Joho the Blog » Quality of Service
EverydayChaos
Everyday Chaos
Too Big to Know
Too Big to Know
Cluetrain 10th Anniversary edition
Cluetrain 10th Anniversary
Everything Is Miscellaneous
Everything Is Miscellaneous
Small Pieces cover
Small Pieces Loosely Joined
Cluetrain cover
Cluetrain Manifesto
My face
Speaker info
Who am I? (Blog Disclosure Form) Copy this link as RSS address Atom Feed

Quality of Service

[This is a draft of a column that will run in DarwinMag on Wednesday, probably.]

Who could object to quality?

Actually, you do. You object to quality every time you buy a worse-but-cheaper brand, order from the top of the wine list instead of the bottom, or reject the “pro” version of some over-featured piece of software.

And you also object to quality of service every time you get righteously annoyed at the way the waiters fawn over the well-dressed couple while barely remembering to clean up your spilled root beer. And, most important, you object to quality of service when you’re waiting on line and some perceived VIPs are served ahead of you because their quality of service degrades your quality of service.

That’s at the heart of the current debate over Quality of Service (QoS) as the Internet begins to subsume other networks. In fact, David Isenberg (who saw a draft of this column) expands the analog: “Maybe you’re pissed that they got in with no delay while you have to wait (delay). Maybe you’re pissed because they can count on getting in right away, while you never know how long you might have to wait (jitter). And maybe you never get in, thanks to those VIP a**holes filling up the place (lost packets).” One person’s Quality of Service can be another person’s Degradation of Service.

That’s what could be. As it stands, the Internet treats all bits alike. When a packet arrives at a router, it gets sent along regardless of what type of data it encodes. In fact, there’s no way to tell what type of data it’s carrying. Medical X-Ray Bits are moved just as quickly as Pamela Anderson Bits. And it doesn’t matter what order the packets arrive in: if the packets encoding Pam’s eyes show up after the ones encoding her painted toenails (assuming that it’s a photo of her vertical and rightside up), they will be put into the right order by the machine receiving them.

But many of the companies who are using the Internet as a transport for telephone calls say that their bits are different. If you’re reciting the Pledge of Allegiance over the phone (soon to be a requirement, by the way), if the “to the flag” ” bits arrive after the “under God,” your message will be unintelligible. Therefore, telephone bits deserve special treatment. Or so the argument goes.

Some very serious people disagree. Their arguments are of three types.

First, QoS is impractical. There are indeed bits in IP packets designed to indicate “type of service,” but no one uses them. There’s not even agreement how to interpret them, much less how to rank them. More important, the Internet routers would have to be set to act on thost bits which would require a massive retooling of the Net’s “operating system.”

Second, QoS is the wrong solution. According to this line of thought, QoS is only required if there’s a scarcity of bits available. It’d be far better to solve the QoS issue by opening up the sluices of connectivity: light up the “dark” (unused) fiber, open up the spectrum for public access, install more powerful routers, get with the IPv6 program. With sufficient bits and sufficient throughput, voice packets will arrive in time without having to always arrive first.

Third. QoS violates the principle of the Internet’s architecture. The Net has succeeded precisely because it does nothing but move bits from A to B. This is the “ End-to-End” theory described by Saltzer, Reed and Clark and the “Stupid Network” as described by Isenberg. Part of the simplicity that keeps the Internet humming is the fact that it treats all bits alike. Further, the fact that the Internet is not optimized for any particular applications means that it is optimized for innovation; “tune” the Internet for the VIP du jour and you will de-tune it for other applications. Let the telphone guys and gals change the way the Net works so that it’s better for voice and then tomorrow change it so that it works better for broadcasting TV shows, and soon the other types of bits we care about will have trouble getting through the line at the check-out counter.

So, even though in theory, we could provide QoS in the short term and open up connectivity in the longer term, doing so would mean obfuscating the true strength of the Internet: It’s no Strom Thurmond when it comes to bits.

