Pages: pp. 46-47
Quality of service is a network "term of art" for describing technologies that allow service providers to manage network congestion rather than simply to add capacity. The Internet has its origins in one QoS—namely, best effort—which assumes that all packets are created equal and that all will share equally in the inconveniences of congestion. Each network node simply queues individual packets in the order they arrive and forwards them on a hop-by-hop basis toward the IP address in each packet header. When the packets arrive—even if they arrive—is a matter between the sending and receiving parties.
It is a simple network concept: flexible, efficient, scalable, and fair. Moreover, it has been effective in its support of applications like FTP and e-mail. But as the Internet has moved into the mainstream of global communication, so have its applications. Voice-over-IP, in particular, and other multimedia applications, as well as certain business applications, require service guarantees that "best effort" does not meet.
The Internet Protocol includes a mechanism for offering limited QoS, namely, a Type of Service (ToS) byte in the IP header. With the new focus on QoS, however, the Internet Engineering Task Force has been looking into additional QoS functionality. The IETF is currently working on two types of protocol development to differentiate the Internet's best-effort QoS service.
One is the Integrated Services (IntServ) architecture, documented in RFC 1633 (informational) and in RFCs 2212 and 2215 (standards track). IntServ requires applications to signal their service requirements to the network through a reservation request. IntServ currently uses the Resource Reservation Protocol (RSVP) as its end-to-end signaling protocol, documented in RFC 2205 (standards track). Unfortunately, the IntServ/RSVP architecture does not scale to the global Internet. The other approach, Differentiated Services (DiffServ), works in the core of the network through a scalable aggregated service mechanism. It is documented in RFC 2475 (informational) and RFC 2474 (standards track). (RFCs are available online through the IETF at http://www.ietf.org/rfc/rfc####.txt.)
The articles presented here address research areas that can support the development of Internet-based applications with QoS requirements.
Bhatti and Crowcroft focus on the issues and principles of modifying IP packet-handling in routers to support real-time applications in an integrated services architecture. Verticale and Trecordi evaluate the effectiveness of two current architectures for the provisioning of multimedia services to IP traffic in the backbone. McWherter, Sevy, and Regli describe a simple testbed for experimenting with different QoS configurations.
The IETF Internet Architecture Board has a work in progress, "Next Steps for the IP QoS Architecture," (Geoff Huston, June 2000), available at http://www.ietf.org/internet-drafts/draft-iab-qos-01.txt.
For an excellent survey of protocol development to support IP QoS, see Chris Metz's On the Wire column from Mar/Apr 1999, "IP QoS: Traveling in First Class on the Internet," available at http://computer.org/internet/v3n2/w2onwire.htm.
Saleem N. Bhatti and Jon Crowcroft
Traditional IP routing uses only the destination IP address to forward packets. This is the basic mechanism used in the Internet's "best effort" service. Can IP routing behavior be modified to support QoS-sensitive flows of semantically related IP datagrams, such as those in real-time audio and video? The authors answer, "Yes, but...we have to establish which parameters of real-time packet flow are important and how we might control them."
Vittorio Trecordi and Giacomo Verticale
ATM networks include built-in support for QoS, and so remain a possible contender for solving Internet QoS problems in the backbone. By mapping IETF standard parameters for an integrated services architecture onto ATM technical parameters, the authors are able to compare the efficiencies if native IP (Packet-over-Sonet) and hybrid IP-over-ATM architectures in different multimedia scenarios. Their results show that, except for a narrow class of traffic types, the QoS benefits of ATM cannot overcome its heavy overhead load. Further, even these benefits become less important as aggregate bandwidth increases.
David T. McWherter, Jonathan Sevy, and William C. Regli
The Drexel Network Toolkit is part of a laboratory environment for building and testing various approaches to implementation of QoS on IP-based networks. The toolkit contains kernel modifications for Linux routers and applications for Microsoft Windows and Unix computers. The authors have used it in real-world scenarios for satellite-based, wireless IP networks used in telemedicine, and they offer their experiences as a template for QoS experimentation in both academic and industrial research settings.