QoS Models

RFC2386 [52] characterizes Quality of Service (QoS) as a set of service requirements to be met by the network while transporting a packet stream from the source to the destination. For the current Internet there are two different models to obtain a QoS guarantee: the Integrated Services (IntServ) [42] and Differentiated Services (DiffServ) [43]. In the section the basic concepts of the two models are introduced.

4.2.1 Integrated Services (IntServ)

The Integrated Services (IntServ) approach [42] aims to provide applications with a guaranteed share of bandwidth. IntServ operates on a per-flow basis, and the requested QoS for a flow is either fully granted or denied.

Three main services are provided to applications: (1) Guaranteed services [53] provide an assured amount of bandwidth, strict end-to-end delay bounds, and minimal queuing delay to packets, (2) Controlled load services [54] give a service that is as close as possible to a best-effort service in a lightly loaded network, and (3) Best effort services are characterized by the absence of a QoS specification. The first two services classes use parameters, such as token bucket rate and size, peak data rate, and minimum and maximum packet size. These provide detailed information about the intended packet stream, so that routers are able to produce detailed reservations.

The IntServ approach assumes that an explicit setup mechanism is used to convey resource requests to routers so that they can provide the requested services to flows that require them. Moreover, the signaling must establish and keep the reservation state in order to guarantee the resources promised. Resource

Reservation Protocol (RSVP) [44] can be used to create and maintain the required flow-specific states in network elements allowing them to provide the requested services. RSVP is a signaling protocol that applications may use to reserve resources for all kinds of flows in an IP network. The network routers respond by explicitly admitting or rejecting RSVP requests.

The main message types in RSVP are the Path message, which is transmitted by the sender to initialize a new flow, and the Resv message, which comes back upstream to the sender, applying the actual resource reservations at the routers. The sender includes the wanted QoS with the Path message, which causes the Path-state to be initialized at every RSVP-aware router receiving the message. The Resv message follows exactly the same route as the Path message and sets the reservation if possible. The Path and Resv messages are refreshed periodically, and if a router does not receive a refreshing message within a specified time, it will remove the reservation state and the allocated resources.

The components of integrated services are admission control, classifier, packet scheduler, and resource reservation protocol. 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. When a host requests a real-time service along some path, the admission control is invoked at every intermediate node to make a local accept/reject decision. The classifier determines what classes the packets should be placed in based on the information in the header, such as IP and port source and destination addresses. The purpose of the classifier is to map each incoming packet into some class for the purpose of traffic control. All packets in the same class get the same treatment from the packet scheduler. The packet scheduler manages the forwarding of different packet streams using a set of queues and other mechanisms such as timers. The scheduler determines the order in which the packets should be serviced by placing them into priority queues. Resource reservation protocol (RSVP) is used as an IP signaling protocol to create and maintain the state in the routers along the path of a flow.

4.2.2 Differentiated Services (DiffServ)

DiffServ [43] does not define any signalling mechanisms, but instead, it provides QoS by dividing traffic into a small number of classes and allocating network resources on a per-class basis. The class is marked directly on the packet, in the 6 bit DiffServ Code Point (DSCP) field. The DSCP field is part of the original type of service (ToS) field in the IP header. The IETF redefined the meaning of the little-used ToS field, splitting it into the 6-bit DSCP field and a 2- bit unused field. The unused field is being allocated to the Explicit Congestion Notification (ECN) mechanisms [55], as shown in Figure 4.1.

Precedence TOS MBZ 0 1 2 3 4 5 6 7

DSCP ECN

0 1 2 3 4 5 6 7

Figure 4.1 TOS and DSCP + ECN

The basic goal of the Differentiated Services architecture is to meet the performance requirements of the users. Different traffic classes have different priority levels and scheduling algorithms have to ensure high priority packets are forwarded before low priority ones.

The DSCP determines the QoS behaviour of a packet at a particular node in the network. This is called the per-hop behaviour (PHB) and is expressed in terms of the scheduling and drop preference that a packet experiences. From an implementation point of view, the PHB translates to the packet queue used for forwarding, the drop probability in case the queue exceeds a certain limit, the resources (buffers and bandwidth) allocated to each queue, and the frequency at which a queue is serviced. The IETF defined a set of 14 standard PHBs as follows:

• Expedited forwarding (EF) [56, 59]. Traffic encounters minimal delay and low loss. From a practical point of view, this means a queue dedicated to EF traffic for which the arrival rate of packets is less than the service rate, so delay, jitter and loss due to congestion is unlikely. Voice and video streams are typical examples of traffic mapped to EF: they have constant rates and require minimal delay and loss.

• Twelve assured forwarding (AF) PHBs [57]. Each PHB is defined by a queue number and a drop preference. The IETF recommends using four different queues with three levels of preference each, a total of twelve distinct AF PHBs. The convention for naming the AF PHBs is AFxy, where x is the queue number and y is the level of drop preference. All packets from AFxy will be put in the same queue for forwarding, so that packets from an application cannot be reordered if they differ only in the drop preference. The AF PHBs are applicable for traffic that requires rate assurance but that does not require bounds on delay or jitter.

• Best effort (BE). There is no guarantee for QoS. Traffic receives no special treatment. Every packet gets the service that the network is able to provide. DiffServ provides differential forwarding treatment to traffic, thus enforcing QoS for different traffic flows. It is a scalable solution that does not require per- flow signalling and state maintenance.

DiffServ is a fully distributed and stateless model. No state information is required to be maintained at any node. The model aims at pushing the complexity to the edge nodes of the network so that the process in intermediate nodes can be as simple and fast as possible. Instead of providing QoS at per flow granularity, DiffServ differentiates the traffic into a fixed number of classes.