IP Quality of Service : An Overview
IP Quality of Service Approaches
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.
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:
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 |
| 101 | CRITIC/ECP |
| 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 | T | 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.
The integrated service architecture, as described in [8] serves to support
There are four basic blocks in the reference implementation framework. These include the following
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.
Classifier
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.
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 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:
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.
Boundary
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.
Classifier
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.
Codepoint
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:
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
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:
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.
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:
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 |
Static
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.