The Countable Blessings of Cable’s Engineers
by Leslie Ellis // November 25 2002
This being the week of Thanksgiving, it seems timely to give a few column inches of thanks to the broadband engineering community.
That said, being true to the title of this column means translating something, not wasting space with gushy gratitudes. To stitch the two together, this week’s translation intends to show, by example, the countable blessings about our engineering community.
Stereotypically, engineers get tagged as being introverted, geeky, and aloof. But stereotypes, as a general rule, tend to huddle people into clumps of unconstructive attributes, which is bad for forward progress. Engineers don’t like to be labeled “dweebs” any more than marketers like being labeled “wiffleheads.”
Those of us who study the language and work of this industry’s technologists know them to possess lots of constructive attributes. We know them as problem-solvers. Innovators. Seekers of truth.
And, in so many instances, engineers are wickedly comical. Consider a Western Show session three years ago, when Leo Hindery (then TCI’s top banana) began describing a triangle of benefits aimed at cable customers. He raved that the triangle was about to start spinning, faster and faster — all the while drawing tight circles in the air with his index finger. Cable’s customers, Hindery said, were about to go through the spinning triangle into a magical world.
A certain unnamed engineer, sitting next to me, drew an exaggerated drag on an imaginary non-tobacco cigarette, emitted a few suppressed coughs, and mimed handing it down the row of attendees.
Engineers are funny.
Yet, there’s the language of the technical community – so inscrutable, sometimes.
Not long ago, a friend overheard me describing tech people as “reliable providers of straight answers.” She harrumphed. “If ‘it depends’ is what you consider a ‘straight answer,’ ” she grumbled.
True, conditional answers can make you crazy. “It depends” is a perennial classic. Or, on the vendor side, a shrug, followed by “it worked in the lab.”
Translation: “It worked in the lab” is very often a euphemism for “calm down, I can’t focus when you’re spazzing,” or “I need more information before I can help fix it.”
The “it depends” translation is a little more tricky, because most times, it really does depend. Pat, one-line answers are exceedingly rare.
Plus, “it depends” buys a little neurotransmitter time to run the query through the labyrinth of possible answers. Maybe it depends on whether you’re talking about the Des Moines or the Jefferson City system, which may use completely different equipment – or whether you’re talking about a Motorola or Scientific-Atlanta deployment, which work differently. And so on.
That’s a long way of saying, engineers aren’t trying to drive you batty with “it depends” any more than you’re trying to drive them batty with your informational needs.
As for innovation and problem-solving: Consider the evolution of the contemporary cable system. Just over the last 10 to 15 years, it is cable’s engineers who innovated with fiber optics, to create more bandwidth, and to decrease outages.
It is cable’s engineers who turned digital video compression into digital cable service; ditto for the two-way plant necessary for broadband Internet service.
And then there’s the whole world of IP (Internet Protocol) communications, underpinning both broadband Internet and voice services, and who knows what else to come.
Just think of what you had to work with 15 years ago, versus now, and the value of the engineer should start to come into focus.
If not, or if you’re dealing with a particularly stereotypical engineer, ask a few questions. “Whaddaya working on these days” is a good start. Listen to the answer. If something starts dinging on your internal “what the hell is that” meter, ask for clarification. Don’t allow yourself to glaze over. Go as far as you can go (which usually is directly linked to how much time you have) in understanding that person’s work.
(Forgive this statement from the Department of the Obvious, but it’s probably not a good idea to initiate this conversation when your engineers are donning gaffs on a windy winter day, or resolving a network outage. These are break room discussions.)
Find opportunities to ask about trade-offs. Technologists are always, always, always weighing tradeoffs. Storage in the house, or in the network? Gigabit Ethernet, or not? OCAP in all boxes, or just the high-end boxes? Knowing the pros and cons on both sides of an engineering discussion is very often synonymous with knowing business strategy.
Engineers are likeable people. It’s Thanksgiving. Take a moment to thank yours this week.
This column originally ran in the Technology section of Multichannel News.
QoS and DQoS: Spinach Before Dessert
by Leslie Ellis // November 11 2002
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 are the most comprehensible techniques in the world; both make broadband Internet and voice-over-IP work better (respectively). 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 (Internet Protocol) 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 the DOCSIS 1.1 specification. It’s important because it’s the mechanism for adding broader, more automatic “tiers” of data service (as translated in the 10/16/00 and 8/8/01 editions of Multichannel News.)
D-QOS mostly anchors to voice-over-IP (VOIP) right now, as a major component of CableLabs’ 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 that packets representing 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 Popeye’s sudden biceps, 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 small, evolutionary steps. Just getting D-QOS to work for VOIP is pretty tricky, yet its fruits will likely be applicable to other multi-media IP applications, such as video streaming.)
Secondly, D-QOS, by nature of its birth inside the PacketCable 1.0 specification, is steeped in the already acronym-chunked parlance of telephony. That alone requires you to tug forward your 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 for you pick up the cable phone. This creates an elaborate integration dance, known in tech lingo as “setting up a flow,” and involving 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+.”
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.
This column originally appeared in the Broadband Week section of Multichannel News.