xDSL Technology

Introduction

The information here is not a primer on xDSL. Rather, it is a quick and dirty synopsis for the consumer who is thinking of using xDSL technology for networking access and needs some practical information. The resources section at the end contains links to many DSL resources. This tract concludes with some discussion specific to the US West (now Qwest as of Oct, 2000) DSL implementation.  At this point the US West specifics are a bit dated.

However, to make use of DSL, it helps to understand the basis of the technology. DSL is a technology for pushing a (relatively) large number of bits through wiring that is typical for "last mile" telephone connections -- i.e. small gage copper wire of lengths less than 18,000 feet. There are a number of different protocols that fall under the DSL umbrella: ADSL, RADSL, HDSL -- and even different subvariations (e.g. CAP encoding ADSL versus DMT encoding ADSL), thus the acronym xDSL to represent the technology in total, without regard to the specific protocol. It's a little like the 56k modem field before the V.90 standard unified the two main contenders, X2 and KFlex.

xDSL is used to push high bit rates through copper wires that run from point A to point B. For most people, point A will be their home and point B will be the other end of the copper phone wire, that is the substation of the local phone company.

Standard telecom modems (e.g. 56k, 28.8k, etc) establish a data stream between two arbitrary points using the entire telecom system--that is, from the sender's local loop, through the telephone switching system (mostly digital switches now) and then to the receiver's local loop. Standard modem connections can span continents, with one end being thousands of kilometers from the other end. 

DSL modems, on the other hand, establish a connection from one end of a copper wire to the other end of that copper wire: the signal does not pass into the telephone switching system. Consequently, DSL modems are not limited to using only the voice frequencies passed by the standard telephone system (typically 0-4kHz); DSL modems typically use more than 100kHhz.

To reiterate, one end of the DSL link will be at the consumer site, the other end must be at the other end of the copper cable -- usually this means your local telephone exchange. At your local phone company the local loop first goes into a splitter that splits the data frequencies from the voice frequencies. The voice frequencies are wired into a traditional POTS switch and enter the normal telephone switching network. The data frequencies are wired into a corresponding DSL modem at the CO end and the resulting high-speed digital data stream coming from (or going to) the consumer is then handled as normal data (not analog voice) and may be hooked into any number of networking technologies for further connection to the data's destination. Thus, the data never enters the standard telephone switching system.

Typically the data will be routed over a LAN/WAN connection (10Base-T Ethernet, T1, T3, ATM, frame relay, whatever) to a business office. The business may be an ISP (the ISP may or may not be the local phone company) which may then route the data onto the Internet, thus providing you with Internet connectivity. Or the business may be the company you work for and the connection provides high-speed access from your home direct to your company's network. Note that if the connection is made to an ISP, you are not connecting to the ISP over its standard modem bank: you are coming in over some sort of LAN/WAN data connection that the ISP has arranged with your local phone company. This is the only way an ISP can provide DSL-connected ISP service for customers. Also note that DSL is always "on:" the connection is always there, ready to pass bits up and down the pipe: there is no calling a remote number and waiting for modems to train up.

Because the other end of your xDSL connection has to be at the local phone company, the choice of which xDSL protocol your modem should support is made for you: whatever the local phone company dictates. (See Hardware/RBOC/CLEC compatibility matrix for details of who is using what.) However, it would be nice if there was one standard so that mass production and pricing of xDSL modems would ensue. It would also let you take a modem from one local phone company to another. Also, Compaq/Dell/etc. are not inclined to sell computers with xDSL modems pre-installed unless there is a single standard. See the "Standards" section below for information about efforts to standardize xDSL modem technology. Also note that calling xDSL connection devices "modems" is a bit misleading in that they are not like "standard" modems; however the terminology seems to have stuck.

Splitters

Because DSL technology uses a wide frequency range, it is possible to have simultaneous voice and data use of a single copper connection. (Indeed, one of the original design goals of DSL was to make it possible for one copper wire to service multiple homes (e.g. a small subdivision with only 1 copper connection to the local phone exchange) by multiplexing multiple 4kHz conversations onto one copper pair.) The voice call will use the normal 0-4kHZ spectrum and the DSL modem will use the higher frequencies to pass the data traffic. Of course, this sharing of the copper is not without some potential problems. In particular, many phones may pass onto the copper frequencies higher than 4kHz, interfering with the DSL data stream. Also, the higher frequencies used by the DSL may be picked up by the phone, causing static on the headset.

The original solution to the 4kHz interference problem was to use "splitters:" a device called a splitter is attached to the phone line near where it enters the customer premise. The splitter forks the phone line: one branch hooks up to the original house telephone wiring and the other branch heads to the DSL modem. See figure 1. Besides splitting the phone line, the splitter acts as a low pass filter, allowing only 0-4kHz frequencies to pass to/from the phone and thus eliminating the 4kHz interference between phones and DSL modems.

Figure 1

The problem with splitters is that it requires breaking and remaking some telephone wiring connections and perhaps even installing new wiring to the DSL modem. In many cases, this means a service call to the customer premise. To avoid this, various alternatives have been proposed. The Universal ADSL group is working on reduced speed DSL that is more immune to frequency interference and that probably uses only frequencies beyond human hearing. Rockwell has proposed something similar called CDSL (consumer DSL). Another solution, used by Netspeed equipment is to use "micro filters." Netspeed calls this "EZ-DSL." A micro filter is essentially a customer-installable low-pass filter with an RJ-11 jack on either end: the customer plugs the phone into one end and the plugs the other end into the wall jack. A micro filter is placed between each telecom device and the wall jack it plugs into, except for the DSL modem. See figure 2.

Figure 2

Note that the micro filter solution is essentially a customer-installable (i.e. no wiring required) version of the splitter solution. Also note that it is only necessary to ensure that there is a micro filter somewhere between telephones and the DSL line. If the customer premise wiring makes it easy to do, the setup in figure 2 can be replaced by the setup in figure 3 (the degenerate case, in which the micro filter solution essentially becomes a splitter solution). The figure 3 setup can potentially have less line degradations and there have apparently been cases where a setup like figure 2 produces a line that is too marginal to work with a DSL modem, but will work when wired as in figure 3.

Figure 3

More splitter discussion: http://telecoms-mag.com/issues/199810/tcs/cavanau.html

Wiring/Line Qualification

There have been some misconceptions about the wiring type required by DSL modems. Cat 5 wire is not required for DSL modems. DSL modems can work over Cat 3 wiring or even worse. However, the better the wiring the less the signal degradation and the longer the distance over which DSL modems will still work.  If you are re-wiring your house, I'd recommend Cat 5 wire or better.  However, whatever wiring is in your house is just a small fraction of the total wiring between you and the telephone central office, most of which you have no control over.

Not all telephone lines are capable of passing the high frequencies used by DSL modems.   There are also limits to the length of copper wire that DSL will work on.   Therefore, a telephone line must be "qualified" before DSL can be installed on the line. The line qualification checks the length of the local loop, for the prescence of loading coils, for the prescence of excessive bridge taps, for local loops that are provisioned over DLC, and the general state of the line.

