Skip to main content

Connectionless, Connection-Oriented and Cans of Corn

Oftentimes, you'll hear cable technologists describe 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 call ties up the spectral resource for its duration.

And it turns out that the notion of "connectionless" and "connection-oriented" data movement reaches well beyond cable's hybrid fiber-coaxial 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 especially matter now because of the ongoing scrape at Excite@Home Corp. — 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 together in boxes. They'd get placed on one of the train's freighter cars. Then, they'd move along a fixed and predetermined route to California. If something went wrong along the way, tough. Your corn waits. Rerouting isn't an option. On the other hand, all of your corn arrives at its destination, together and at the same time.

If you chose to ship your cans of corn by truck, however, their route can be innately 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, reroutes 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. The routers along the way (the drivers) can keep a constant eye on traffic conditions, and respond accordingly.

Both options, of course, have pros and cons.

Data that moves along connectionless systems — Internet-protocol and Ethernet, for example — can often arrive at its 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 access will head your way just as soon as packet-styled telephones start ringing. The voice-over-IP techniques being pursued by the cable industry are necessarily built on top of the Data Over Cable Service Interface Specification (DOCSIS) cable-modem spec — which is connectionless itself — so your network will need to make a transition 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.