Sessions Matter More Than ‘Thick Vs. Thin’
by Leslie Ellis // December 01 2000
The Halloween candy isn’t gone yet, the Thanksgiving feast is showing up on the bathroom scale, and we’re headlong into the high-caloric holidays…which brings to mind the ongoing talk about “thick v. thin clients.”
First, some basics. When people say “thin client,” or “thick client,” they’re talking about the digital set-top box. This is “client” as in “client-server.”
Second, thick v. thin has less to do with physical size than it does with capabilities: How much processing power, graphics capability, and memory resources are available.
Third, “thin versus thick” is really a supplier-inspired way of delineating “now versus next.” Thin is now. Thick is next. Because time is relative, what’s thick today is thin tomorrow, and what’s thin today was thick yesterday.
In today’s environment, “thin” correlates to Motorola’s DCT-2000 line, and Scientific-Atlanta’s Explorer 2000 line (including all clones). “Thick” describes both manufacturers’ more advanced boxes: Motorola’s DCT-5000, and S-A’s 6000/8000 series.
Fourth, there will always be the thick and the thin. Six of cable’s top-7 operators (Cablevision excepted) operate services on “thin” boxes to an aggregate 6.8 million U.S. households, as of September 30. They’re installing “thin” units at a combined rate of about 114,000/week.
Always seeking metaphor, I offer this: “Thick versus thin” is like Americans. Generation by generation, we get taller and heavier. Photographs of ancestors show smaller, shorter people; your grandmother’s china hardly seems big enough to hold today’s ample servings. You order a cup of coffee in another country, and embarrass yourself with your surprise at its thimble-like capacity (at which point you know for sure that you are an American).
Ditto for set-tops. Motorola’s DCT-1000 was gigantic compared to the various analog units that constituted the set-top landscape, in 1995. Those very boxes, grandfathers now to the beefier DCT-5000, seem tiny by functional comparison. And yet, some already view the DCT-5000 as emaciated.
Somehow, we’ve all gotten wrapped up in the debate, while avoiding the steeper slope. Thick versus thin is an issue, but it is not the issue. Client-server is the issue. That’s the new part, and the challenge. It is the sessions between the box and the server that matter, because “thin’ is a given.
Think of the “now:” The 6.8 million digital boxes deployed by AT&T Broadband, Adelphia Communications, Charter Communications, Comcast Corp., Cox Communications, and Time Warner Cable. They present more channels, and a navigational aid. The channels are compressed with MPEG-2, imprinted into a Quadrature Amplitude Modulation (QAM) transmission path, broadcast to the box, decompressed, and presented to the TV. The guide, in most cases, is a permanent resident in the box. No client-server activities exist, for the most part.
People who say they run on the “now” usually mean they’ve devised a way to make the box do sessions with their software, which is located elsewhere. Some call this a “virtual channel” environment. In some cases (think WorldGate, or Ron Pitcock’s new venture, Integra5), this means they’ve made their application behave as though it’s an MPEG-2 video channel.
In other cases (think all middleware providers), a built-to-fit software module sits in the box, acting as both interactive storefront and traffic cop to various, remote interactive applications.
The “next” will be video on demand (VOD), cable’s first major push into session-based interactions. VOD will pave the way for other types of interactive sessions, many of which will be tested throughout the U.S. and Canada next year.
The name of the game is and will be establishing how many simultaneous interactive sessions a box can handle. Executives with Scientific-Atlanta visited recently, to describe a chart they’d developed using deployed digital set-tops numbers. A blue line shot straight up, starting in March (not coincidentally when Time Warner turned on the digital set-top spigot). Under it was a flatter green line, depicting the number of deployed boxes capable of doing multiple, simultaneous interactive applications. The implication: The green line is about to fork wildly up, in lockstep with the blue line.
Yet, a few months back, I spoke with a cable engineer who expressed great glee at getting both Wink and WorldGate to run on a single digital set-top box, of the “thin” variety. This is where we are: Two. If it’s true that you can never be too thin, then it’s a matter of adding more without exhausting the very resources that make you skinny.
Until the thick boxes start rolling in, it’s probably wise to examine what you can do with what you already have. Tally up the resources under the hood of the boxes you already have. Compare it to the services you want to launch. Think sessions. You already are thin, with thick on the way. And once you’re thick, you’re too thin for the next stuff. If only this worked anatomically…
This column originally appeared in the Broadband Week section of Multichannel News.
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.