IP Quality of Service : An Overview


IP Quality of Service Approaches

TOS Routing

Integrated Services

Differentiated Services




Recent years have a seen a lot of research on the provisioning of Quality of Service (QoS) in the Internet Protocol. This report makes an attempt to give an introduction to the various approaches that have been suggested for the provisioning of QoS in IP. The second section discusses these approaches, and suggests links for further reading. The last section compares the various approaches that have been discussed in this report.

IP Quality of Service

Many approaches have been suggested for providing QoS in the Internet Protocol. This section discusses these approaches in detail. The various approaches that are discussed are:

TOS routing

When the Internet Protocol was first specified in [1], even though TOS bits were provided in the IP header, were not used by most of the routers. The focus then was on routing the packets to the final destination and not on providing QoS guarantees of any kind whatsoever.

The TOS byte format is shown in figure 1. The TOS byte is interpreted in this manner.
Bit 3  0 - Normal Delay

1 - Low Delay

Bit 4 0 - Normal Throughput 

1 - High Throughput

Bit 5 0 - Normal Reliability 

1 - High Reliability


0 - 2: Precedence Control
111 Network Control
110  Internetwork Control
100 Flash Override
011 Flash
010 Immediate
001 Priority
000 Routine

Bits 6 and 7 are unused for the time being. These are set to zero for now.

The use of high throughput/high reliability/low delay links could cost more for the end-users. Early networks, which implemented the TOS routing, include the AUTODIN II, ARPANET, SATNET, and PRNET. These implementations had their own mappings from the type of service to the actual service in the networks.

