QoS and DQoS: Spinach Before Dessert


Sometimes, technology is like green leafy vegetables — spinach, for example. Some find it distasteful, yet it's crammed with the minerals and healthful stuff that make your insides work better.

Where I grew up, you had to eat it before you could have dessert.

Two acronyms, "QoS" and "D-QoS," are the green leafy vegetables of this week's technology translation. Neither technique is the most comprehensible in the world; both make broadband Internet and voice-over-Internet protocol (respectively) work better. And you can't easily get to the sweetness of new, revenue-bearing services without them.

"QoS" stands for "quality of service." Before its variant, D-QoS, came into being, "QoS" was pronounced as its three component letters.

But when that "D" (for "dynamic") was hyphened onto the front, people began pronouncing both D-QoS and QoS as a word: "Dee-kwoss," as in, rhymes with "pea sauce," and "kwoss," as in, rhymes with "floss."

QoS and D-QoS are directly tied to the inner workings of the IP side of the house. Both share a common tenet: Not all packets are created equal.

Specifically, QoS relates to broadband Internet/cable modems, as a major component of Data Over Cable Service Interface Specification (DOCSIS) 1.1. It's important because it's the mechanism for adding broader, more automatic "tiers" of data service (as translated in the Sept. 16, 2000 and Aug. 8, 2001 editions of Multichannel News.)

Right now, D-QoS is mostly anchored to voice-over-IP (VoIP) as a major component of Cable Television Laboratories Inc.'s PacketCable 1.0 specification. Specifically, it sets up and tears down the unique type of bandwidth necessary for voice-over-IP calls: Bandwidth that is rigged to protect its contents from timing delays, so packets that make up a live conversation don't arrive out of order. Engineers call this "isochronous" (eye-sock-roh-nuss) communications.

QoS, then, provides a method to automatically upshift a cable modem to a higher priority level. Once. As an upgrade.

D-QoS automatically adjusts bandwidth priorities many times a day — and on the fly, depending on what's happening. To the consumer, it's what happens behind the scenes each time a VoIP call is made or received.

D-QoS, in essence, is like a bandwidth supercharger. It senses a need for a higher or different grade of bandwidth, based on whatever the customer is trying to do. It then makes that bandwidth available for the duration of the need. D-QoS is like the biceps that Popeye suddenly sprouts after he glugs the can of spinach: They last as long as Bluto is bothering Olive Oyl.

What makes both techniques work is a fairly elaborate system of electronic reservations. Aptly, the reservation system is known in network software lingo as "RSVP," for "resource reservation protocol."

In QoS, it works sort of like this: The cable modem inserts an RSVP flag into a load of packets it plans to send to the headend CMTS (cable-modem termination system), indicating that it wants to subscribe to a higher grade of service. The CMTS, instructed to be on the lookout for RSVP flags, sees it, and sends it off to a processing server for handling.

D-QoS is a little different. For starters, it only encompasses VoIP applications so far. (The operative thinking here is to make small, evolutionary steps. Just getting D-QoS to work for VoIP is pretty tricky, yet its fruits will likely be applicable to other multimedia IP applications, such as video streaming.)

PacketCable birth

Secondly, D-QoS — by nature of its birth from within the PacketCable 1.0 specification — is steeped in the already acronym-chunked parlance of telephony. On its own, that requires someone to tug forward their knowledge of PacketCable lingo: Especially the "MTA," or "multimedia terminal adapter," a sort of cable modem with phone jacks.

That said, D-QoS works sort of like this: An MTA goes off-hook — techspeak when for you pick up the cable phone. This creates an elaborate integration dance, known in tech lingo as "setting up a flow."

Setting up a flow involves the MTA and at least three other pieces of equipment: the CMTS, to set up and tear down the isochronous path; a "soft switch," to place the call to whomever you're calling; and a "call management server," or "CMS," to authenticate and provision the call.

Some of these tasks are part of an augmented version of RSVP protocol, specific to D-QoS, and known interchangeably as "extended RSVP" and "RSVP-plus."

If it sounds pretty tricky, it is. "Easier said than done" is the consensus coming out of MSO experiments with D-QoS technology so far. In fact, neither QoS nor D-QoS will see a whole lot of action, outside of field tests, until the installed base of CMTS units are upgraded to DOCSIS 1.1 — a process that's just now beginning.

In spinach terms, the seeds are just now going into the dirt.

Questions? Suggestions? E-mail Ellis299@aol.com.