IP Quality of Service

© 2008 Khaled A.B. Aly, Technopsis.com®

Network services have been broadly classified into data and real-time services, where the first are sensitive to packet loss and the second are sensitive to delay and delay variation (jitter). Packet loss is an occasional must in any data network and is handled by application layer retransmissions as necessary. Delay and jitter are more difficult to manage since providing performance guarantees requires complex stochastic conditioning of traffic flows between the service endpoints and along the nodes en-route.

The statistical nature of IP traffic and protocols enables aggregating traffic and effectively utilizing network resources. However, the same features pose the issue of managing often conflicting performance demands of carried services. Depending on scale and services involved, there is a choice between ignoring QoS and just over dimensioning resources and implementing QoS at one or more layers, using one of two architectures, through protocols of different robustness and complexity.

First, QoS has been known and practiced in layer 2 protocols: IEEE 802.3 series Media Access Control (MAC) protocols, Frame Relay, and Asynchronous Transfer Mode (ATM). Second, layer 3 QoS may be considered for two classes of IP networks: 1) IP WANs, where virtual channels between sites are realized using Frame Relay or ATM; and 2) IP VPNs, where Multi-Protocol Label Switching (MPLS), also known as layer 3 switching, is used for defining layer 3 flows though coloring corresponding IP packets. Third and last, QoS can be implemented through one of two architectures, in the order of their development: Integrated services (Intserv) and differential services (Diffserv).

Intserv architecture defines two services:
  1. Guaranteed service--provides deterministic delay; and
  2. Controlled load service--provides best-effort delivery under lightly loaded conditions
Resource ReSerVation Protocol (RSVP) is the end-to-end signaling protocol used in the Intserv architecture, which requires guaranteed per-flow QoS over the IP network. RSVP incurs a scalability issue since the amount of state information that needs to be tracked about individual flows would become intractable as the number of flows increase in a realistic scenario.
In an RSVP implementation, receiving nodes send bandwidth reservation messages to each router en-route back to the service source. This technique allows RSVP-enabled routers to take note of receiving nodes reserving resources for the same flows, inferring a multicast service and aggregating traffic for bandwidth efficiency. The reservation components consist of a traffic receiver (RSVP sender), an RSVP receiver, and a number of RSVP-enabled routers. An RSVP-enabled router is equipped with two local decision modules:
  1. Admission control, which determines the sufficiency of required resources to support the reservation; and
  2. Policy control, which determines whether the user had administrative permission to make that reservation.

Call admission control (CAC) determines the admissibility of real-time traffic to the network when there are not sufficient resources to accommodate such traffic, which cannot be simply dropped as could data traffic. A voice/video call that is being attempted when there are not enough bandwidth and delay guarantees would need to be attempted at a later time or possibly re-routed through PSTN or ISDN. Extensions are defined for policy control as well.

If the reservation passes the two fore-mentioned controls, RSVP sets packet classification and packet scheduling parameters to achieve the desired QoS. RSVP runs directly over IP, with two main message types to note: PATH and RESV, which respectively describe flow parameters and corresponding needed resource guarantees. Generally, RSVP’s working principle of flow-based reservation implies that it wouldn’t scale very well. RSVP has a good business case for small to medium intranets with relatively low link bit rates (below tens of Mbps).

Diffserv architecture differentiates packets of different flows by setting the IP packet header values of the Differentiated Service Code point (DSCP) field, for managing the packets’ Per Hop Behavior (PHB). The DSCP field is used for packet marking following its classification. Diffserv architecture performs the following functions:
  1. Traffic Conditioning, in turn made of
    1. Packet Classification
    2. Traffic Shaping
    3. Traffic Policing
  2. PHB Resource Allocation; Implemented used one or more of the following algorithms: WFQ, CBWFQ, and MWRR
  3. PHB Congestion Avoidance and Packet Drop Policy, operate jointly at TCP/IP levels using one or more of the following algorithms: RED, WRED, ECN, and SPD
The network boundary traffic conditioners consist of

The following definitions are essential to understanding the above Diffserv framework.

Conditioning (classification, marking, policing, shaping)

