Eric A. Hall

Home >> Article Archives >>

A Reversal of Fortunes

A couple of weeks ago, I got ADSL service installed at my home office, and let me tell ya', the DSL market is so complex that you have to study it before you do anything. There are a variety of services, equipment, and architectures in use, each of which have to be learned before you can make any sort of reasoned decision about which service to buy into.

And after I got it all working? Well, the service is great for the most part, but not always. Now the problem isn't the limited bandwidth at my site, but the limited bandwidth at the content provider's site (this means you). This must be fixed before we can expect to accommodate millions of high-speed users.

All About DSL

If you're not already familiar with DSL technologies and how the market is segmented, here's a brief tutorial.

Conceptually, DSL is fairly simple. It's a point-to-point service that runs over standard telephone wires. It uses frequencies at the high end of the spectrum to provide a high-bandwidth carrier signal that other protocols (like IP) can run across, although the distance is limited as a result of the shorter life-span that higher frequencies have. Also, the high-end frequencies don't interfere with lower-end frequencies, allowing plain old telephone service (POTS) to coexist on the same copper pair. This lets you talk on the same telephone line that you're using to pull down video images.

In practice, however, it's not so simple. In order to use DSL for Internet connectivity you have to get wire pulled, buy DSL service to run over the wire, and get Internet service from an ISP that supports the same flavor of DSL used by your provider. Each of these realms offers a variety of choices, meaning that the equipment you buy from one ISP for use on one DSL vendor's network may not be usable with offerings from another DSL vendor or ISP. You'll be stuck with whatever you buy, so pay attention.

To start with, there are many different flavors of Digital Subscriber Line technology. The one I have, and the one that will probably be the most popular for a while, is Asymmetrical DSL, or ADSL for short. The most common implementation of ADSL provides three channels between your site and the DSL provider. One channel is a high-speed download circuit capable of anything from 32 Kbps to 8 Mbps, while another channel provides a medium-speed up-link capable of speeds ranging from 32 Kbps to 1 Mbps. You'll also get a POTS channel that you can use for voice, if you buy ADSL from somebody with access to the public switched telephone network (ie, the telephone company). All this comes over a single pair of copper pulled from the telephone company central office to your site, and plugged into a "splitter" that separates the different channels into their distinct frequencies.

Microsoft, Compaq, Intel, and a bunch of other people who have no business in this space have been pushing for "Universal ADSL," sometimes referred to as "DSL lite" and "Consumer DSL (CDSL)." Universal ADSL is a scaled down version of regular ADSL, offering a maximum 1.5 Mbps down-link and 128 Kbps up-link, although most of the early offerings seem to be in the 384/64 range. The benefit of Universal ADSL is that it won't require a splitter at your site. You'll just plug the phone and computer into a single (existing) telephone jack.

At the high end, "High-Speed" DSL (HDSL) provides a symmetric, high-speed (1.5 to 2 Mbps) link over standard telephone wiring. HDSL is comparable to T1 service, but without the 24 multiplexed voice channels. It's one big data channel, with no voice functionality per-se. Indeed, if you were to buy a T1 line for your company's web site today, you might actually get HDSL and not even know it.

There are other variations, including things like Rate-Adaptive DSL, ISDN DSL and "Very-High-Speed" DSL (VDSL), but these technologies are not likely to be as successful as ADSL and HDSL.

But wait, there's more! Not only are there different flavors of DSL, there are also different methods of encapsulating data into these different flavors. For example, some vendors are supporting an encapsulation format called DMT (Discrete Multi-Tone Modulation), while others are supporting CAP (Carrierless Amplitude Phase Modulation). Although both technologies are based on QAM (Quadratic Amplitude Modulation), they're sufficiently different so as to be completely incompatible. This is like the 56k encapsulation wars, only much, much worse. The only good news here is that DMT appears to be winning, having gained support from the international standards bodies.

It's still a mess, though. Any of the products offered for any of these technologies are just barely interoperable with any of the others, if at all. Since each of the vendors are backing different flavors of DSL, and are also backing the different encapsulation techniques used by them, the DSL modem you get is almost guaranteed not to work with another vendor's equipment. Caveat emptor.

DSL Providers

Here in the Bay Area there are three providers of DSL service. Pacific Bell provides their FasTrak DSL service, which allows you to run the DMT-version of ADSL over an existing POTS line. If you've got a phone line already, you can sign up for the service, buy and install the requisite splitter and modem, and be up and running within a few days. You can get symmetrical 384/384 Kbps access, or 1.5 Mbps/384 Kbps asymmetrical access (the package I bought), at residential and business rates.