If a line fails to qualify, there are limitations to the recourses available. A good relationship with the linesmen/testers would help.  You can try to get load coils removed or bridge taps eliminated, but your telephone company's standard policy may not condon this extra effort.   You can try to get your phone service moved to a different and perhaps cleaner line.  It will probably be a tough go.  The International Engineering Consortium has a tutorial on xDSL line testing.   The line testing tutorial may put some arrows of knowledge in your quiver and may provide a few meager weapons useful to talking the teleco into the extra effort needed to get a marginal line qualified.

Webproforum has an excellent tutorial on the options for providing DSL service over a DLC-provisioned phone line.

CO (Central Office) Locations

Because DSL technologies are limited to finite lengths of copper wire, it is often interesting to know how far you are from your central office (the local Telco wire center that houses the other end of your telephone local loop).

Finding this information is problematic. Perhaps you know of a Telecom facility in your local neighborhood.  Alternatively here are some other options:

Here are few lists of Qwest central office locations:

COs for Seattle.

COs for Portland.

Some CO locations for GTE, Seattle eastside.

A more general solution, for Qwest territory, is available from the US West iconn database (InterCONNection database).

Finally, Qwest has a list of deployted COs at http://www.qwest.com/disclosures/netdisclosure459/

Mapquest.com has a locator tool (telephone area code search) where, given an area code and the prefix, it will locate on a map the CO for the area code, prefix combination.  It's been accurate for the few tests I've performed, but others have reported that it gives bogus results.

