AOL Poses a Tunneling Conundrum

Author:
Publish date:

Last week, as the rest of the nation endured the last of the election frenzy, AT & T Broadband quietly fired up its "Broadband Choice" tests at its Boulder, Colo., system. Meanwhile, Time Warner Cable quietly continued testing what it calls "multiple ISP" (MISP) access in Columbus, Ohio.

To the north, Canadian MSO Rogers Cable continued monitoring a 2-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: Allowing outside Internet-service providers (ISPs) to offer a faster connection to their customers by riding on cable's swift lines.

Meanwhile, federal antitrust watchdogs reportedly gave the issue another vigorous shake last week, saying they'll block Time Warner Inc.'s merger with America Online Inc. if the two don't formalize and expand their open access plans. In defense, Time Warner and AOL told the Federal Trade Commission 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 Online Services Inc.)

Ironically, AOL may need the head start. As it turns out, the architecture of its 25-million-plus subscriber network isn't exactly a natural for a cable environment.

Why? AOL uses a method called "tunneling" to connect each of its customers' PCs to its web of servers. Technically, tunneling 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. Each data packet isn't just 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 tunnels: electronic mail, instant messages, chat, Web-page requests. Suppose you point your AOL browser to
www.multichannel.com

. The packets comprising your request are encrypted at your PC, encapsulated and sent to an AOL server. That server says, "Ah, I see a request for
multichannel.com

from so-and-so."

It fetches the page, encrypts it, encapsulates it, and tunnels it back to you. You never ping the
multichannel.com

server directly.

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 are 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.

But 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. The packets can also be nailed up to a consistent bit rate for a period of time for, say, 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 tunneled environment, accessing local stuff flings the request for it back to AOL, which then fetches it. The data map resembles a hairpin when a hyphen would do.

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 ways to work around this, 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.

Related