Connectionless, Connection-Oriented and Cans of Corn
by Leslie Ellis // December 03 2001
Oftentimes you’ll hear cable technologists talk about data movement as “connectionless.” It’s their way of expressing the “always on” aspects of cable’s high-speed Internet service. The service is observably connectionless in that it doesn’t hiss, pop and poot, like dial-up Internet connections do.
There are also “connection-oriented” services in contemporary cable systems. Telephony, as it exists today, is one: A slice of bandwidth is “nailed up” between the cable phone and the companion equipment in the headend, a connection is made, and the spectral resource is tied up by the call for its duration.
And it turns out that the notion of “connectionless” and “connection-oriented” data movement reaches well beyond cable’s hybrid fiber-coax plant, into the part of communications networks known as the “backbone.” Backbones are a labyrinth of fiber optic lines and routers and switches reaching outward from the headend to, say, the Internet (as one example).
Backbones matter especially now, because of the ongoing scrape of Excite@Home – which, after all, started as a managed, high-speed backbone for cable’s collaborative use. “Managed” meant it was designed to sidestep the bandwidth clogs consistently associated with the public Internet.
While it’s not really necessary to be a guru on backbone techniques, it probably helps to know the basics about how data moves, after it leaves your network.
And this is where we get to the cans of corn.
If you were a farmer in Iowa, and you produced cans of corn for sale elsewhere (likely far away), you’d (obviously) need to ship those cans of corn. You’d probably have two options: Rail, or truck.
Let’s say you chose rail, and that your cans of corn need to get to San Francisco. They’d get packaged up together in boxes. They’d get placed on one of the train’s freighter cars. Then, they’d move along a fixed and pre-determined route to California. If something went wrong along the way, tough. Your corn waits. Re-routing isn’t an option. On the other hand, all of your corn arrives together and at the same time at its destination.
If you chose to ship your cans of corn by truck, however, their route can innately be more fluid. The driver, alerted to a mess along I-80, could slip south to I-70 and continue west. Or, let’s say some of your corn goes by one truck, and some by another. Maybe the first truck encounters a 27-car pile-up along the way, re-routes himself, and gets there later than the second truck. The corn all arrives, but out of order. The handlers at the other end sort it out.
In this corny example, the corn that moves by rail is connection-oriented. A piece of bandwidth – the railway – is nailed up, and is used solely to move those cans of corn.
The corn that moves by truck is connectionless – the route is adaptable, and responsive to changes in traffic. Routers, along the way (the drivers) can keep a constant eye on traffic conditions, and respond accordingly.
Both sides, of course, have pros and cons.
Data moving along connectionless systems – Internet Protocol and Ethernet, for example – can often arrive at the destination out of order. If those packets comprise a telephone call, you wind up with the symptomatic equivalent of saying “can hear me you?” Buffering is necessary.
Connection-oriented systems, like the ATM (Asynchronous Transfer Mode) developed by telecommunications experts, are great at maintaining consistency in packet transfer, but not so great at optimizing bandwidth. Because the “route” is fixed for the duration of a packet’s journey, that route can’t be used for anything else during that time.
The pros and cons of connectionless systems, for services other than high-speed Internet, will head your way just as soon as packet-styled telephones start ringing. Because the voice-over-IP techniques being pursued by the cable industry necessarily build on top of the DOCSIS cable modem specification – itself connectionless – a transition will need to happen in your network, from connection-oriented, to connectionless.
The underpinnings of connectionless and connection-oriented data engineering are layered in theory. Translation: With the right techs and the appropriate libations, you could talk this stuff until you’re blue (or, more likely, green) in the face. The pros and cons of data transport are one of those chewy engineering debates that go way back.
No matter how you attempt to sort it through with your in-house technologists, the answer (I bet you a dollar) will be “it depends.” That’s because there is no blanket “right” answer. What matters most is knowing how to think it through.
This column originally appeared in the Broadband Week section of Multichannel News.