IP-based networks were neverdesigned for real-time traffic,yet QoS support in suchnetworks is needed toaccommodate both global use and the more demandingapplications now emerging.Changes in packet handling, inparticular, will help provideQoS support in IP networks.QoS-Sensitive Flows: Issues in IP Packet HandlingSALEEMN. BHATTI AND JON CROWCROFTUniversity College LondonImagine a network technology that routinely loses information, expe-riences variable and unpredictable delay in data delivery, and makesno distinction between applications with different communicationrequirements. Next, imagine that the use of this technology is growingexponentially and that, even as networks become increasingly congested,its applications are being extended to global-scale voice and video. This scenario describes the situation we face in supporting real-timeapplications over an IP-based infrastructure. Such applications involvedata flows that have quality-of-service (QoS) requirements. A QoS-sensi-tive data flow cannot readily tolerate the effects of packet loss, delay (anddelay variation, or jitter), and fluctuations in network throughput. In this article, we examine the problems in attempting to make theexisting IP infrastructure do what it was never designed to do—provideQoS support for integrated services to both real-time and non-real-timeapplications. We concentrate on the issues and principles concerningrouter modification for IP packet handling.PACKET HANDLING IN TRADITIONAL IP NETWORKSIP offers a connectionless datagram service that gives no guarantees con-cerning data delivery and has no notion of flows, in which many datagramsform a sequence meaningful to an application. For example, an audio appli-cation can package 40-millisecond audio time slices in individual datagrams.The sequence and timeliness of the datagrams has meaning to the applica-tion, but the IP network treats them as individual and unrelated. There isno signaling at the IP level—no way to inform the network that it is aboutto receive traffic with particular handling requirements, and no way for IP totell users to back off when there is congestion. IP routers forward individual datagrams on the basis of single metrics andnetwork destination addresses. The routing is dynamic, not fixed, allowingIP packets in a single flow to change network paths in case of router over-loads or failures. The absence of a fixed path for traffic of a single flow means,in practice, that the network cannot guaranteed consistent QoS during asession. Even if the path remains stable, the connectionless datagram ser-vice, does not protect the packets of one flow from those of another. Packets in output queues are serviced in a simple first-come, first-serve(FCFS) order, with the packet at the front of the queue transmitted first.48JULY • AUGUST 2000 http://computer.org/internet/1089-7801/00/$10.00©2000 IEEE IEEE INTERNET COMPUTINGINTERNET QoSIP PACKET HANDLING49IEEE INTERNET COMPUTINGhttp://computer.org/internet/JULY • AUGUST 2000Figure 1 describes how packets are processed in atraditional IP router. This traditional IP forward-ing mechanism provides the current best-effort IPservice. To modify routing behavior so that it cansupport QoS, we must establish the key parame-ters of a real-time packet flow and determine howwe might control them.INTEGRATED SERVICE CONCEPTSAND REQUIREMENTSThe Internet protocol architecture was designedto provide robust and scalable support for appli-cations that require not much more than reliableend-to-end data transfer,1for example, FTP andtelnet. In 1992, Clark et al.2described a way toevolve the original Internet architecture to an inte-grated services network that could support tradi-tional applications as well as emerging real-timeapplications. They identified four architecturalcomponents: a service level, a service interface, anadmission control mechanism, and schedulingmechanisms. The following is a simple description of the inter-actions between the components: ■ A service level is defined. This includes all the ser-vice semantics: descriptions of how packetsshould be treated within the network, how theapplication should inject traffic into the net-work, and how the service should be policed.Knowledge of the service semantics must beavailable within routers and applications.■ An application invokes a service using the serviceinterface and a signaling protocol. The invoca-tion includes specific information about thetraffic characteristics required for the flow, suchas data rate. The network indicates if the ser-vice invocation was successful and might alsoinform the application of any service violation,either by the application’s use of the service orfrom a network failure.■ Admission control uses the information in the ser-vice invocation, plus knowledge about other ser-vice requests it is currently supporting, to deter-mine if it can accept the new request. Admissioncontrol, typically implemented in the routers,polices service use to ensure that applications donot use more resources than they have requested.■ Once a service invocation has been accepted, thenetwork employs router mechanisms for schedul-ing and queue management to ensure that thepackets within the flow receive the requestedservice.A critical feature of this integrated-services architec-ture is signaling—talking to the network. Signalingis required in connection-oriented networks, and thesignaling part of such networks offers a natural pointfor communicating particular application require-ments. But datagram networks are connectionless,and typically don’t require signaling. Any signalingmechanism introduced to IP networks should becompatible with current Internet operation andshould not constrain or change the operation of exist-ing applications and services. SCHEDULING AND QUEUE MANAGEMENT As application traffic moves from the end systemstoward the network’s center, packets from differentflows are intermixed. Figure 2 (on the next page)shows how the traffic patterns of three flows (voice-over-IP, FTP, and Web traffic) are disrupted when theflows are aggregated. The flows arrive at a router onthree different input lines but are destined for thesame output line. The router forwards them in theorder they arrive, which causes the packets to experi-ence variable delay. This may not be a problem inFTP, but it can be for VoIP. While some delay cor-rection is possible at the end systems (through buffersto smooth the delay