This month, at various times, I got stuck in traffic behind a school bus, a food truck, and an elderly transport van. I stayed calm each time, reminding myself that they were carrying out more important missions than whatever I was doing at the time. (I was probably on my way to work to write this article.)
Such generosity is rare on the streets. But on the Internet, it may lead to the long-sought promise of high-bandwidth, interactive media at a relatively low cost. Part of this story involves a technical description of the "scavenger service" and "alternative best-effort service" adopted by the Internet2 QoS Working Group . The other part of the story is the odyssey the working group took in order to adopt such creative solutions.
To push the traffic metaphor a bit farther, the working group found they could not reach their destination without placing their entire fleet of vehicles in reverse and looking for a different street. Their boldness is particularly worthy of note because they had to leave behind a road many of them had helped to dig out and pave in the first place.
Traditional, best-effort packet delivery has not prevented people from sending real-time audio and video over the Internet for the past couple decades. But the jitter, combined with limited bandwidth, rendered services like CUSeeMe looking as if you were gazing at them through a rain-drenched window.
Sites with sufficient cash on hand tried to solve the problem through over-provisioning. But even if users at two endpoints were willing to install optical fibers on site, they couldn't force their providers to do the same.
In other words, high bandwidth required a coordinated effort between endpoints and backbone. To a large extent, the creation of Internet2 in 1996 sprang from an agreement to upgrade lines and equipment at each level of the network. While Internet2 is many things, one of its aspects could be described as a mutual promise among universities, researchers, and regional backbone providers to create and gainfully employ high-throughput connections.
To make smart use of these lines and maximize their value, Internet2 researchers joined others in looking for ways to nail down bandwidth across a wide area network: to provide guaranteed throughput for specific applications during limited time periods.
At that time, the promise of flexible, guaranteed Quality of Service (QoS) on the Internet was exemplified by the Resource ReSerVation Protocol (RSVP), defined in RFC 2205 in 1997. It embodied the most ambitious goals of the QoS researchers.
Suppose two hosts agree on a session that involves large data flows. Under RSVP, the host meant to receive the data uses reservation messages to contact each router on the route back to the server and reserve bandwidth at that router.
Putting this job at the receiver allows routers to notice when multiple receivers are asking for the same data flow, and combine them in a form of multicasting to increase efficient use of the network between the sender and the router. Routers all along the route, once they agree to provide the bandwidth, cooperate to keep packets moving.
In theory, it's awesome. In practice, RSVP has been declared viable only for small networks. According to Ben Teitelbaum, chair of the Internet2 QoS Working Group, recent protocol development on "aggregated RSVP" may overcome the objections that "it doesn't scale."
Still, his group has come to the conclusion that logistical, financial, and organizational barriers will block the way toward any bandwidth guarantees. Here are a few of the daunting problems, summarized from an article by Internet2 researchers Teitelbaum and Stanislav Shalunov:
Guaranteed service assumes that every router along the route supports the QoS protocols. As the RSVP RFC points out, non-RSVP nodes not only ignore QoS requests, but might reroute packets so they aren't using the reserved route at all. While the RFC considers this result tolerable, real guarantees would require huge numbers of ISPs to agree to deploy the protocols all at the same. The Internet does not work that way.
ISPs must cooperate in ways that help their competitors more than themselves. In other words, one ISP will be promising a premium service as a way to win customers, then asking competing ISPs to help meet that promise. Such help is not likely to be proffered until ISPs are run by the spiritual descendents of St. Francis of Assisi.
New, complex payment mechanisms would have to be put in place. Who pays whom along the route? How much more should QoS cost? What if users want the priority service to kick in only when the network gets congested? Moving from a flat, one-size-fits-all system to a tiered system is always a headache.
Complex monitoring systems will have to be put in place along the routes. How do customers know they're getting the throughput they paid for? (Subjective experience is a very poor indicator.) What kinds of penalties can be imposed on ISPs that cheat and get caught only once in a long while? And suppose the ISP cannot meet its promise due to a Denial of Service attack beyond its control?
Once ISPs start offering QoS, they have incentives to degrade standard service so as to nudge customers toward paying for the premium service.
In addition to these and other specific criticisms, the premise of premium service runs fundamentally counter to the architecture of the Internet. Consider this: traditional IP routing chooses the best route for each packet based on local considerations. In fact, this practice is the justification for breaking up data into packets in the first place.
Premium services assume that a route is chosen in advance (although RSVP allows for a limited degree of rerouting). One could ask, "Who needs the Internet for this?"
As Teitelbaum puts it: "The best-effort service model allowed the Internet to become the fast, cheap, and global infrastructure that we know and love. The temptation to teach it new tricks--like offering circuit-like QoS assurances--is very real. Unfortunately, there is a huge risk that in doing so, we would undermine the very properties that have made the Internet so successful."
Reaching the realization that premium services were both impractical and philosophically undesirable, the Internet2 QoS working group made an astonishing turnaround. They officially announced they were halting all efforts on premium service -- turning their backs on years of impressive research and specification work. And then they demonstrated some true out-of-the-box thinking by looking for efficient bandwidth use in an entirely new direction.
The sea change in the QoS working group consisted of this: instead of forcing users to compete for favored treatment (a kind of rationing that leads to all the distortions and risks listed earlier), they allowed users to voluntarily accept a lower status. If you're nice, you relieve congestion for everybody. You may even end up with better bandwidth than you'd get otherwise, because you are placed in a separate queue from normal traffic.
The two services the working group has adopted along these lines are currently being experimentally confirmed.
The QBone Scavenger Service (QBSS) lets an application mark its traffic as low-priority. The traffic is delivered using the same best-effort algorithm as normal traffic, but placed into a separate queue that the router serves less often.
The proposal is based on a "lower than best-effort" service suggested by R. Bless and K. Wehrle in 1999. It has been further refined and used in experiments by Differentiated Services (diffserv) researchers. Unix users will immediately see the similarity of scavenger service to the nice command and system call, which change a process' priority.
To see how simple the implementation is, take a look at the definition. The sender implements the service by setting a single bit in the IP header!
Routers, of course, require more sophistication than the sender to implement the scavenger service. They can't simply put all normal traffic ahead of all low-priority traffic; that could starve the latter. Instead, they have to maintain separate queues for normal and low-priority traffic, sending just enough of the latter to keep TCP connections alive.
All they need is one of the well-established algorithms already built into many routers for prioritizing traffic, such as weighted fair queueing.
Furthermore, if networks deploy the scavenger service piecemeal, it's still useful. Interfaces that ignore, but pass on, the scavenger mark will provide normal service to all, without undermining the efforts of sites that do honor the bit.
It's important to realize that the scavenger service depends on a choice by the end-user. Either it is built right into a binary, or the user chooses the service when running the application. In either case, the choice ultimately resides with the user.
But the working group is betting that lots of users would play along. Some will do it in honor of preserving a commons, some will do it to free up bandwidth for other applications of their own, and some will heed financial rewards or the demands of a network's acceptable use policy.
The service ought to be appropriate for large file transfers, because the recipients usually don't care if a few extra minutes are added to a large download when they know they have to wait a significant amount of time anyway.
Scavenger service could be the solution for campus networks currently plugged up by music downloads from peer-to-peer file-sharing services. Some universities would benefit greatly, because the service could be used by research projects that routinely conduct data transfers taking hours to complete.
Teitelbaum hopes that the scavenger service leads developers to experiment with entirely new classes of applications. Users may make far greater use of their available bandwidth if they feel confident they can exchange large amounts of data with little or no impact on other applications. New types of background processes may emerge to exploit the network just as grid computing applications such as SETI@home exploit unused CPU cycles.
Don't want to give up something for nothing? Then consider another idea under consideration by the working group, Alternative Best-Effort (ABE). This is meant for interactive media applications like Voiceover IP, which require low delays but can tolerate losses.
In ABE, the application asks for packets to be dropped in the event of congestion, instead of piling up in the queue. So ABE helps applications avoid jitter while reducing congestion for all traffic.
ABE has a research history going back at least to 1998, and is comparable to another research project called Best Effort Differentiated Services (BEDS).
Philosophically, I find this change of heart by the Internet2 QoS Working Group appealing and even inspiring. While most of Internet2 is hefty, expensive stuff (fat pipes, stunning video equipment), the QoS Working Group has picked up two modest research projects that might lead to the widespread adoption of worthy new practices throughout the Internet.
Taking a different highway ramp took courage: it's not easy to walk away from a large and well-publicized initiative such as premium services. To find alternatives, the group combined a sensitivity to Internet culture with a bold willingness to make deep but incremental adjustments to IP. It's what I would call a best effort.
Andy Oram is an editor for O'Reilly Media, specializing in Linux and free software books, and a member of Computer Professionals for Social Responsibility. His web site is www.praxagora.com/andyo.
Read more Platform Independent columns.
Return to the O'Reilly Network.
Copyright © 2009 O'Reilly Media, Inc.