Snorwood Does DSL


Here's part 2 of these DSL comments/rants.
Here's part 3 of these DSL comments/rants.
Here's part 4 of these DSL comments/rants.
Comments? Questions? Send mail to snorwood@redballoon.net.

I wanted to get DSL. I found out that DSL is more complicated than it should be, and the range of services offered by the various providers of this service varies widely and is often confusing. Strangely enough, many of the companies which provide DSL service do not make it easy for potential customers to get information about the details of their service; this sort of information is rarely available on the web, so prospective customers must call the ISP's and often talk with several "layers" of sales reps before finding someone can answer questions that are even remotely technical in nature.

I found it rather odd that a "high-end" Internet access service is being marketed primarily not to the technically knowledgeable, but rather to the masses of subscribers to AOL and other somewhat "watered-down" dialup services. I suspect that the relatively low market penetration of this service is a result of this sort of poorly targeted marketing effort. This is complicated by the fact that many ISPs which claim to offer DSL service do not actually provide the service themselves, but rather re-sell the service of some other provider, often the local telephone monopoly. This often makes it difficult to find out who is actually providing the service in order to investigate its reliability and quality.

Anyway, here are some things to look for when choosing an ISP for DSL.


Stuff to Avoid:

PPPoE: PPP-over-ethernet (PPPoE) is being used by many ISPs, often local phone monopolies, rather than simple bridged or routed ethernet. As far as I can tell, this offers no substantial benefits whatsoever to the customer, as it appears to exist primarily as a means for ISPs to oversell their capacity and to make it very difficult for customers to run "unsupported" configurations (servers which need 24/7 connectivity, etc.) and operating systems (anything that isn't running some variant of Win32 or MacOS). This requires that special software (often WinPoET or MacPoET) be running on the client computer and is usually used in conjunction with inactivity timeouts (which is counter to the whole claim of 24/7 connectivity) and dynamic IP address assignment (also unnecessary and highly undesirable for various reasons). Further, PPPoE isn't even a standard yet (though it is described in RFC2516) and results in a performance hit as well. Basically, it sounds like a pretty horrible idea and, like PPP over ATM (PPPoA; I don't know of any ISPs that actually use this yet) should be avoided.

DHCP/dynamic IP addressing: While not quite as bad as PPPoE/PPPoA, this is also undesirable. Unlike cable networks, the topology of DSL networks does not require the use of dynamic IP address assignment for network management purposes; there is no technical reason why an ISP would need to use this with its DSL service, and there are many reasons why they shouldn't: DHCP clutters the network with broadcast packets and adds an extra element of potential instability to the network. If the DHCP server dies, client machines will be unable to obtain or renew IP address "leases." When a client machine gets "renumbered," all current connections (telnet, ftp, etc.) will be dropped. Further, this system depends upon good user behavior; if someone sets up a bogus DHCP server and starts assigning random addresses to other customers, connectivity will be lost. Most importantly, DHCP makes it very difficult to implement many of the concepts which make high-speed network access worthwhile--VPN to other sites, IP-based authentication to other sites, running servers on the client machine, etc. Basically, DHCP is wholly unnecessary for DSL users, adds an extra element of instability to the network, and makes it difficult to do many of the things that make 24/7 high-bandwidth connectivity worthwhile. Even if there is no need or interest in doing any of these things _now_, that doesn't mean that there won't be that need or interest in the future.

installation charge: Most DSL providers will offer free installation and equipment with a minimum service commitment. This is generally a good deal. I would not ordinarily recommend setting up a multi-month deal with a dialup ISP, but the savings with DSL are far more substantial. Most DSL providers will allow you to cancel the service without penalty within the first month if there are service problems or if you move to an area where DSL is not available before the end of the contract. Anything longer than a one-year contract is probably too long, however.

transfer cap: Some DSL providers will charge for bandwidth usage above a set number of bytes per month. This is probably good network management, and isn't necessarily a bad idea, but prospective customers should check to see that the limit is set at a reasonable level.


Stuff to Look For:

multiple IP addresses: Some DSL providers will offer customers a block of IP addresses as opposed to a single address. This is an important consideration for anyone who has multiple computers, printers, etc. or might want to have them in the future. Even with only a single computer, multiple IP addresses can be used for virtual web/ftp hosting, etc. Users with multiple computers can use address translation (usually done with a low-end PC running Linux/*BSD/etc. or by a hardware device) and other methods for several machines to make use of a single "real" IP address (if the terms of service don't prohibit this), but multiple addresses make this much easier and allow more flexibility.

routed vs. bridged service: Routed service is better; it doesn't have the shared-bandwidth and broadcast-traffic issues that are common with bridged service. Still, either is better than PPPoE!

reasonable terms of service: Read the ToS! It's common for ISPs to prohibit spamming, unauthorized access to other sites, and general abuse of the service. Make sure that there are no prohibitions against running your own servers (again, even if this isn't a consideration _now_, it might be in the future; besides, most OS's, including the Win32 variants and all Unix variants, run various services "out of the box," which could potentially place anyone in violation of the ToS!). Check to see if there is some guarantee for the level of service; see if a particular transfer rate is guaranteed; this will help to show if a given ISP is over-selling its capacity.

hardware: Some ISPs provide better hardware than others. Some provide merely a bridge, others provide simple routers, and still others provide routers with additional functionality such as packet filtering/firewalling, etc. Make sure that you get the passwords to any router that your ISP provides (though if you make changes and screw up your service, they can legitimately refuse to help you, so be careful!). How much of an issue the actual hardware is will depend on the intended use of the service, but it never hurts to have "too much" functionality.


Other Considerations:

SDSL vs. ADSL: Symmetric DSL (SDSL) provides identical bandwidth capacity in both the upstream and downstream directions. Asymmetric DSL (ADSL) provides a faster download speed and slower upload speed. SDSL runs over a separate phone line is considered to be the more stable technology, while ADSL uses an existing phone line for easier installation, but is apparently more subject to interference, etc. ADSL service is usually cheaper; with ADSL, make sure that the upload speed is reasonable (128K+). There are assorted philosophical issues about asymmetric technologies to consider as well. If there's a choice and the price difference is minimal, get SDSL.

service guarantee: What, if any, guarantee does the ISP offer? Do they guarantee that, say 70% of your stated bandwidth will be available at any given time? Obviously, this depends on the connectivity of the other site with whom you are trying to exchange data and various backbone loading and routing issues, but your ISP shouldn't be any more of a bottleneck than the stated speed limitations.

business vs. residential service: This should be fairly obvious: business service is more expensive (and is almost always SDSL), but often offers more features or more permissive terms of service than residential service, for example business users are often allowed to re-sell the bandwidth, while residential customers are not. In general, business-grade service can be provided at a residence, but the reverse is usually not true.

installation charge: How much? Are there any hidden charges?

quality of mail/news/web servers: If you are depending on your DSL provider for mail/news/web/etc. service, check on the quality of these services. My personal feeling is that it is a bad idea to depend on any DSL or cable provider for email, since one would lose the account upon moving to any area that is not currently serviced by that DSL/cable provider. My recommendation, short of running your own mail server, is to get an account with a reliable ISP, preferably one which offers Unix shell access for email use; this service is often very inexpensive if you don't need dialup connectivity. Shell access is also important since I am not aware of any DSL providers that offer it. The web servers run by DSL and cable providers are generally pretty close to useless, since they rarely support large sites and almost never allow any "useful" server-side processing (CGI, SSI, etc.). Anyone with "real" web-hosting needs would probably be best served by another provider (also note the same caveat as email: if you move to an area not serviced by the DSL provider, your URL will change, too!). News service is probably important; see if the DSL provider runs its own servers or contracts with some place like Supernews. Make sure they carry a decent feed.

price: Usually, better service costs more. But not always. Compare prices and see.

installation process: Who does the installation? How fast can they do it? Usually, the bottleneck is having the local telco measure the distance and provision the line.


Return to home page.
This page last updated on December 5, 2000