The requirements for IP hosts from the communication perspective and from the application perspective as specified in [2] and [3, advocate the use of TOS bits by the hosts. This RFC recommends the use of the first three bits in the TOS field for the precedence and all the remaining bits for the purpose of specifying the type of service required. However, the specifics of the bits in the TOS have not been dealt with in [2] and [3].

Integrated IS-IS [4] and the Open Shortest Path First (OSPF) [5] are two routing algorithms which are capable of TOS routing. The integrated IS-IS does the QoS routing based on the QoS feature of the IS-IS. The routing is done on the basis of the throughput, delay, cost and the error probability. The routing is done on the basis of any one of these metrics, but a combination of metrics is not allowed. The IS-IS retains the same format for the TOS byte as given in [1]. The first three bits specify the preference and though it does not affect the route, it may affect certain aspects of packet forwarding.
000 All normal
100 Low delay
010 High throughput
001 High reliability
Other default

This routing algorithm also retains the same format for the TOS field specified in [1].

As far as the OSPF routing algorithm is concerned, it calculates different routes to a destination for each IP type of service. That is, in other words, it constructs different trees for each TOS. In order to differentiate routes based on the TOS, costs are associated with the routes. The OSPF encodes the TOS in the link state advertisements. The following codes are used in the routing packets exchanged.
OSPF Encoding D R
0 0 0 0
4 0 0 1
8 0 1 0
12 0 1 1
16 1 0 0
20 1 0 1
24 1 1 0
28 1 1 1

[6] discusses extensively on the TOS routing. The TOS structure defined in [6] in shown in figure 2. This structure is different from the one proposed in [1], in that the bit 6 is also used as a TOS bit. The first three bits (precedence bits) indicate the importance of the packet. The TOS bits indicate the tradeoffs between the delay, throughput, reliability and cost. The last bit is unused. Even though there is a difference in the TOS byte format, this scheme is designed to be compatible with the routing algorithms that were just discussed. The four bits of the TOS byte are treated in the following manner.
1000 Maximize delay
0100 Maximize throughput
0010 Maximize reliability
0000 Normal service

This specification considers the TOS field as an integer rather than as a sequence of bits. This means that a request can be made only for one of maximizing throughput/minimizing delay/maximizing reliability/minimizing cost.

[7] describes the means by which a router interprets and processes the precedence bits in the TOS field. The routers that support precedence bits need to implement precedence ordered queue service and precedence based congestion control along with a mechanism to select the priority features of the link layer. The precedence bits serve to differentiate between the various traffic flows based on the relative importance of the individual flows. When a router implements precedence ordered queue service, it ensures that a packet with a certain priority is not transmitted until and unless all packets with higher precedence values are transmitted. Similarly the lower layer precedence mapping ensures that the packet priority is maintained at the link level as well.

Integrated Services

The integrated service architecture, as described in [8] serves to support

  1. Real time service like audio and video in the existing Internet and
  2. Controlled link sharing: Controlled link sharing is a facility made available to the network service providers wherein the available bandwidth is divided into certain service classes and provided with a management facility by which these administrative classes are allocated and controlled.
To do this, the architecture proposes to change the existing best effort service Internet model. The integrated service model consists of consists of two types of services to support real time services, namely predictive service and guaranteed service. One important assumption made in the development of the IS model is that the network resources can be explicitly controlled. This means that ?resource reservation? and ?admission control? are basic blocks of the IS model. This also means that the intermediate routers need to maintain flow specific information. Thus a basic change to the current Internet model is proposed.

There are four basic blocks in the reference implementation framework. These include the following

  1. Packet Scheduler
  2. Admission Control
  3. Classifier
  4. Reservation Setup Protocol
In the current Internet model, all the packets receive the same QoS. To realize the IS model, the routers need to implement the "traffic control", which includes the packet scheduler, admission control and the classifier.

Packet Scheduler

The packet scheduler, as the name suggests, schedules the transmission of the packets. Various types of queues can be implemented at the packet scheduler. These queues are typically located at the output driver level of an operating system and they correspond to the link level. Different implementations can have different packet scheduling algorithms.


The classifier classifies each incoming packet to a particular service class, so as to be scheduled appropriately for transmission by the packet scheduler. The packets are classified based on certain information that is present in the packet header. All the packets belonging to the same class are treated similarly. There are many criteria based on which the packets can be classified. For e.g., the classifier could consider all video flows as belonging to the same service class.

Admission Control

Admission control implements the decision algorithm that a router or host uses to determine whether a new flow can be granted the requested QoS without impacting earlier guarantees. The decision to accept or reject a reservation request is made on the basis of the requested QoS and the available QoS on the outgoing link.

Resource Reservation Protocol

The resource reservation protocol is responsible for creating the flow specific information in the end hosts and in the routers all along the path from the source to the destination. The specification for one such reservation protocol is described in [9]{RSVP}. This specification describes RSVP (Resource Reservation Protocol). The application specifies the required QoS with the help of ?flowspecs?. RSVP uses the flowspecs to reserve resources in the routers along the path from the source to the destination. RSVP maintains ?soft-state? QoS.

The implementation reference model for the routers is shown in figure 3.

The classifier classifies the packets on their arrival from the input driver and sends it to the appropriate queue that the packet scheduler maintains. The packet scheduler then transmits the packets based on the scheduling algorithm to the output driver.

The admission control block comes into play during the connection set up. If the admission control accepts a reservation request, then appropriate changes are made to the classifier and the packet scheduler. The management block is used to provide the controlled link sharing facility to the network service providers. It can directly control the classifier and the packet scheduler.

Integrated Services Model

The integrated services model describes a core set of services that will be offered in the internet. The core model deals only with the time of delivery of packets and does not deal with other issues like routing and security. This section briefly discusses the service requirements and services for the individual flows, and then it discusses the service requirements and services for the resource sharing.

Quality of Service Requirements

As already mentioned, the core model is concerned only with the time of delivery of the packets. Thus, the only QoS guaranty that is provided by the network is the per-packet delay. The commitments can be even more restrictive at times, wherein only minimum and maximum packet delays are guaranteed. There are essentially two types of applications: those that are sensitive to the time of arrival of the packets (real time applications) and those would wait for the data even if it is delayed (called as elastic applications).

Among the real time applications, there are tolerant applications and intolerant applications. A typical real time application is the playback application. Playback applications that can tolerate some loss of fidelity (and thus some delay) are referred to as ?tolerant? applications. Similarly, playback applications that cannot tolerate loss of fidelity (and thus delay) are referred to as ?intolerant? applications. The ?guaranteed service? model can characterize intolerant applications, while the ?predictive service? model characterizes tolerant applications.

Elastic applications are those that wait for the data, until they are received. These applications are characterized by the ?best-effort service? model.

In [9] and [10], the guaranteed service and the controlled load IP service classes are discussed.

Resource Sharing Requirements

The QoS service model dictates how the network allocates the resources to the individual flows. The resources are allocated on a per flow basis and does not consider policy issues when looking at a group of flows. The resource sharing requirements discuss these issues. Delay was the only QoS parameter that was guaranteed in the previous sections. Similarly, the prime parameter of interest in this section is the link bandwidth. Thus, this component of the service model, called "link-sharing", is concerned with the sharing of the aggregate bandwidth among multiple flows, subject to some policy specification. Some examples of sharing link bandwidth among multiple flows include:

Multi-entity link sharing:

In this case, multiple agencies share a link among themselves. These agencies insure that at times of overload, a share of the link bandwidth is available to the all the agencies based on the policy, while at times of underload, any one of the entities could use the entire link bandwidth.

Multi-protocol link sharing:

In the case of multiple network layer protocols like IP, IPX, etc. it should be insured that no single protocol occupies the entire link bandwidth. This is because each protocol has its own method for handling congestion control and some protocol could be aggressive in doing the same.

Multi-service link sharing:

Within the same protocol family, like IP, IPX etc. the system administrator may limit the link bandwidth made available to individual applications (like FTP, TELNET etc.).

[8] proposes to use the ideal fluid flow model to characterize the resource sharing service model.

Packet Dropping

The assumption made about the flows till now is that all the packets within a flow are equally important. However, in audio and video flows, some are more important than the others are. Therefore, a ?preemptable? packet service is added to the service model. In this case, some packets that are marked as ?preemptable? are dropped when the network is in danger of not meeting the quality of service requirements. A router can reduce the delay on non-preemptable packets when it drops some preemptable packets.

Usage Feedback

Another important feature that needs to be provided is a feedback mechanism to ensure that the network resources are not abused. This is termed as "accounting".

Reservation Model

The reservation model specifies the method by which the application negotiates the QoS with the network. The simplest reservation model is asking the network for a particular QoS and the network either accepts or rejects it based on the available QoS. However, the reservation models can be very complex. The resource reservation protocol is one such extensive effort on the reservation model.

This concludes the description of the integrated service model. The integrated service model is not a readily implementable model nor is it a scaleable model. A lot of effort has been put into the integrated services model. However, the current focus is on the differentiated service model, which is described in the next chapter.

Other links to Integrated Services

IETF page on Integrated Services - http://www.ietf.org/html.charters/intserv-charter.html

Differentiated Services


Differentiated services are intended to provide scaleable service discrimination in the Internet without a need for maintaining per flow state or doing per hop signaling. This approach employs a small set of building blocks from which a variety of services can be built. These services can be either end-to-end or intra domain. Differentiated Services provide a wide range of services through a combination of:

This section discusses the different approaches to differentiated services.

Terminology used

Before going into the various approaches that have been suggested for differentiated services in the Internet, we need to define certain terms that will be used in the rest of this section. 

Per-hop behavior

This is the forwarding behavior a packet receives at a network node. For predictive services to be realized, per-hop behaviors probably need to be supported at all routers in a differentiated service capable network. 

DS Byte

The TOS octet in the IP header if it is used for providing differentiated services is called DS byte.


Where two network clouds are linked. These clouds could represent different autonomous systems, administrative domains etc. A boundary can be further sub divided into exit and entry nodes, where the exit/entry nodes are the upstream/downstream nodes of a boundary link in a given traffic direction.

Traffic conditioning primitives

This includes policing, shaping, classification and packet marking. These functions are applied on flows, behavior aggregates etc. These are discussed in more detail later in the section. 

Differentiated Services behavior aggregate

A group of packets with the same "DS byte" pattern crossing a boundary in the same direction. In differentiated services terminology, behavior aggregate and aggregate are used interchangeably. 


This is an entity that classifies packets based on certain fields in the IP header. The classification is based on certain well-defined rules.

Class Selector Codepoint

Any of the eight codepoints in the range 'xxx000' (where 'x' may equal '0' or '1'). This is explained in detail later in this section. 

Class Selector Compliant PHB

A per-hop behavior satisfying the Class Selector PHB Requirements.


A specific value of the DSCP portion of the DS field. Recommended codepoints should map to specific, standardized PHBs. Multiple codepoints MAY map to the same PHB.

Differentiated Services Boundary

The edge of a DS domain, where classifiers and traffic conditioners are likely to be deployed. A differentiated services boundary can be further sub-divided into ingress and egress nodes, where the ingress/egress nodes are the downstream/upstream nodes of a boundary link in a given traffic direction. A differentiated services boundary typically is found at the ingress to the first-hop differentiated services-compliant router (or network node) a host's packets traverse, or at the egress of the last-hop differentiated services-compliant router or network node packets traverse before arriving at a host. This is sometimes referred to as the boundary at a leaf router. A differentiated services boundary might be co-located with a host, subject to local policy. 

Differentiated Services Domain

A contiguous portion of the Internet over which a consistent set of differentiated services policies are administered in a coordinated fashion. A differentiated services domain can represent different administrative domains or autonomous systems etc.

Differentiated Services Definition of TOS octet

In [11], differentiated services definition of the TOS octet and the operational model behind that definition are provided.

0 6 7

IN: in (1) or out (0) of profile

PHB: per-hop behavior

CU: currently unused (reserved)

The IN bit indicates whether the packet is in or out of profile with respect to some traffic policy at the boundary. The packets with the IN bit set to 1 should always experience lesser delay and congestion compared to those packets with the IN bit set to 0. The 5 bit PHB indicates the per hop behavior, while the last two bits are unused and set to zero. These two bits could be used for congestion control in future. Within a particular class of per hop behaviors, the IN bit could be used to set a higher priority for certain packets in that class. Note that this definition of the DS byte is not compatible with the TOS octet in the IP packet header.

In [12], a more detailed description of the TOS octet is given. This definition is different from that proposed in [11].

6 7

DSCP - Differentiated Services Code point

CU - Currently Unused

The nodes select the PHB is selected based on the value of the entire DSCP field. With some exceptions, the mapping of the DSCP to the corresponding PHB should be made configurable. The choice of these mappings is left to the implementers. PHB specifications must have a default codepoint. However, the choice of values for these codepoints is left to the individual implementations. For the purpose of scalability, the nodes should forward the packets received with unknown codepoints without changing them. This byte too, is not compliant with the TOS octet of the IP header. But the assumption made here is that the differentiated services domains protect themselves by deploying re-marking boundary nodes. In [12], an attempt is made to maintain backward compatibility with the widely used per hop behaviors and the historical use of the IP Precedence bits. However, the DTR bits of the TOC octet are not considered for backward compatibility.

Compatibility with the existing per hop behavior

To maintain compatibility with the existing per hop behaviors: A "default" PHB must be provided in the DS compliant nodes. This is the common best effort service currently offered by the routers. When none of the other PHBs are matched, the packet is treated for best effort service. A DSCP value of ?000000? is suggested for this PHB.

Compatibility with the IP Precedence numbers

To maintain compatibility with the IP precedence fields: The IP precedence bits are being used widely to differentiate between the various types of packets. Some of the common uses of the IP precedence bits are:

  1. As a drop preference in receiving routers: Routing and network control packets are marked with higher preferences. When a router receives packets at a time when it is congested, it may drop the packets that are marked with lower preference. This is done is order to conserve the buffer space for processing higher preference routing and network control packets, by which the network service improves.
  2. As a drop preference in transit routers: The preference on the packets in marked either by the source host or by the intermediate routers. When a packet is scheduled for transmission to a router, which is congested, the router may drop the packets based on the preference assigned to the packets.
  3. As a queue selector: This is used to select the queue to which the packet should be assigned in a strict priority queuing system or a VC multiplexed environment like ATM or Frame Relay.
In [12], a set of minimum requirements on a set of PHBs that are compatible with the forwarding behaviors that have been implemented currently has been suggested. In addition, there are sets of codepoints that must map to PHBs. There may be other codepoints that map to the same PHBs. This set of codepoints is referred to as the Class Selector codepoints and the minimum requirements for the PHBs mapped to by these codepoints is referred to as the Class Selector PHB requirements.

The DSCP value of ?xxx000? has been reserved as the class selector codepoints. PHBs mapped to by these codepoints must satisfy the class selector PHB requirements. The codepoint for the default PHB is the ?000000?.

The class selector codepoint with a higher numerical value has a higher relative order compared to one having a lower numerical value.

There have been many approaches for differentiated services, namely

  1. Assured Service
  2. Premium Service
  3. User-share differentiation service
These services are discussed in the next section.

Assured Service

Clark and Wroclawski [13] defined an "Assured" service that follows "expected capacity" usage profiles that are statistically provisioned. The assurance that the user of such a service receives is that such traffic is unlikely to be dropped as long as it stays within the expected capacity profile. An Assured service traffic flow may exceed its Profile, but the excess traffic is not given the same assurance level. The assured service suggests that a contract might exist between a service provider and its peer, or between two service providers, which guarantees a certain level of service, and offers the opportunity to overload this on a best effort basis. The expectation is that traffic, which is within the contracted rate, as measured by a token bucket, has a very much-reduced probability of being lost, while traffic, which is excess, has a less sanguine prognosis. The model assumes that the boundary device, like a router, is measuring traffic and marking it either "in" or "out".

Many service providers are testing this model today, with a view to offering a layered usage-based service level agreement. Such an agreement might include several layers of drop or delay preference, and associated rates. For example, it might offer the following four-tiered service:

Premium Service

Jacobson [14] defines a "Premium" service that is provisioned according to peak capacity profiles that are strictly not oversubscribed and that is given its own high-priority queue in routers. A premium service traffic flow is shaped and hard-limited to its provisioned peak rate and shaped so that bursts are not injected into the network. Premium service presents a "virtual wire" where a flow's bursts may queue at the shaper at the edge of the network, but thereafter only in proportion to the indegree of each router.

Realizing the need for a commercial service to co-exist with the best effort service, Van Jacobson suggests the allocation of a fixed percentage of the bandwidth for premium service, which is made available to the customers at a much higher price. Providing a premium service in this manner reduces the bandwidth available for best effort traffic, but this would be compensated by the higher cost for the premium service. At the same time, the premium service bandwidth is made available to the best effort traffic when not in use.

Premium service levels are specified by the peak bit rate for a particular flow. A flow, in this case, is identified by the <Source IP address, Source Port, Destination IP address, Destination port, Protocol>. The first hop router filters the packets and sets the premium bits based on the premium service specification, and perform traffic shaping on the flow that smoothes all traffic bursts before they enter the network. A compliant router maintains two queues, one for the premium service packets, and the other for the best effort traffic. It should send the premium service packets first before servicing the other queue. The user should not exceed the peak-bit rate. Where packets cross a boundary, the policing function is critical. The entered region will check the prioritized packet flow for conformance to a rate the two regions have agreed upon, discarding packets that exceed the rate. It is for this reason that it is always preferable to conform to the agreed upon rate.

Thus in this scheme, the router needs to maintain flow information to set the bits appropriately in the header.

User Share Differentiation

Zheng Wang [15] proposed the user share differentiation method for implementing differentiated services. This scheme is based on the concept of resource sharing. The scheme allows ISPs to differentiate traffic flows on a per-user basis, providing minimum bandwidth guarantee and share-based bandwidth sharing. The ISP has a pool of bandwidth resources that is shared by multiple users. There are two parameters based on which the bandwidth is shared, namely user and share. User identifies the entity to which the resource is allocated and the share identifies the amount of resources allocated to that entity.

When a user signs a package with the ISP, the user share differentiation scheme guarantees that:

    1. The user will have a minimum amount of bandwidth on all or some of the links in the ISP.
    2. For the bandwidth over the minimum amount, the user shares the bandwidth with other users in proportion to its allocated share.


Other links to Differentiated Services

IETF Differentiated service page http://www.ietf.org/html.charters/diffserv-charter.html

MITs differentiated service page http://diffserv.lcs.mit.edu/

Torsten Braun?s slides on differentiated services http://www.iam.unibe.ch/~braun/talks/swisscom498/ppframe.htm

Bell labs page on differentiated services http://www.bell-labs.com/user/zhwang/diff-serv/index.html

Lixia Zhang?s page slides on differentiated services http://www.internet2.edu/qos/may98Workshop/presentations/Zhang/sld001.htm

  Best Effort  Integrated Services Differentiated Services
QoS guarantees No Yes Yes
Scaleability Yes No  Yes
Setup  No Dynamic 

Per Session

End to End 


Long term

Within a domain



[1] http://andrew2.andrew.cmu.edu/rfc/rfc791.html - RFC 791 - Internet Protocol

[2] http://andrew2.andrew.cmu.edu/rfc/rfc1122 - RFC 1122 Requirements for Internet Hosts - Communication layer.

[3] http://andrew2.andrew.cmu.edu/rfc/rfc1123.html - RFC 1123 Requirements for Internet Hosts - Application and Support.

[4] http://andrew2.andrew.cmu.edu/rfc/rfc1142.html - OSI IS-IS Intra-domain Routing Protocol

[5] http://andrew2.andrew.cmu.edu/rfc/rfc1583.html - OSPF-2

[6] http://andrew2.andrew.cmu.edu/rfc/rfc1349.html - RFC 1349 Type of Service in the Internet.

[7] http://andrew2.andrew.cmu.edu/rfc/rfc1716.html - RFC 1716 Towards Requirements for IP Routers.

[8] http://andrew2.andrew.cmu.edu/rfc/rfc1633.html - RFC 1633 Integrated services in the Internet Architecture: An Overview.

[9] http://andrew2.andrew.cmu.edu/rfc/rfc2212.html - RFC 2212 Specification of Guaranteed Quality of Service.

[10] http://andrew2.andrew.cmu.edu/rfc/rfc2211.html - RFC 2211 Specification of the Controlled-Load Network Element Service.

[11] http://diffserv.lcs.mit.edu/Drafts/draft-nichols-dsopdef-00.txt Differentiated Service Operational models and Definitions.

[12] http://www.ietf.org/internet-drafts/draft-ietf-diffserv-header-02.txt Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers.

[13] http://diffserv.lcs.mit.edu/Drafts/draft-clark-diff-svc-alloc-00.txt An Approach to Service Allocation in the Internet.

[14] Van Jacobson, Differentiated Services Architecture", talk in the Int-Serv WG at the Munich IETF, August, 1997.

[15] Zheng Wang, http://diffserv.lcs.mit.edu/Drafts/draft-wang-diff-serv-usd-00.txt, User-Share Differentiation (USD) Scaleable bandwidth allocation for differentiated services.