Covad and Northpoint are the other two vendors, offering non-integrated service, meaning you'll need to get a new copper pair pulled from the central office in your neighborhood to your local site. Although this isn't a very big deal, it adds to the installation time. It also means you won't get a POTS channel like you dow with Pacific Bell's ADSL offering, since these two vendors don't have access to the PSTN. Alternatively, you can get IDSL, SDSL, and a wider variety of ADSL speeds from these vendors. Another note: unless you're looking to wire up a good-sized building, you probably couldn't order service directly from Covad or Northpoint anyway, as they prefer to sell individual-class circuits through their ISP partnerships. In all likelihood you'll end up ordering service through an ISP anyway, so this is irrelevant unless you're looking for a big fat pipe.

In the end I went with Pacific Bell. One reason was availability, as I couldn't get service from Covad or Northpoint until later this year. Another reason was my desire to get rid of ISDN and revert back to analog POTS lines, and by going with Pacific Bell I got access to the voice network over the ADSL line.

This may seem odd, my wanting to get rid of ISDN and revert back to POTS, but market conditions have dictated this effort. Just as I'm forced into using Windows NT because that's where the third party product development action is, I'm forced to use POTS if I want to explore voice-over-IP, or any of the most common computer-telephony products like voice modems and software-based PBX systems. There is such a dearth of ISDN-aware telephony equipment that I'm forced to have multiple POTS lines in order to play with any of the leading-edge products. Another disadvantage of ISDN over POTS is the per-minute residential pricing. Why pay more for less functionality?

Since I didn't have a POTS line in place (I only had ISDN), I had to get a new copper line installed for the ADSL service. I then put the splitter on the new line, ran the inside wiring, rigged up the POTS jacks and the DSL modem. Although I could have paid a contract outfit to do this work, I chose to do it myself, and it only took a couple of hours. It certainly wasn't any more difficult than any network wiring I've done in the past.

Internet Service Providers

With modem and ISDN calls, everybody's connections get routed over the same voice network. A circuit is established between the user's equipment and the telco's switch, which is then routed to the modems and ISDN terminal adapters at your Internet service provider's office. There's only one network in this model.

But with DSL, your connection doesn't ever touch the PSTN (unless you're buying voice service as well, which is routed separately at the phone company's central office). Instead, the "circuit" gets handled by equipment at the line's termination point, much as it is with T1 service. Rather than going into the voice network, DSL circuits are passed to packet-centric networks like PacBell's ATM cloud, or Covad's network, or Northpoint's network, etc.

In order for an ISP to provide you with DSL service, it has to buy connections to the same data network that you're on. Some ISPs buy access to all of them, while some only buy into one or two of them. Since I was buying time on Pacific Bell's network, I had to find an ISP that was also wired into PacBell's ATM cloud.

You might think that I would just look to Pacific Bell to provide the Internet connectivity portion of my service, since they would also be providing me with the DSL service and phone line. However, Pacific Bell's Internet access division does not currently offer a package that is appropriate for my needs. They only offer a single-IP connection much like their personal ISDN and dial-up Internet services, but since I have a LAN here with a dozen or so devices, I need a subnet of my own. Pacific Bell's Internet group is working on a plan for this type of installation, but they don't have one that I can buy yet.

Instead, I went with Concentric Networks, a top-tier Internet provider with a nationwide high-speed network and a well-deserved reputation for advanced network services.

The Morning After

Changing all of my Internet services from Brainstrom (my ISDN ISP) to Concentric was a bit of a hassle, although no more so than any of the other times I've switched providers. Renumbering devices, updating the nameserver entries at Network Solutions, changing DNS information for the root nameservers, etc., was about the trouble you'd expect from such an effort.

Another dimension was also added by the overall newness of the technology. For example, I had to get a block of addresses from Concentric, who also had to get new addresses from the American Registry for Internet Numbers (ARIN), the authority that doles out blocks to top-level ISPs. I was given three different blocks of addresses before we found one that everybody liked.

Another set of problems cropped up with overall stability issues. Since Pacific Bell is only offering DSL on a trial basis, many issues and procedural operations are still being worked out. In the two weeks I've been on-line, I've had my service interrupted over a dozen times. These interruptions have been tracked down to "unscheduled testing" of the T3 circuit between Concentric's NOC and Pacific Bell's central office. The problems have stopped - for now - and things are working pretty smoothly, but I expect to have more of these problems rather than less of them, at least for a short while.

I've also had to deal with security issues related to my being on a bridged connection instead of a routed one. You see, once the local DSL pair gets back to the central office, it goes into a DSLAM (DSL Access Multiplexer), which is effectively a modem bank at the local central office. The DSL modem provided by Pacific Bell is an ATM-Ethernet bridge, meaning that I'm sharing my network traffic with everybody else on that DSLAM.

These concerns can be addressed partially by the DSL service provider, who can put together filters that keep the ports from seeing each other, and also partly by the ISP, who can write IP-specific filters that prevent broadcasts and the like from propagating. However, there are still concerns about bridging that haven't been addressed to my satisfaction. Of course I use a firewall here, so I'm able to block all traffic coming from the bridge. A casual user probably wouldn't have a firewall though, so it's important to look at this before you rush headlong into an arrangement.