IP Precedence: A three-bit field in the Type of Service (ToS) byte, set to indicate the relative priority with which a packet should be handled. IP Precedence can be written by the application that created the packet or by a node in the network.

PHB: A pre-defined traffic class that describes the forwarding behavior of a Diffserv node applied to a set of packets with identical DSCP values. A PHB class depends on traffic load, required resource allocation, and packet discard policy.

Explicit Forwarding (EF) PHB: A resource allocation centered PHB that uses Diffserv domains to accommodate an assured bandwidth end-to-end service with low loss, latency, and jitter.

Assured Forwarding (AF) PHB: Provides differentiated service levels among its four traffic classes, where each class is served in a separate queue (a total of 12 service levels).

DSCP: A six-bit field used to indicate a certain PHB in a network. The DSCP field is an extension to the three bits used for IP precedence. It can be set to one of the following: - Default DSCP, best-effort service (DSCP = 000 000) - Class Selector, 7 possible precedence values (DSCP = “001 through 111” 000) - EF PHB, defines premium service (DSCP = 101 110) - AF PHB, 4 service classes, each has 3 drop precedence levels (12 possible DSCP values)

QoS Group: A field (or label) in the packet data structure representation internal to the router that is not a part of the IP packet header. Routers perform packet marking based on the QoS Group using functions like CAR, PBR (Policy Based Router), and QPPB (QoS Policy Propagation using BGP exterior routing protocol.

Resource allocation (queuing, scheduling)

Weighted Fair Queuing (WFQ): Fair Queuing treats each flow in an own logical small queue and services a fractional amount of data in each queue in a round robin fashion. WFQ differentiates flows in the scheduling process, by assigning weights and prioritizing queue servicing, based on the IP Precedence value. WFQ limits packet discard to the most demanding flows.

Class Based WFQ (CBWFQ): Allocates separate sub-queues for each traffic class, enabling users to directly specify the minimum required bandwidth per class.

Modified Weighted Round Robin (MWRR): Round-robin scheduling serves a whole packet at a time instead of a small data unit such as a byte. WRR serves flows according to weights that are assigned to each. MWRR employs a deficit counter attributed to each WRR queue.

Congestion avoidance and drop policy

Random Early Detection (RED): A congestion avoidance queue management algorithm. It drops packets using a probabilistic function once the average queue size exceeds a threshold. The drop probability is set such that packets are dropped only from a few (a minority of) queues.

Weighted RED (WRED): Employs packet drop probability to implement grades of packet service and also supports setting selective RED parameters based on IP Precedence.

Explicit Congestion Notification (ECN): Signals congestion to the TCP source by marking a packet header rather than dropping the packet. It requires setting a bit in the IP packet header so that TCP endpoints could determine at session start whether ECN is enabled at each end.

Selective Packet Discard (SPD): Distinguishes vital routing and network control traffic over user data traffic.

Diffserv architecture achieves scalability by eliminating dependence on per-flow state information through a collection of simplified classification and conditioning functions, implemented only at network boundary nodes. PHB is applied to aggregates of traffic that have been appropriately marked using the DSCP.

The combination of packet marking and well defined PHBs eliminates end-to-end signaling and flow state maintenance and results in a scalable, coarse-grained QoS solution. The disadvantages of Diffserv include:

IETF RFC 2998 describes a generic model in which a Diffserv network can be used in the context of the Intserv architecture to support the delivery of end-to-end QOS. It works by applying the Intserv model end-to-end across a network containing one or more Diffserv regions/domains. As viewed by Intserv, the Diffserv domains are analogous to virtual links connecting Intserv/RSVP capable routers or hosts. Routers within each Diffserv domain implement specific PHBs. The model is a clever engineering compromise between two extremities: pushing a Diffserv region all the way to the network edge, where source and destination hosts are RSVP capable; and pushing Intserv all the way to the core, with no Diffserv domains. Most current routers support both Intserv and Diffserv architectures and allow the above model of an end-to-end Intserv with multiple Diffserv domains.

RSVP vs. PHB RSVP carries the request through the network, visiting each node the network uses to carry the stream. At each node, RSVP attempts to make a resource reservation for the stream, before reporting back to the application and allowing the call/communication. PHB QoS checks the host/application traffic type marking to provide priority on a PHB basis through the network.