Resources

Glenn Fleishman just published a helpful weblog entry on the topic.

Lawrence Lessig just posted a terrific article to Dave Farber’s mailing list, as did Karl Auerbach and Bob Frankston.

David Isenberg’s newsletter in 1999 ran a clear explanation of the issues. The article is based in part on research by Andrew Odlyzko; there’s a long interview with Odlyzko here.

This column resulted from my participating in (well, auditing) an email thread among Glenn Fleishman, Bob Frankston and David Reed. Obviously, they are not responsible for my stupidity, carelessness and poor personal hygiene.

Previous: « || Next: »

16 Responses to “Quality of Service”

  1. If your post had contained the phrase “Voice over IP” or the buzzword “convergence” I would have been more comfortable with it. Switches and routers and buffers and cache… switches and routers and buffers and cache… switches and routers and… here’s what I think: the old PSTN needs a shot in the arm. There’s no good reason not to digitize everything and run it all over the same backbone and serve all the realtime needs of linear packetized apps like full motion video and voice. Lighting up dark fiber is part of the puzzle. Using copper better is another piece. The whole thing about QoS is based on a model of scarce bandwidth and absent buffers or cache. The net can stay real dumb if we’re willing to invest in pipe, or it can get a little smarter if we’re willing to invest in fixtures, but it’s all a matter of plumbing.

  2. Re-reading my earlier comment I find it to be typically curmudgeonly. I’ll read the postings and articles you link and undoubtedly have greater clarity regarding the issues as they exist in 2002/2003. Thanks for the info.
    fp

  3. curmudgeoness is ever so fun. Why give it up, Frank?

    Being a bit of a grump myself I shimmer and jitter anytime I anticipate complicated projects. Complexity is ok. It can be talked about in simple terms. In be done without complication.

    However, when self-interest (in the form of short-term looks) takes the stage even a “stupid network” can become complicated and eventually unintelligible.

    I vote Nay to that your honor. Let’s keep things stupid.

  4. Stuart Cheshire put this well in 1996 in the context of ISDN vs IP (anyone remember iSDN?):

    2. For every guarantee there’s a corresponding refusal

    Note that ISDN’s guarantee only applies once you are connected. There is no guarantee that you will get connected when you place your call. Just like any other network the ISDN network has finite capacity. The difference is that even when it is under heavy load an Ethernet will always take your packet and try to deliver it if it can. The ISDN network won’t even let you place the call unless it is absolutely 100% certain that it has so much spare capacity that it knows it can guarantee never to lose any data you might send. So in the end ISDN doesn’t guarantee anything at all. If there’s the slightest possibility that there might not be enough capacity to send your data, ISDN will refuse to even try.

    You see, adding a guarantee doesn’t magically increase the overall capacity of the network. The capacity of the network stays the same, but the effective usable capacity goes down because now the network has to refuse data any time there’s even the slightest chance it might not be able to deliver it.

    So, a guarantee doesn’t improve the chance of your data getting through. In fact it reduces the chance, because now the network guarantees that in the questionable cases, it will refuse to even try.

  5. Funny, I was reminded by Kevin’s post of the ISDN versus Frame Relay marketing bafflement of the late 80s. Provisioning switched networks doesn’t seem that different from provisioning routed environments. And today’s hybridization including spanning tree protocol, blocked switches, designated bridges and so forth has me thinking the more things change the more they remain the same. While getting better and faster of course. Nevertheless, if your spanning tree pukes, well, your network is as down as if you had a bad-old-days blocking PSTN switch installed in the middle and the traffic overwhelmed it.

  6. QOS is nonsense, 8 classifications and 4 que’s, pah. Besides – all others are right too, make the pipe bigger and provision your network right, no QoS needed. So don’t be cheap on bandwith, but if you do, just leave the peones alone, they wotk fine and need no network…

    AK

  7. I agree QOS is nonsense.

Leave a Reply

Comments (RSS).  RSS icon