It should also be pointed out that these concerns are a direct result of the way that the Alcatel DSLAMs and modems that Pacific Bell use are ATM-Ethernet bridges instead of routers, and this problem isn't necessarily indicative of DSL. For instance, Covad uses DSLAMs from Diamond Lane Communications and routers from FlowPoint, which provides for a routed ATM-Ethernet connection that is more palatable to security-sensitive businesses (although I still suggest a firewall be used, of course).

It's Great! (Sometimes)

After getting it all worked out, I've got to say that the performance is truly great, when I'm able to get it. Most of the time I get excellent throughput, and visitors to my web site have also reported substantially snappier responses as well. This makes it a win in my book.

The biggest issue is that "most of the time" clause. For example, over this weekend I was able to download the entire 12 megabyte distribution of Internet Explorer 4.0 for the Mac in just over 2 minutes, resulting in overall throughput around 100,000 bytes per second. But earlier today I tried to download the same file and got less than 60,000 bytes per second, resulting in a download time almost 4 minutes long. Likewise, I was only able to download the 18 megabyte distribution of Netscape Communicator Pro 4.05 for Windows in about 5 minutes, providing an overall throughput of around 55,000 bytes per second. Still good, but not great.

So what made the difference? Well, oddly enough, the problems are congestion and bandwidth at the back-end, instead of at my site. With 1.5 Mbps available to me, I'm now able to exceed what many sites can give. All of a sudden, my local connection isn't the bottleneck, but instead the never-before-seen problems of latency, large hop-counts and back-end bandwidth are all much more visible.

Whoa! For years people have been saying "when we get better bandwidth to the user..." and other such nonsense, conveniently ignoring the fact that they couldn't handle all of us in the first place. Sites that want to take advantage of my last mile (and the million other users coming behind me) are going to have to add lots more bandwidth. There's no way you'll be able to keep us coming back if all we get is a few Kilobytes per second.

Video-Over-IP Doesn't Play

Here's another example. With 1.5 Mbps, I should be able to watch TV-quality video over the Internet. Unfortunately I can't, due partially to lousy back-end bandwidth, but also due to a lack of high-quality feeds. Even those sites with plenty of pipe aren't providing the rich content that I can take advantage of. The following table shows the average performance for watching video clips over the net. You tell me if this is acceptable.

Television signals run at 30 frames-per-second. The average FPS rate for the videos I looked at was around 8, which is miserably choppy, and just barely acceptable. The three worst performers—Fox, CRN and PC Week Radio—were absolutely horrific. Given a choice between watching videos at these sites versus any other site with higher quality feeds, which do you think I'll choose?

Lousy video is a result of several factors, each of which are specific to this application. First of all, the videos themselves were often sampled at very low rates. Fox News samples everything at 5.5 FPS, so even though I got 100% of the frames, the resulting image was crap (100% of crap is: 100% crap). In order to get higher resolutions, those of you who provide video streams are going to have to start offering higher-quality sampling rates, with at least 15 FPS. Many sites offer both low- and high-quality feeds for users with different capabilities, but not all of them (most notably Fox News, and CRN, both of whom only offer low-quality sample rates).

Another angle to this is that the media servers have to reserve (and use) more bandwidth for their feeds. Most of the sites I looked at only provide a 21 Kbps pipe, which isn't enough to push more than a few frames at a time. The feeds from Pseudo and PC Week Radio were both highly susceptible to loss and interference, due to the limited amount of pipe available.

On the other hand, Film.com's on-line interview with Denis Leary had a 100 Kbps feed, which I was able to receive at the full 15 FPS, providing a very-high quality signal that was almost comparable to TV. This is who you need to emulate. Offer multiple feeds at multiple speeds, allowing those of us with the big pipes that you've been asking for to enjoy the experience.

A Reversal of Fortunes

Providing 100 Kbps feeds is probably hard to justify in the age of dial-up users. But that illustrates my point exactly. What I'm seeing is that the back-end isn't ready for an onslaught of high-speed users. By removing the bandwidth restriction from my leg of the journey, the problem focus shifts to the back-end sites like PC Week Radio, who just can't give me content fast enough. With 28.8, I don't know any better, but at 1.5 Mbps, I can see quite well who's giving me quality and who isn't.

And this is just the tip of the iceberg. There's a whole new world of products coming in to take advantage of this new bandwidth, ranging from voice-over-IP products like TouchWave's WebSwitch and Selsius' H.323 phones, to video-over-IP products like Microsoft's NetMeeting and Intel's Create and Share. Users of high-speed services are going to want to use these products, and ISPs like Concentric are doing their best to provide quality-of-service guarantees and the services required to fulfill those needs. Now it's up to the back-end systems to provide the high-quality content and bandwidth needed to make the overall experience worthwhile.

Want to offer interactive customer support over IP, using your web site and off-the-shelf tools? You'd better get an OC-3. That pip-squeak T1 ain't gonna cut it any more.

Home | Articles | Books | Specifications | Software | Personal | Search