A database that covers the entire US is available at www.telcoexchange.com, where there is a Digital Line Pricing Tool.  Fill out the form for this tool, specify DSL as the desired connection type, and the tool will spit out the name of the CO for the specified number.   Beware, however, that the distance calculations provided by the tool may be way off. [As of 11/21/98 the www.telcoexchange.com  site is no longer providing CO names or V&H location coordinates.  I'm not sure why.]

www.getspeed.com will also provide some CO distance calculations.

The US West and the www.telcoexpress.com databases express central office locations in V&H (vertical and horizontal) coordinates, which is a coordinate system developed at Bell Labs and used by most Telecom companies in North America to express CO locations.

I've written a little code to convert from V&H coordinates to latitude and longitude (and back again).  Click here to convert between V&H and lat/lon.  For many reasons, don't expect this process to be exact. (I generally find the V&H locations from the US West database convert to lat/lon coordinates that are within 10 blocks of the actual CO location.)

Once you know the lat/lon of your CO, you can locate it using something like "Maps on Us": This URL will take you to their page that allows you to "Show Latitude and Longitude."  Check this checkbox and then click the Set General Options button. You will then be able to open a map location by specifing a latitude and longitude.

Once you have your lat/lon location and the lat/lon of your CO, the Bali Online site has a nice little utility to compute distances between two points. Note that the "great circle" calculation of the Bali Online site is good for long distances like "the distance between Seoul and New York", but local surface irregularities can make it fairly inaccurate for short distances (e.g. intra-city).

http://www.dsltester.com has software that runs a test to determine if the phone line in question (the phone line used in the test) is likely to qualify for DSL. There is a link to the actual test server from this page, as well as some sample test results and other information about the test. They sell the results to ILECs/CLECs and other service providers, but will provide a pass/fail report for end users. Some people have reported good results with this test.  Anrew Kaufman of dsltester.com reports on how the test works:

Well, in short, we look a narrow band modem diagnostic information which is collected by the modems. We then look at the spectral curves produced, and compare them to  a library of curves that we have developed and through comparative analyses  of curves from loops of approximately the same distance as the one under  test we are able to identify the signatures of the various jeopardies to  DSL, such as Loads, DLC's, Bridged Taps, and DAML. I hope this high level  overview gives some better idea of what is happening.

 

Sharing a modem/cable/xDSL connection between multiple computers

Anyone with more than 1 home computer and an Internet connection eventually asks the question: "How do I share my Internet connection between my 2 (3,4,5...) computers?" Modem connections can be shared and it's even more tempting to share cable/xDSL connections because of their "always on" nature and the greater bandwidth available. The methods are generally the same for any of the connection technologies and fall into three general categories:

1. Obtain a separate IP address for each computer and make sure that you have some sort of networking enabled to share the connection. One option is to connect the cable modem to a hub and to connect your computers to the same hub. Alternatively, with a bit more setup you may use a router and perform routing on your local network
   
   The advantage of this solution is that each computer has equal and full access to the Internet. One disadvantage is that many ISPs charge separately for each IP address. There are also security concerns: if you just connect your local LAN direct to the Internet, you better make sure your hosts are each individually secured. The other two solutions depend on a centralized approach to the external connection, making it a logical extension to deploy a centralized security solution (e.g. a firewall).
2. Use NAT (network address translation) software to let multiple computers share a single IP address. Sygate is an example of a product in this area. Linux's IP masquerading is another. NAT1000 is another. Darren Mackay has a great site with lots of information about various NAT software.
   
   Dan Kegel has worked adding NAT support to gaming software.  He's got a writeup of NAT and gaming problems.
   
   On a separate page I record some USENET discussion of NAT servers, and in particular the problems of trying to use NetMeeting (or other H.323 protocol software) with a NAT server.
3. Use proxy servers to proxy the particular service you want to share (e.g. HTTP proxy server, ftp proxy server, etc.). Wingate is an example of a product in this area.

dslreports.com has a nice set of drawings that depict the different ways of wiring up a LAN to the Internet. 

Tim Higgins has an excellent web site on sharing an Internet connection. www.cablemodeminfo.com also has a selection of links to articles about sharing a cable modem. J Helmig's site is another site with information about sharing a modem connection. The Helmig site also has a lot of tech-support type information about Windows networking.

Sharing a DSL connection with Both Local and Remote Computers

A more elaborate situation involves sharing a DSL connection with both your local LAN and with a remote laptop when you hit the road. Details are on a separate page.

Sharing data over the Internet (VPN)

When I say "sharing data over the Internet"  I mean using the Internet as a "long cable" to connect two (or more) geographically separate hosts. In other words, two separate hosts want to share files back and forth between each other. There are a number of ways to do this, each with separate capabilities and problems.

1. OS-independent, bare bones: run an FTP server.
   One host runs an FTP server and other hosts can, via an FTP client, get and send files to the FTP server. This is a simple mechanism, is operating system (OS) independent, and is a time-honored tradition on the Internet.  However, it's not real seamless and the capabilities are somewhat limited.
2. Use standard Windows networking, with the Internet providing the connnection.
   Steve Jenkins has a detailed writeup of how to do this.  I also provide a short writeup of windows networking and the Internet. This is a nice extension of a local LAN over the Internet, however the mechanism is not very secure. It opens the hosts at either end to potential security attacks and, typically, the data passing over the Internet (i.e. the contents of your files) is not encrypted.  In other words, it is open to people to read or even (with more work) modify, as the data moves over the Internet.
3. Use VPN.
   VPN, or Virtual Private Networking, is a mechanism for establishing a secure and private network on top of an open and insecure network.  In effect, you end up using the Internet as a pipe, and establish a secure and protected connection between two separate LANs over this pipe.  A VPN connection typically provides all the capabilites of the "standard Windows networking" connection, with much better security and data integrity.  Windows provides VPN services through a technology know as PPTP.   Microsoft has several white papers on the technology on their web site.  The "Routing and Remote Access" (also known as the multi-protocol router) patch for Windows NT provides both PPTP client and server capabilities. I provide VPN details are on a separate page.

Security

An article I wrote for Information Security Magazine provides a basic overview of security and a DSL connection to the Internet.  The following section provides a shorter re-hash of the article's content.

An excellent site for firewall reviews and other site security information is http://www.firewallguide.com.

An xDSL (or cable modem) connection to the Internet has a greater security risk than a plain old analog modem dialup connection. For one, the bandwidth is greater, allowing the possibility of more cracking to be done in the same period of time. More importantly, the connection is usually always on, which makes your hosts a much easier (and potentially more lucrative) target to find. The discussion in this section concentrates on examples of LANs connected via DSL to the Internet, but the points can be applied to the single computer case just as well. (The LAN case encompasses the single computer case.)

One mechanism for sharing a DSL modem is to connect it direct to your local LAN hub and to use valid IP addresses for each of yours hosts:

Figure 4: Direct Hub Connection

While this is a conceptually simple method for sharing an DSL connection (particularly with a bridging DSL modem and an ISP that is handing out IP addresses as required via DHCP), it requires a fair amount of diligence if you are concerned about the security of the local hosts. First, the only thing preventing your local LAN traffic from zipping around your ISP's LAN is an Ethernet learning bridge. While a bridge will not forward traffic destined to local MAC addresses, it will forward multicasts and broadcasts. A malicious cracker could make use of this information to target your systems. In addition, if you are using more broadcast-chatty protocols on your local LAN, like NetBEUI, you are passing even more information onto the ISP's system. A learning bridge is not a security device, it is a traffic-limiting device, designed to keep your local point-to-point LAN traffic from swampping the rest of the network. Second, a configuration like this leaves every host equally open to attacks from the outside. Each host has to be secured independently and equally if you want to prevent a weak link in your system. Finally some security techniques (such as firewalls and preventing your file and printer sharing traffic from even being accessible) are not available in a configuration like this. There is nothing inherently wrong with this configuration: it is a perfectly valid configuration, depending on your security needs. Most companies with a concern about the data on their local LAN would not use a configuration like this. However, historically, many departments at educational institutions would connect with mechanisms similar to Figure 4 (with a standard Ethernet bridge, usually from DEC, rather than a DSL modem, but the concept is the same).

Other details of the direct hub connection: (under construction): possible problems if only using TCP/IP transport (lack of connectivity, or connectivity through ISP's gateway); using multiple IP addresses problematic if both DHCP and static assignments are desired; using multiple transports and unbinding file-printer sharing/netbios from TCP/IP.

Another option would place a dual-homed gateway between the ISP and your local LAN. If the local LAN is using non-routed IP addresses and if the gateway is only providing access through a proxy server or a NAT server, then the security is improved:

Figure 5

The dual-homed host solution isolates your local LAN traffic from the ISP's network. In addition, a NAT/proxy server on the dual-homed host provides some protection to other hosts in the local LAN, which do not have to be watched/secured as tightly. In a situation like this, an operating system with security capabilities would be advisable. For Windows users, Windows NT, because of its security capabilities, would make more sense on the dual-homed host rather than Windows 95/98. Using NTFS, it is possible to lock down the OS files for NT, helping to defeat cracking attempts from the outside. In addition, it is possible, via the network control panel applet to disable the Workstation, Server, and NetBios bindings from the network adaptor that is connected to the DSL modem. This eliminates all Windows networking file access through the NIC connected to the DSL: you won't have to worry about anyone making a network neighborhood connection to shares on your gateway machine. Unbinding like this does not eliminate file and printer sharing through the local LAN side of your gateway machine, which is a great feature. In other words, you have file and printer sharing capabilities on interfaces 192.168.0.1, .2, and .3, but don't even expose file and printer sharing capabilities through interface 204.180.205.31.

The dual-homed approach, with a fairly small degree of inconvenience (as compared to figure 4), provides the opportunity for improved security. To summarize the dual-homed approach:

1. Use a dual-homed machine to make your connection to the DSL modem.
2. Run a NAT or proxy or firewall server on the gateway machine. Only run those services that are necessary (e.g. if you don't need to run an ftp server, don't.)
3. Use an OS with security capabilities on the gateway machine. Disable the guest account. Use reasonable passwords on all accounts. Lock down the OS files. Unbind native file networking protrocols from the DSL-side NIC on the gateway machine.  For Windows NT users, consult the quick checklist for securing Windows NT to make sure your Windows NT installation is reasonably secure.  Also, the IIS security checklist has lots of information about securing a Windows NT machine that is connected to the Internet.  If you want all the details on locking down your NT machine, this is the place to look.

Securing a connection to the Internet is a large topic, much of the which is beyond the scope of this tract. There are a number of sites that provide more discussion. Johanne Ullrich's web site has a simple introduction to security issues for the consumer connected to the Internet. He also includes some step-by-step instructions for some common precautions for Windows 95/98.

http://www.microsoft.com/windows95/community/mktbulletin/cable-security.asp is Microsoft's quick and dirty "how to for dummies" page on cable modem security for Windows 95. It basically talks about turning off File and Printer sharing or using password protected shares. http://support.microsoft.com/support/kb/articles/Q164/8/82.ASP is a more complete knowledge base article about basic Windows NT security for Internet connections. More complete information is available from Microsoft's security pages: http://www.microsoft.com/security

NSA has a popular set of white papers on securing Windows 2000.

For a great tome on security and securing NT in particular, see Sean Boran's site.  The Amoring NT site is good and concise. The labmice.net site has a good checklist of items to attend to for securing Windows 2000. The hardening Win2k guide at http://www.systemexperts.com/win2k/HardenWin2K.html is useful. The NT security FAQ is not concise, but it has lots of information and links. Finally, the CERT site is a good checklist and contains lots of pointers to other sites.

Port scanning sites

HackerWacker will do a port scan and a few other probes of your host, testing for common security problems.

http://grc.com will do a port scan (look for "Shields Up").

http://www.dslreports.com/r3/dsl/secureme

http://www.antionline.com/

 

Performance

Along with sharing and security, one of the first things a new DSL user wants to know is "how fast is this baby, really?"  So they surf off to some server somewhere and try to download a big file.  And they are subsequently pleased at the speed or curious because the rate doesn't seem as fast as the modem is rated.  Here's a few quick points to keep in mind while measuring your performance.

Know your modem's speed.  Your modem is "trained up" to the corresponding equipment at the other end of your local loop. DSL Modems, like standard anlogue modems, can train up at different speeds, depending on the line condition and configuration settings at the consumer end and Teleco end of the connection.  For example, with the Cisco 675 modem used by US West, the command "ifconfig wan0", when given to the modem (using the serial port connection to the modem's management port) will display something like:

nsos>ifconfig wan0
wan0 ADSL Physical Port
Line Trained
640 Kbps down; 272 Kbps up; 340 baud
Line Quality 34 dB

nsos>

In this case the modem is trained up for 640kbits/sec down and 272 kbits/sec up: the very best you can expect in this case is a download transfer rate of 640kbits/sec.

Recognize that the Internet is not homogenous. Some servers may be far away and connected over slow links.  You will not get fast transfer rates from these servers regardless of how fast your local connection is. You are only as fast as the slowest link (or slowest server). In others words, the best download test would be a connection to a fast server directly on your ISP's network. This kind of test eliminates the most unknowns.

Know what you are measuring. When you get performance numbers, where do you get them from?  They may mean different things. For example, while downloading a file in Internet Explorer, IE will report a download speed.  This is the speed that the actual file data is being copied.  (For example, a 200k file that takes 60 seconds to transfer is a download speed of 3.3k/sec.)  But the actual number of bytes passed over the DSL connection is much higher because of the overhead of encapsulating the payload in the various network layers.  Add various Ack/nak packets or whatever other protocol overhead there is, and you may be shoving a much greater number of bytes down the line.

To elaborate, here's one simple test I did. The numbers are just rough guides and I didn't subject this test to great rigor. However they illustrate my point. I downloaded a 5,595k file over a 640kbits/sec (down) DSL connection.  The download speed reported by IE (actual file bytes) was 45kBytes/sec, or 360kbits/sec.  However, the actual number of bytes passing over my Ethernet interface from the DSL modem was 56kBytes/sec (as reported by Windows NT's Performance Monitor), or 448kbits/sec, which is getting pretty close to the rated connection speed.  (These numbers are averages over the entire transfer time.)  If I only used the first measurement (IE's reported download speed) I might think I'm only getting 56% of the maximum connection speed. However the second number shows that I was actually getting at least 70% of the rated connection speed. For comparison, the highest I've seen off my US West DSL connection is 93% of the rated connection speed, as measured off the Ethernet interface.

It really matters what you measure.

All that said, how do you fine-tune a DSL connection?  I find that Windows NT's default configuration for its TCP/IP stack works just fine. It supports a number TCP/IP dynamic performance adjustment algorithms that have been developed over the years and these work just fine for me.  Your mileage may vary.  Other people using Windows (especially Win95 and Win98) have reported considerable performace gains by adjusting various configuration parameters. Philip Philpov's Cable Modem page provides some enduser-oriented discussion of cable modems, including tips and tweaks for better speed. The discussion has almost equal bearing for DSL connections.  http://home1.gte.net/awiner/ also discusses some registry tweaks for improved DSL/Cable modem performance under Windows 95/98/NT 4.

Performance measuring tools:

There are numerous sites around the Internet that advertise "click here to get a readout of your connection speed."  (For example, see www.2wire.com's bandwidth measurement page.)  These all work by downloading a bunch of data to PC and timing the process.  It is important to note that these tools are rough approximations at best: if the pipeline between you and them is congested, they are are going to tell you that your DSL link is slow. They are measuring a total path through the Internet and not just the speed of your DSL link.

US West (Qwest) has a performance site that lists a number of test download locations on their network.  If you are a uswest.com DSL subscriber, by selecting a site close to you, you get a test that minimizes weak links on the general public Internet.

Windows 95/98: try the Network Monitor Agent that Microsoft provides at http://www.microsoft.com/windows95/downloads/. It works with the Win95 System Monitor.  It shows realtime transfer rates off your ethernet card (in other words, it includes most overhead layers).

Windows NT: try the Performance Monitor, which is great tool for monitoring the state of a NT system.  Much superior to the Win9x System Monitor. The relevant object to measure is the Network Segment object: an interesting counter of that object is the "Total bytes received/sec" counter.  There are lots of other interesting objects also.  Note: the Network Segment object is only visible in the Performance Monitor if the "Network Monitor Agent" service is installed (goto "Control Panel, Network, Services" to check/correct this).

DU Meter (http://www.hagel.threadnet.com/dumeter/) and Net.Medic (http://www.vitalsigns.com/netmedic/index.html) are two other popular tools.

Sitka maintains a page with a number of network monitoring tools.  Of particular interest is the visual ping took, which calculates the ping time and the available bandwidth from a from a sitka host (Sitka is situated in Canada) to the a user-specified host.  For example:
http://sitka.triumf.ca/cgi-bin/visual-ping?uswest.net
will calculate the data from sitka to uswest.net.   Substitute your site of interest for uswest.net in the above URL.

Another intesting tool is available at http://www.datametrics.com:81/ This tool will perform a traceroute, and also plot the locations on world map.

 

Performance results:

Given all the variables in the Internet, it's quite difficult to do an apples-to-apples, repeatable comparison of access speeds.  Nonetheless, people are always curious to compare speeds. Bill Faust has a project going that has compiled a set of results of download speeds.  If you want to see what speeds others are getting, check it out.   http://www.disisit.com/nettest.html also has some interesting numbers for one specific case.

xDSL Standards

A number of ADSL standards have been proposed, many with the intent to obviate the need for splitters and any service call to the customer premise. These include Netspeed (Cisco) EZ-DSL, Rockwell's CDSL (consumer DSL), and the ITU's G.Lite initiative.

As of June 1999 the ITU's G.Lite standard has been ratified. The consumer DSL market appears ready to rally around this standard, but as of June 1999 there are few (perhaps none besides tests) deployments of this standard. This standard is known as G.Lite, DSL-Lite, and Universal DSL. It allows for splitter-less installation (using micro-filters when necessary instead) and is limited to 1.5MBits/sec down.

The Universal ADSL group is an advocacy group working to rally the industry around a common standard.  They have focused on the ITU G.Lite initiative, which passed into the standards phase in the fall of 1998.

 

US West DSL (MegaBit Services)

The information in this section is mostly specific to the deployment of DSL by US West. US West calls their DSL offering MegaBit Services. MegaBit Services does not refer to a new technology, it is just the tradename US West uses to refer to their rollout of RADSL service. The US West deployment is using EZ-DSL, a micro filter design by Netspeed. (Netspeed was acquired by Cisco in March, 1998) Customer (home) end equipment is either the PCIRunner xDSL internal modem card or the SpeedRunner 204 (which is now being called the Cisco 675) standalone (external) router (or "modem" as I've been calling it). The PCIRunner is installed much like a regular modem. It plugs into a PCI slot and has an RJ-11 jack for connection to the phone line. It comes with Windows 95 and Windows NT drivers. It does not require an Ethernet card.

The standard install is using the SpeedRunner 204 and comes with the SpeedRunner 204, an Ethernet (3Com 3c905) card, a twisted pair Ethernet patch cable (cross-over), and micro data filters made by Globespan. The SpeedRunner 204 has an RJ-11 jack for connection to the phone and an RJ-45 jack for an Ethernet connection to the customer equipment (an Ethernet hub or a single PC equipped with a 10-baseT Ethernet card). If the SpeedRunner is connected to a hub, it should be connected with a straight-through patch cable rather than the cross-over cable that comes the install kit. Connecting into a hub makes is possible for all the computers on the customer LAN to access the Internet. (See the Sharing section.)

http://w3.one.net/~garyc/adsl/howtos.htm#lan has some information on how to operate the Cisco 675, including upgrading the firmware and recovering from a blown firmware upgrade.

US West is providing two different filter types: filters for wall-mount phones and filters for phones connected to a wall jack. The filters only filter on line 1, so if you have a two line phone setup and have the DSL modem on line 2, it will be necessary to somehow arrange to filter the 2nd phone line. There are at least two possibilities: apparently the wall-mount filters come apart so you can dissect them and switch the connections from the line 1 pins of an RJ-11 jack to the line 2 pins of an RJ-11 jack. Alternatively, at Radio Shack and other "phone" stores you can buy little connectors take a single RJ-11 2-line jack and splits it out into 2 RJ-11 jacks, both wired for line 1 (but one going to the real line 1 and 1 going to the real line 2). Plug the micro filter into the line 2 jack of this 2-line splitter. Then plug a single line phone into the micro filter.

Software

There are no special software requirements to use a DSL connection. Quite often the DSL connection device is package with an Ethernet interface for the consumer side (e.g. the Cisco 675 supplied by US West).  In this case, if your computer speaks TCP/IP, and if it can interface to Ethernet (just about every operating system meets these two requirements), then it can use a DSL connection.  uswest.net supplies a special CD-ROM package for Windows as part of the US West installation package, but it's mainly just a browser (Netscape) with some uswest.net configuration information pre-supplied.   It's not necessary at all.

A short rundown of the US West installation process:

1. Install the Ethernet card in the PC (not necessary if connection to a hub). Make sure the PC OS recognizes the Ethernet card and has the proper drivers installed.
2. Install microfilters on all phone lines, except the line connected to the Cisco modem.
3. Connect the Cisco modem to the phone line (using the Cisco's RJ-11 jack) and to the Ethernet card (or hub) using the RJ-45 jack.
4. Make sure the Cisco modem is configured for bridging mode, not classical routing or PPP routing over ATM. (This actually depends on your ISP. uswest.net is using bridging mode.)
5. Configure your operating system with the correct TCP/IP configuration information for your ISP. (Basically: IP address, netmask, default gateway, and DNS server addresses.   You may also have to configure email with the correct server name and user id and password.  You know the drill.)

The US West order process and support staff is notoriously SNAFUed, so it may take some time and a number of people to get answers to simple questions. Apparently, their process works like this: they have a sales staff that takes orders and appear to work under commission. These sales people have access only to a new order database. My sales staff operated out of an 888.641.4384 number. After an order is taken, it can progress to a "stored order" database, which is where orders sit if the destination central office is not yet DSL equipped. An order stays in the "stored order" database until its due date arrives, at which time it migrates to the work order database. The work order database is where an actual work order is generated for the order and someone is scheduled to do the installation. Each group at US West apparently has access to only one database and you can get bounced around quite a bit until someone can actually find you in the database. Clearly, the system is far from optimal: case in point: my order was entered with a due date of 10/1/98, instead of 7/30/98, which is when service is actually available for my area. My order was also "lost" numerous times. Sound advice would dictate checking on the status of your order several days after placing it.

Second-hand information indicates that for the initial Seattle rollout of DSL, US West installed capacity for 64 ports per wire center (CO). Given that Seattle has about 11 wire centers, this equates to capacity for 704 DSL customers.

US West Megabit numbers:
Sales: General Megabit: 800.634.2879. My sales (for Washington?) number: 888.641.4384
Post-sales info: 888.333.0131
Work Order number (the people only track work orders and don't have access to the "stored order" database): 888.234.9375
Tech Support: 888.234.8375
Megabit Installation Technical Support: 1-800-247-7285.

ISPs that support DSL access

ISPs that provide DSL access are worried about their Internet backbone connection being swamped by these new high-speed links. For example, if an ISP has only a T1 link to the Internet, it won't take many 256k DSL customers to put a heavy strain on this T1. ISPs seem to be dealing with this issue in two ways: limiting what the customer can do with his link (e.g. not allowing the customer to run http servers), or by putting monthly quotas on how many bits the customer can transfer over his link. The former, in my opinion, is a dumb idea, the latter is perhaps a reasonable solution to a valid problem.

US West sells "MegaCentral" (an ATM connection to US West's data net) connection services to ISPs that wish to service US West DSL customers. Assuming a client who uses DSL to connect to the internet through an ISP, the mechanism for a packet of data is as follows: the data passes from a client's computer, through the Cisco 675 to the local CO and from there it passes onto US West's ATM network and gets sent to the client's ISP. From there the ISP passes the data onto the Internet for routing to its eventual destination.

There is a vast body of telecom law in the US that prevents the RBOCs (Regional Bell Operating Companies, the baby bells, e.g. US West) from offering long distance service (both voice and data) until their home territories are open to competition. Speculation has it that this prevents US West from opening up their ATM network to nation-wide ISP mega-central connections.  In other words, if you are an ISP and want to provide service to US West DSL customers in Seattle, you have to connect to US West's ATM network in the Seattle LATA; a Denver connection won't do because US West can't run long distance data over their ATM network to your Denver ISP.  From the end-user's point of view, this means that you are limited to ISPs that have a connection to US West's ATM network in your local LATA.

US West maintains a list of ISPs that are equipped to provide ISP service for US West Megabit customers.

Todd Boyle has a comparison chart of ISP's providing DSL service in the Seattle area.

uswest.net does not track NIC MAC addresses.  PacBell also does not track NIC MAC addresses.

US West: Some Technical Details

US West provides some sparse technical details about their configuration in their disclosure pages for the DSL tariff:

http://www.uswest.com/com/disclosures/netdisclosure403/index403.html for disclosure page.

http://www.uswest.com/com/disclosures/netdisclosure403/news.html#ADDINFO for other disclosure information.

With the Cisco 675 modem set to bridging mode (RFC 1483), the Cisco is doing ethernet to ATM bridging. Data from the PC passes down through the TCP/IP stack on the PC, gets packaged as Ethernet frames and is passed to the Cisco over the Ethernet interface. The Cisco converts these Ethernet frames to ATM cells, which get passed over US West's ATM cloud to the ISP's router, where they pass into the ISP's system.

The alternative is to run the Cisco 675s in routing mode, in which case the Cisco 675 acts as a mini router, receiving IP data from the PC (transported in an Ethernet frame), which is then sent onward as an IP packet in a PPP link running over ATM (PPP over ATM). There may be some advantage to this method for some ISPs, since many are already set up to do authentication and billing using PPP-based systems.

As of Spring, 1999, new US West installations are configuring the Cisco 675 to use PPP routing. In this mode, the Cisco 675 is using PPPoA.  The 675 is logically one endpoint of a PPP link.  As such, it has an IP address and acts as a router, not a bridge.  Since the basic uswest.net PPPoA configuration supplies only 1 IP address, which is used by the 675 as one endpoint of the PPP link, the 675 acts as a NAT server to effect the actual connection of any PCs to the Ethernet interface on the 675.  See http://www.users.uswest.net/~scottz/Cisco675-NAT.html for information on the Cisco NAT implementation.

US West Problems

USWest: Bad Cisco Modem or faulty modem power supply.

There have been numerous reports of Cisco modem failures with the US West DSL service. Many of these appear to result from bad power supplies. To quote from SimMike's posting:

I finally talked with someone at US West who confirms that my Cisco modem
has failed. The sure sign of modem failure is the LAN LNK light blinking on
and off. He also confirmed the rumor that US West had sent out a bunch of
faulty power transformers. From my understanding, the transformers slowly
start malfunctioning, overpowering the modem, until the modem finally fails.
It boggles my mind that they could send such a junky cheap transformer with
an sophisticated router like the Cisco 675. Stupid is the word that comes to
mind.

They promised to send me a whole new modem package. I will send back the old
one after the new one arrives. My service will be out 10 days. One final
piece of advice, be sure and call the Megabit Installation Technical Support
line at: 1-800-247-7285. These guys are the only ones who understand the DSL
hardware. Everybody else at US West will give you the run-a-round.

Read the message below for signs of modem failure.

SimMike wrote in message ...

>>>This morning, 10-30-98, I hit the mouse to bring my screen back to life.
There was an error message saying it could not connect to DCHP to retrieve
my addess (IP). I closed this box and tried my e-mail and web browser. No
luck. The WAN and LAN LNK lights were steady and on. There was even
intermittent activity on the ACT lights for both. Still no connection. I
rebooted my computer. Same problem. I unplugged the modem power, no luck. I
connected the Serial port Management cable to the modem and brought up
Hyperterminal. The familiar Netspeed banner flashed on the screen. Response
seemed somewhat sluggish, but I tried a few commands, like Stats. Next I got
this error message:

"Hello!
Operation fault at fefd55cc, subtype 01
Fault ecord is saved at 1013b540
fefd55cc : 90b03000 1000638c  ld  0x1000638c, g6"

>Now the Cisco 675 banner will not come up. I'm afraid the modem is fried. I
tried one more thing. I unplugged the modem transformer and let it cool off
of half an hour. It always ran hot anyway, much hotter than other
transformer converters. When I plugged it back in, the only light that  came
on was the Power light. No WAN light. No LAN light.  Nothing except power.
If I leave it be, after about twenty minutes the LAN LNK light will start
weakly flashing every second or so. Slowly this flashing gets stronger. Next
the LAN LNK light starts flashing and alternating with the Alarm light.
Finally after about 10 more minutes, the LAN LNK light is steady, no Alarm
light, and the LAN ACT light even flashes occasionally. Still no WAN light.
Still no connection via the Management cable connection.

>I really think the Cisco 675 somehow failed. I read an earlier message
about possible problems with the transformer malfunctioning,  overpowering
the modem, and eventually causing total failure. That sure looks like what
happened. If it was simply my DSL connection, the Serial port management
connection should still work.>
>
>Mike Reinholz
>PS -- my computer is running fine. I ran 3Com diagnostics on the network
>card and it passed all tests.

USWest.net: Problems connecting to another DSL-machine on the same local subnet.

The problem occurs when two separate DSL-connected machines can successfully access the Internet, but they can not successfully access (ping) each other. If they are on the same US West local subnet, then the problem is known. A posting to the uswest.dsl newsgroup at news.uswest.net (by Xiphiplastron [xiphi@cyberdude.com]) describes the problem and a work around:

In article <35D4FE08.94B66938@ibm.net>, etkal@ibm.net says...
> It seems that systems on the same subnet using DSL cannot talk to each
> other. For example, a friend locally has a DSL line, and I cannot ping
> his system. Likewise, certain games, etc. will not work correctly,
> although they work to other users on different subnets. I can get to his
> web page from other outside locations, but I can't when I use DSL.
>
> USWest tech support says it is a known problem, but that they don't know
> when or if it will be fixed. Sounds like a routing problem, but can
> anyone post some technical detail as to what is going on here?

I haven't seen a response to this so I thought I'd put in my experience
with regard to this.

Not being able to ping others on the same subnet (not connected to your
LAN) is a "feature" of how they do things.  Simply put, if you try to
ping someone on your subnet, it's going to assume it doesn't have to go
through a router and try to use the ARP protocol to connect.  Since
you're only connected to the other user via a router, you need to set up
something in order to do this.

Assuming you're running Windows 95/98, you could open a DOS window and
execute instructions as follows:

If you're in subnet 123.123.123.xxx and your final octet is 100 and your
friend's is 101 and the router is (likely) 254 you'd do the following
command in your DOS window:

route add 123.123.123.101 mask 255.255.255.255 123.123.123.254 metric 1

Your friend would do the same except change the last octet in the first
IP address to yours.  to findo out the router's IP address, type ROUTE
PRINT at the command line and you should be able to figure it out from
the list of IP addresses.

Although the commands listed are for Windows95/98, adept users of other
operating systems should be able to figure out specifics.  I am curious,
however, if there's a way to do this on the Mac OS.  I'd appreciate any
info in that regard.

USWest.com: Intermittent Line Problems.

Line problems are a function of the connection between the customer's modem and the DSLAM at the CO.  One thing to check is the signal quality. The Cisco 675 reports a db reading.  This apparently needs to be greater than 17db to have a hope of a quality DSL connection, even for slow speeds (256k).  Levels above 25db give you a little more headroom. Another area to check is the amount of errors recorded.  Larry M posted the following in comp.dcom.xdsl:

Larry M wrote in message <366E918D.409F4E8A@pcisys.net>...

>High CRC (Cyclical Redundance Check) errors usually point to
>a bad modem, either at the CO (the ATU-C) or at the remote
>(ATU-R).  One thing you can do to test this is to unplug
>your modem and plug it back in (recycle it) a couple of
>times.  Do a "stat wan0" check each time you recycle it.
>Each time you do that (theoretically) you should train up to
>a different modem in the CO (unless the DSLAM is full).
>Look for big differences in CRC errors.  Which means you hit
>a bad modem in the CO.  To test your remote modem you could
>ask US West to send a tech out with a modem and compare his
>error rates with yours.
>High RS (Reed Solomon) errors usually point to cable
>problems.  Although high CRC errors can cause high RS errors
>also. 

USWest.com: Intermittent Solid WAN activity light, lasting 15 minutes or so (ARP Storms).

The following USENET article describes the ARP storm problem.

David Sandberg <mystic_fmSPAMJAM@excite.com> wrote in message
news:378f6243.4672602@news.uswest.net...
> Every once in a while I have a problem with my US West DSL line, where
> the line will suddenly become unusable for half an hour or more.
> During these periods the WAN light on my Cisco router (in bridging
> mode) is solidly on, and the LAN light is blinking constantly.
> Running "netstat -e" (under Windows 95) tells me that the only
> activity being registered is about 10 non-unicast packets received per
> second.  Nothing shows as outgoing, and the per-protocol statistics
> ("netstat -s") seem to indicate that no activity is happening at all.
> But during the periods of this activity I cannot access the Web, get
> mail or news, or anything else.
>
> This seems to occur once every couple of days, although sometimes I
> have had long periods without noticing the problem (like weeks).  I'm
> not sharing any system resources that could be accessed from outside.
> I've inquired with US West about this, but they made no effort to
> suggest any reasons or to track down what might be happening.
>
> Has anyone else experienced this?  Any ideas?
>
> --
> David Sandberg

I believe, from your description, that you are experiencing an ARP storm.
ARP storms are: 1) a known problem, 2) are experienced by others (the
problem is not limited to your experience/conditions), 3) there is nothing
you personally can do to address the problem, 4) are one of the main reasons
why US West is moving from bridging mode to PPP mode, and 5) there is
nothing you can ask US West to "fix" until your local pop is switched over
to PPP mode (that's the fix).

(Are you in bridging mode rather than PPP?)

I'm enclosing an explanation, previously posted by a US West engineer, of
ARP storms in a Cisco-DSLAM ATM environment.  It's a good explanation and
since this topic comes up fairly frequently, I may have to add this to "US
West problems" area of www.tuketu.com/dsl/xdsl.htm.

Randy Day-

--------start enclosure----------
Address Resolution Protocol - ARP is a function of how
a device finds the relation from a IP address to a physical network address
For instance, if your workstation has an ethernet address of
00:a0:24:5d:d8:ae
and an IP address of 215.216.16.6.  In bridge mode the router at .net will
have a
table of IP address to mac addresses.  There is also a bridge table that the
router keeps
that maps the ethernet address to the PVC over the atm network to that
workstation.

The ARP table need to be there so that the router knows how to talk to the
end
workstation at the ethernet layer.

What happens in these arp storms is the following:

Cisco has a feature/bug which say you cannot clear a single ARP entry from
the router.
You either clear the whole ARP table or nothing.

In Bridge mode the router has to have an ARP to talk to a remote IP device.

When it gets a arp it does not know what the ethernet address is, therefore
it also
does not know what the PVC is to send the arp request out.  So it sends a
broadcast
to all PVC for every single ARP.

To make a long story short,  When the whole ARP table is cleared, the router
has to rebuild the ARP table, so it sends a broadcast to every PVC for every
workstation
on the network.  In other words if you have 1000 PVC with 10 PC's on each
DSL
connection the router send 1000*1000*10 ARPS, 10,000,000 ARP's get sent out
to rebuild the whole ARP table, and yes these ten million ARPs go out to
EVERY PVC.

The router CPU shoots up to 100% for up to 10-15 minutes just to rebuild the
ARP table.

Why is USWEST clearing the ARP table??   They are not, they are just
maintaining the
IP addresses for customers.

Remove a static IP and the router clears the arp table.


This is the main reason there is a push to get away from bridging!

Bridging in this environment is not a scalable solution.

--------end enclosure----------

 

Case Study: Running a Web Server off a DSL Connection

As an experiment in DSL robustness,  I've been running the www.tuketu.com webserver off a DSL connection. The DSL connection is  640kbit/sec down, 272kbit/sec up.  uswest.net is the ISP and the IP configuration is determined by DHCP (the IP address is assigned by DHCP and free to change at any lease renewal). tuketu.com is a low volume server, getting about 500 users visits a day. The name service for the tuketu.com domain was initially provided by granitecanyon.com.   No software help is used to manage the relationship between the IP address and the DNS information. (i.e. nothing like dyndns.com or tzo.com)

tuketu.com had 5 major (longer than 2 hours) outages during fall 98 to late summer of 99 period.  It  had a number of smaller outages during this time period, the vast majority of the smaller outages being related to the administrator (me) mucking around with the web server (rebooting, etc). Very few of the smaller outages were related to DSL/ISP problems...and most of those were largely the result of ARP storms.

The major outages can be diagnosed as follows:

Case 1: DNS resolution problems.
The DNS service for tuketu.com was provided by an external third party, granitecanyon.com.   Granitecanyon.com is a free public service provided by some engineers with heart, but the robustness of their servers and the speed of their change mechanism leaves something to be desired. For one particularly bad two week period their name servers were out of sync, one providing bogus data while the other provided correct data. This impeded the ability of some users to connect to find tuketu.com.

Case 2: IP number changes, difficulties updating DNS information.
In this major outage, the ISP renumbered their IP network (probably to manage a shortage of IP numbers rumored to exist at the time in their local POP). This resulted in a new IP number being assigned by DHCP. (Even with a static IP provided by the ISP, the renumbering could have resulted in an IP address change.) Human monitoring noticed the new IP address in a relatively short period of time (several hours), and the new address information was then propagated to the DNS servers. However, it took about a week for the DNS servers to pick up the new information. For this week, connections to tuketu.com were problematic.  Several hours of this outage are attributable to the dependence on human inspection to notice IP address changes on the server. The remainder is attributable to DNS service problems.

Case 3: DSL hardware error.
After about 6 months of use, my DSL connection experienced a hardware error. It was eventually tracked down to a faulty modem in the DSLAM at the CO office. It took uswest.com about 10 hours to respond to the problem report and to track down the problem, but they did work past office hours to do so. The symptoms were actually rather difficult to interpret (WAN link light was OK, traffic could go upstream, but not down-stream), but uswest.com worked it out.  IP address assigned by DHCP server did not change after this outage.  Everything was up and ok after the hardware was replaced at the CO end.

Case 4: Webserver unplugged, IP number changes, difficulties updating DNS information.
In this case, the IP number assigned by the DHCP server changed. The reason for the IP address change is unknown, but it could have been the result of the Webserver host being unplugged and down for longer than the DHCP lease period (three hours). The problem in this case could not be diagnosed for several weeks, since the system administrator (me) was out of the country and not able to connect to the webserver for remote diagnostics.   When the problem was finally diagnosed, it was another week for the necessary changes to propagate to the DNS servers for tuketu.com (see case 2 above).

Case 5: DSL hardware failure at the CO end.
In a classic case of Murphy's Law, about 3 hours before leaving on a vacation, my DSL line went down. My Cisco 675 refused to sync up with the CO.  I called the problem in and got a trouble ticket, but US West failed to fix the problem during the two+ weeks I was on vacation.  The problem did not get fixed until I returned and bugged US West every few hours for a day.  After about 28 hours of nagging, US West did something that fixed the problem. I never got a report about what was wrong...my Cisco 675 just starting syncing again.  Total downtime: about 17 days.

Summary:

1. There have been 2 DSL-related problems during this period. The first was fixed in about 10 hours.  I was quite pleased with the response at the time.  The second was fixed in about 2 weeks and 28 hours....US West dropped the ball until I had time to nag them repeatedly to get the problem fixed.  Both DSL-related problems appear to have been equipment failure of some sort at the CO end.
2. Limited support.  I'm the only administrator. If I'm gone no one else fixes problems.
3. DNS-problems. The first DNS provider for tuketu.com was often down or slow to reflect DNS record changes.  The second DNS provider (myinternet.com) has proven to be a much more robust and trouble-free provider.
4. IP address changes. Using a DHCP-assigned address, even without any software support to coordinated IP address changes with my DNS server, has not directly been a major problem. The number of IP address changes has been small (2 in 7 months). Rather, the fallout from address changes has been great more because of the difficulty in getting the new address information into the DNS records for tuketu.com

The Future

The future will probably see the elimination of the POTS, particularly in the local loop. The high-speed bit-pipe into the home will be harnessed to carry both data and voice.  One example of this is the Sprint ION effort.

Sprint ION

Sprint introduced a service, Sprint ION, that heralds things to come. The first markets were Seattle, Denver, and Kansas City. The service had these interesting qualities:

Using VoDSL, Sprint's package is a complete replacement of the ILEC. Using a physical DSL connection to carry both voice and data over ATM, Sprint provides a dedicated high speed Internet connection (up to 8mbit down, 1 mbit up, depending on line quality), 4 voice lines, and unlimited phone service, both domestic long distance and local/local long distance (intra-LATA). (Well, at 750 minutes a month, this is close to unlimited for most people).  The charge is a flat monthly fee of about what a typical family would spend for multiple phone lines, long distance, and high-speed DSL.  The flat charge replaces any fees for local phone service, your long distance provider, and your high-speed Internet access.  The ILEC is effectively cut out of the picture...at last we see competition in the local loop.  The only revenue for the ILEC is whatever co-location charges and local-loop charges the ILEC is able to wring out of Sprint.  Does this strike fear in the heart of US West?

In the fall of 2001 Sprint discontinued the ION service. Economically, the service had been a bust. The technology was rolled out a bit prematurely, which meant Sprint could not promote it widely.  It also limited how fast Sprint could provision new customers.  Sprint ended up spending several billion dollars developing the technology and rolling it out. Exact numbers are hard to come by, but when the service was cancelled, it apparently had a few thousand customers, meaning an expenditure of probably more than half a million dollars per customer.  Ironically, by the time the service was cancelled, most of the bugs had been worked out of the system and most customers were passionate about the features, speed, and economic value of the service.

Forbes commentary on the Sprint ION network.

 

Resources

What follows is a fairly random collection of useful links that I've built up over time.

US West DSL related links	Some good information about PPP mode, configuring the Cisco 675	http://www.users.uswest.net/ ~rlutton/ADSL
	Good technical discussion on the Cisco 675 modem.	http://garyc.zoomtown.com/
	More Cisco 675 discussion and PPP/bridging discussion	http://www.users.uswest.net/ ~scottz/
	US West ICON database (CO information)	US West iconn database
	Cisco 675 NAT Configuration Program: A program that assists entering port ranges into the Cisco 675	http://ccheaven.virtualave.net/c675nat/c675nat.htm
DSL Devoted Sites	A general interest DSL site, with a sort of portal flare. Has some interesting multi-media links.  Has the annoying habit of disabling the "back" button.	http://www.adslexperience.com
	a site devoted to DSL	http://www.everythingdsl.com/
	An active site devoted to DSL.  Lots of news items related to DSL and a generally market following of the DSL trend.  Some good resource location information also.	www.dslreports.com
	An active site with lots of good news about happenings in the DSL industry.	www.dslprime.com
Home Networking	Lots of good information, including instructions for sharing an Internet connection.  Also has product reviews on home networking gear, including wireless.	http://www.practicallynetworked.com
DSL Diagram	Good diagram of the basic DSL setup	http://www.mynetwatchman.com/myNetwatchman/images/AdslVariables.gif
IFITL (Integrated Fiber in the Loop	Very good pictures and details about IFITL: detailing the connection from the user premise to the Internet backbone.	http://www.rayvaughan.com/bellsout.htm
PPPoE	Lots of good information about using/dealing with PPPoE	http://www.carricksolutions.com/index.htm

http://homepage.interaccess.com/~jkristof/xdsl-faq.txt is the xDSL FAQ page.

http://www.alliancedatacom.com/paradyne-dsl-tutorial.htm is Paradyne's excellent tutorial on DSL, with lots of details. The discussion is more geared for ISPs (or, more generally, network service providers) than end users.

TeleChoice's Report on xDSL is a comprehensive site for DSL information.

Whatis.com has a writeup on DSL, with a focus to providing a taxonomy of the various DSL types.

Paradyne's DSL Sourcebook is a detailed treatment of DSL, with a particularly good discussion of the network layers used to provision DSL (and the use of ATM as the popular backbone of choice for DSL).

http://www.nwfusion.com/edge/research/dslam.html is a good source for information on DSLAMs.

www.2wire.com has the slickest multimedia home page of any site with information about DSL. The information content is ok, but the best thing is the 2wire theater page, where you can download and play high-resolution video content.  Here's where your DSL connection shines: the video content is of such high quality (no flickering post stamps here), that it requires some sort of high-speed (384kbs or better) to view the content.

http://www.colorado.edu/infs/jcb/sinewave/network/connectivity/intro.html is a nice discussion of various Internet Connection technologies.

http://www.gofast.net/html/adsl_library.html is a good set of links about ADSL.

http://www.aspergantis.com/adsl/index.htm is another set of links about DSL. It's nicely organized.

http://www.alliancedatacom.com/isp-dsl-equipment.htm is information from a Seattle-based ISP about the xDSL equipment needs for ISPs using DSL.

Philip Philpov's Cable Modem page provides some enduser-oriented discussion of cable modems, including tips and tweaks for better speed. The discussion has some bearing for DSL connections.

Jeff Beardsley has a nice discussion of DSL, particularly GTE's DSL offering: http://home1.gte.net/jbeardsl/gte/

http://web.syr.edu/~jmwobus/comfaqs/serial-technology.html is John Wobus's compilation of remote access technologies.

See http://www.comrex.com/203.html for a good explanation of bridge taps.

www.sandman.com : an excellent site for telecom info and telecom tools and products.

The Telecom Digest, FAQ, and Archives (a wealth of information) is available at http://hyperarchive.lcs.mit.edu/telecom-archives.

http://www.inconnect.com/dsl/ for Internet Connect in Salt Lake City: alternative ISP and good information on US West's DSL service.

http://database.azstarnet.com/demo/owa/show_faq?in_faq_num=1 is an alternative ISP, name of StarNet. Their DSL FAQ is pretty extensive.

Copyright © 1998 Randy Day
Last modified: May 07, 2005