I've been talking and emailing with Bob Frankston and a couple of other folks since Monday about the issues surrounding a network concept known as Quality of Service (and abbreviated QoS), when I met Bob at the Supernova 2002 conference. (You might recall that Bob was one of the guys behind VisiCalc, a little invention that changed the face of business computing.)
The notion behind QoS is that you need to establish some kind of prioritization for data packets so that more important packets are more likely to make it through an end-to-end QoS implementation (say from a Wi-Fi-based VOIP phone through your DSL connection to a telco termination to the PSTN, or a video signal from your cable modem over 802.11a to a receiver). The 802.11e task group at the IEEE, for instance, is establishing QoS to ensure that media and voice can be sent over a Wi-Fi connection without jitters or interruptions.
The problem with QoS specifically is that it's hard to do under an IP network. TCP/IP and its various parts were designed to not care about the kind of data, only about getting it to the right place. TCP incorporates packet retransmission in case of failure; UDP, which is actually part of the TCP/IP universe, doesn't retransmit missing packets, leaving it up to the application that's using UDP to decide whether it needs the missing pieces or not.
With a stupid network, as David Isenberg terms it, you just need pools of bandwidth all over the place. You don't need to make one kind of data more or less important than another, as impossible a task as that's generally proven to me. It's one of those "have your cake and eat it, too" problems: if you focus on QoS, you lose many of the best aspects of IP networking; if you don't focus on QoS, then you can't ensure certain classes of data get to where they're going when you want them there.
Here's where I hope I represent Bob, David Reed, and David Isenberg's arguments correctly: it's better to focus on having more bandwidth than more intelligent networks. That is, forget about the fascist task of deciding that certain network traffic is more important than other network traffic. Rather, spend your energy (telcos and chipmakers and network equipment makers) on simply increasing the pool. In a non-prioritized network, more bandwidth means that more different kinds of traffic have an equal chance to get through.
David Reed pointed out, for instance, that a full quality voice signal only needs a few Kbps with modern compression. If you've got 128 Kbps upstream via DSL (as I do), why do you need QoS from yourself to the network? If you've got 11 Mbps via Wi-Fi (raw), why on earth does voice traffic need any help? Bob has said to me several times that there are simple technological fixes, none of them very expensive, that could push out high-speed bandwidth to the home -- fiber, etc., aren't required, just a little electronics of the electrical signal kind.
(Bob, by the way, knows of what he speaks. He was at Microsoft from 1993 to 1998, and was one of the forces behind spreading home networking as a concept within the company, and thus throughout the industry. He was one of the folks behind HomePNA, which uses plain copper wiring inside the house instead of dedicated Ethernet, and he calls himself -- ruefully -- the father of Network Address Translation (NAT). He regrets pushing the fake, private NAT address technique as a way to expand address space instead of IPv6, which would have offered substantial advantages in mobility and security. But who knew?)
Of course, the current reality is that networking systems are lumpy, and that even when you have ostensibly enough space, poor topology or network design can result in substantial collisions or dropped packets that can enormously reduce network throughput. It doesn't take a lot of dropped packets in a voice call to make a conversation sound choppy.
But Reed and others note that the biggest culprit in that problem isn't on the local end (LAN or DSL/cable-to-Internet) but rather at the point at which you transit your data from the DSL or cable modem pool into an ATM network or other network that takes you onto the Internet. Virtually all broadband is massively oversold for capacity, so until more capacity is brought to broadband termination points, you'll have times of congestion.
More to the point is that even if you had QoS from your machine or remote device across your network over a broadband or digital service connection to the Internet: well, it still has to contend once it gets there. If you were to pay the telco or cable company for QoS, they can't guarantee it to an endpoint, and they would have every motivation to ensure that without you paying for QoS, all of your packets were belong to them: you'd certainly see even poorer performance.
Worse, if the phone companies and cable companies get the idea that they should be selling you Voice over IP in the home or business as a network service that can be "guaranteed" and "reliable," you can bet Aunt Nellie that this transforms the nature of the data feed from the Internet that you get. It's no longer just the Internet, but a proprietary network that has different properties.
On the Interesting People list that Dave Farber runs, three posts on this topic appeared this morning. First, Larry Lessig on how prioritization should be fought in favor of neutrality; second, from Karl Auerbach on how the artificial dearth of high bandwidth on the network edges seems to push QoS, probably subversively; and third, from Bob Frankston, whose words I leave you with:
What we need to focus on is the mechanism and the awareness of the concept of connectivity -- the simple commodity out of which it really is trivial to create the current telecommunications services and it is possible to do far more.