AOL’s Tunneling Conundrum
by Leslie Ellis // November 13 2000
Last week, while the rest of the nation endured the last of the election frenzy, AT&T Broadband quietly fired up its “broadband choice” tests in its Boulder, Colo. system. Time Warner Cable quietly continued testing what it calls “multiple ISP” (“MISP”) access in Columbus, Ohio. To the north, Canadian MSO Rogers Cablesystems continued monitoring a two-year-old government mandate for the same thing, which they call “third party residential internet access,” or “TPRIA.”
The four labels – open access, broadband choice, MISP, TPRIA – all mean the same thing: Letting outside Internet service providers (ISPs) offer a faster connection to their customers by riding on cable’s swift lines.
Meanwhile, federal antitrust watchdogs gave the issue another vigorous shake last week, saying they’ll block Time Warner’s merger with America Online if the two don’t formalize and expand their open access plans. In defense, Time Warner and AOL told the Federal Trade Commission that they’ll stunt a potential AOL head start by not letting the online giant ride Time Warner’s broadband plant until at least one other competing ISP is there, too. In Columbus, that entity is to be Juno.
Ironically, AOL may need the head start. As it turns out, the way AOL architected its 25 million-plus subscriber network isn’t exactly a natural for a cable environment.
Why: AOL uses a method called “tunnelling” to connect each of its customers’ PCs to its web of servers. Technically, tunnelling is a protocol. A protocol is a language spoken by electronic bits travelling along a network.
Here’s how it works: When a customer logs in to AOL, a secret tunnel is instantly built between that PC, and the AOL network. Not only is each data packet encrypted (as is cable modem traffic). Each packet is also encapsulated. Encapsulation is the electronic equivalent of the plain, brown wrapper. The only visible parts are the packet’s source (who am I?) and its destination (where am I going?). Everything else is tucked inside the tunnel.
In AOL, all traffic moves in tunnelsl: E-mail, instant messages, chat, Web page requests. Say you point your AOL browser to multichannel.com. The packets comprising your request are encypted at your PC, encapsulated, and sent to an AOL server. That server says, “ah, I see a request for multichannel.com particular web site from so-and-so.” It fetches the page, encrypts it, encapsulates it, and tunnels it back to you. You never directly ping the multichannel server.
By contrast, the data packets that move to and from cable modems are encrypted, but not encapsulated.
This isn’t so much of a big deal in cable’s current ISP tests. Because there’s so many other components that need to be created, and because the service goal is limited to Internet access, AOL’s tunnels aren’t the end of the world.
However, when “broadband choice” evolves to mean multiple ISPs providing multiple IP services over cable’s plant – think Internet, plus voice, plus streaming services, for example — AOL’s tunnels could become a problem.
DOCSIS 1.1-based cable modems, which enter the market next year, bring the ability to do more than just speedy Web surfing. MSOs can mark packets as higher priority if, for example, they comprise a phone call. Or, the packets can be nailed up to a consistent bit rate for a period of time, say, for a streaming event.
But if AOL’s traffic rides in a secret tunnel from the home to its servers, how do cable providers see and pluck off the prioritized traffic? Think about what this means for things like local content, multicast events, or IP phone calls. In a tunnelled environment, accessing local stuff flings the request for it back to AOL, which then fetches it. It’s travelling the shape of a hairpin, instead of a hyphen. Ditto for a local, IP phone call. Phoning your neighbor on a future IP cable phone means sending the dialed digits through AOL’s tunnel, to AOL, in Virginia. There, AOL disassembles the tunnel, sees the IP voice bits, and presumably sets up the call. The words “complicated” and “inefficient” come to mind.
There are workarounds, of course. One option is to tear down the AOL tunnel at the headend, extract any prioritized traffic, and make it do what it’s intended to do. Requirement: More headend stuff. Another option is to give all AOL packets a high priority. Result: Inefficient bandwidth usage.
For now, this is more of a problem for AOL than it is for cable MSOs. The matter of AOL’s tunnels isn’t likely to land on the FTC’s to-do list, either: If anything, it hurts AOL more than it hurts outside ISPs. But it’s worth watching, and watching carefully, if for no other reason than AOL’s presumed spot at the helm of the No. 2 U.S. cable operator.
Consider: There are at least five things that don’t yet exist, but are critical for a multiple ISP environment. Necessity being the mother of invention, AT&T and Time Warner (and any other MSO wishing to test multiple ISPs) are building these five things themselves.
First is the screen that shows customers which ISPs they can pick. AT&T calls this a “service agent.” Second, there’s the traffic cop – the software that tracks which ISP is using how much bandwidth. Technologists call this a “mediation engine,” and view it as a way for MSOs and ISPs to color within the lines of the service agreements they forge with one another.
Third, there’s those ever-snarly billing links. Look at it logistically. Ten ISPs could mean 10 different billing systems; 10 different billing systems means 10 different required interfaces. MSOs will need to take the information tracked by the mediation engine (the traffic cop), and mete it out in an electronic format that the various ISPs’ billing systems can use.
Fourth, there’s trouble-shooting and conflict resolution. Say an AT&T Broadband customer, using AOL’s service, can’t access mail. Is it AT&T’s network, or AOL’s mail server? Who fields the call? Who fixes it? Who lets that end customer know what’s wrong, and when it’ll be corrected?
And lastly, there’s a specific equipment need. It’s known interchangeably in technical circles as a “source-based router” and a “policy-based router.” It’s needed because today’s cable modem traffic only knows one thing: Where it’s going. The destination. But, in order for MSOs to know which customer is connected to which ISP, the source of the packet becomes a necessity. This router sits at the Internet-end of the CMTS (cable modem termination system, the headend piece of cable modem networks).
Cable’s work to pry open their own networks, without donning a “common carrier” label, is perhaps the year’s most significant bit of technical pioneering.
(The use of source-based routing may come into question if the AOL/Time Warner merger proceeds. AOL’s dial-up network uses an alternative method to source-based routing, known as “tunneling.” Although Time Warner’s trial work will use source-based routers, it’s likely that AOL will have something to say in the matter. Source-based and tunneled routing methods aren’t mutually exclusive, but using both could require extra equipment, and could limit AOL’s ability to offer services other than high-speed data.)
This column originally appeared in the Broadband Week section of Multichannel News.