Diffserv and QoS in the Internet

Diffserv and QoS in the Internet Adam Burke, Joshua Mentz, Neco Ventura Department of Electrical Engineering, University of Cape Town, Rondebosch, Cape Town, South Africa {aburke, jmentz, neco}@crg.ee.uct.ac.za Abstract - There is a need for mechanisms to support QoS in the Internet to provide adequate services for delay and loss sensitive applications. The IETF has proposed two architectures that can provide these mechanisms. These are the Integrated Services and Differentiated Services architectures. Both architectures have distinct advantages and it is suggested that the best usage scenario involves a combination of them to provide end-to-end QoS guarantees. This paper focuses on the control plane signalling required to support the inter-working of Intserv and Diffserv as well as some of the fairness issues present in the Assured Forwarding per hop behavior of the Diffserv architecture. A testbed network is to be implemented to evaluate the signalling mechanisms in provisioning for end-to-end guarantees and to determine if fairness can be achieved in the Diffserv model. I. INTRODUCTION The Internet has traditionally been used as a medium for the transport of non real-time data. A best effort service is adequate for this purpose. More recently, however, the Internet has been used to transport real-time media such as voice and video. Such media have far stricter Quality of Service (QoS) requirements. There are two main technologies that have been introduced to address the provision of QoS in the Internet. These are Integrated Services (Intserv) [1] and Differentiated Services (DiffServ) [2]. Each of these technologies has their own scope and strengths. They will both be introduced below. The Intserv model allows users to make end-to-end reservations to ensure that the network will provide the required service. The mechanism works as follows: should an application require an end-to-end service, it must first make a reservation using the Resource Reservation Setup Protocol (RSVP) [3]. In RSVP, a path message is sent from the source to the recipient. The path message primes each Intserv router along the path to expect a reservation message. Upon receipt of a path message, the end-point sends a reservation message back to the source along the The authors would like to thank Telkom SA, Siemens, the National Research Foundation (NRF) and the Department of Trade and Industry (DTI) for supporting this research project.

same path. As the message moves upstream, each network element makes a reservation for that particular flow. If the resources aren’t available, the request is denied. There are two QoS classes that can be provided by an Intserv network. The Guaranteed Service class is suitable for applications with strict real-time delivery requirements. This class of service provides an assured level of bandwidth and a firm end-to-end delay. The Controlled Load Service provides no firm quantitative guarantees. The service provided by the network is equivalent to that experienced by a best effort flow on a lightly loaded network. This service is suitable for applications that can tolerate a certain amount of loss and delay. The main drawback of Intserv is that of scalability: should Intserv be implemented in the Internet, core routers would have to perform both RSVP resource allocation as well as per flow scheduling for a large number of flows. The term flow, as used in this paper, refers to a correlated series of packets that consist of the five-tuple: source address, destination address, protocol number, source port and destination port A proposed solution to Intserv’s scalability problem is Diffserv. Diffserv solves this problem by introducing traffic aggregation. The mechanism works as follows: packets belonging to traffic flows that are destined for a Diffserv network are classified according to the class of service that they should receive. This information is placed in the packet’s Diffserv Code Point (DSCP), which is stored in the IP header. Core routers therefore have only to consider the DSCP of a packet to decide what service that packet should receive. A router’s response to a DSCP is known as its “per hop behavior.” Using the mechanism above, relative differential services may be provided. In order to provide improved performance in Diffserv, it is necessary for per flow policing to be performed at the edges of the Diffserv network. By limiting the traffic entering a Diffserv network and providing class aware scheduling in the core, it is possible to provide bounded relative QoS across Diffserv networks. The IETF defines both the Expedited Forwarding (EF) and the Assured Forwarding (AF) classes of service. EF provides a virtual leased line service. It was designed for traffic that requires strict bounds on delay as well as guaranteed bandwidth. EF packets that exceed their negotiated rate are dropped at the ingress to the Diffserv

network. By contrast, AF was designed to provide a service similar to that which a lightly loaded network would provide. It was intended for traffic types that require guaranteed bandwidth with less stringent delay requirements. AF packets that exceed their negotiated rate are re-marked to a higher drop precedence at the diffserv ingress. The Intserv and Diffserv architectures should not be considered to be competing technologies but rather complementary technologies [4]. By using Intserv in the access networks and Diffserv in the core it is possible to meet the user’s requirement for bandwidth guarantees while maintaining the network requirement of scalability. High quality guarantees can best be achieved through the use of signalling of resource requirements while aggregate traffic handling ensures scalability of the overall solution. Network policy elements are introduced in Section 2 as a mechanism to facilitate the merging of the Intserv and Diffserv architectures. Section 3 describes how to achieve end-to-end guaranteed QoS through appropriate signalling mechanisms. Section 4 contains a more detailed description of the Diffserv AF class of service as well as some of its shortcomings. Section 5 proposes a solution to the shortcomings of the Diffserv AF class and gives a description of the evaluation that will be carried out in order to validate the solution. The conclusion is given in Section 6. II. NETWORK POLICY ELEMENTS In order for Intserv reservations to be made over a Diffserv network it is necessary for the Intserv network to have access to information about the availability of Diffserv network resources. It would also be advantageous for the Diffserv network region to be capable of making provision for Intserv style reservations in an aggregated manner. Further, network administrators should be able to control which users, application and hosts are permitted access to particular service levels within their networks. This should all be achievable within a secure, scalable framework [5]. To enable this functionality, network policy elements are required. The two network policy elements that will be discussed here are the Policy Decision Point (PDP) and the Policy Enforcement Point (PEP) [4]. Their positions in a combination Intserv-Diffserv network are illustrated below.

Policy Decision Point Hosts

Intserv Network

Diffserv Network Policy Enforcement Point

Figure 1: PDP and PEP in an Intserv-Diffserv network

The PDP exists solely in the signalling plane of the network and as a result does not directly handle any data streams. It contains a database of network policies and communicates the effects of these policies to the PEP while ensuring that the Diffserv network is effectively provisioned. As well as enforcing the policies of the PDP, the PEP performs admission control, traffic conditioning, policing and traffic classification. A. Functionality of the Policy Enforcement Point The primary function of the PEP is to map Intserv style resource reservations to Diffserv classes of service. When the PEP receives an RSVP reservation message it must perform admission control. The PEP first determines if it has sufficient resources available to provide the required service. If the resources are available, it then sends the reservation request to the PDP where a policy decision is made. Based on the answer returned by the PDP, the PEP either accepts or rejects the RSVP request. This mechanism allows more effective admission control to be applied as the PDP can make decisions based on the requirements and policies of the network administrators and the congestion of the Diffserv network. The PEP must perform traffic conditioning according to the existing reservations. This involves ensuring that each flow does not send data at a rate exceeding that which it has a reservation for. Packets received from a flow at a rate greater than that originally negotiated may be dropped or marked to receive some deprecated service. Per flow policing at this point in the network is an obvious solution as per flow activities should be confined to the access network where scalability is less of a concern. Furthermore, the use of traffic conditioning at this point combined with a flow aware Diffserv implementation will enable a network to ensure fairness among flows and empower the entire network to meet the requested guarantees. In performing the task of traffic classification, the PEP must set the DSCP of those packets constituting flows with existing reservations. The specific DSCP to be applied will be signaled to the PEP by the PDP when the reservation is accepted. For all other flows, the DSCP should be set to an appropriate value to ensure best effort service. Setting the DSCP for all flows ensures that host marking cannot be used to achieve unauthorized access to premium network resources. B. Functionality of the Policy Decision Point The primary task assigned to the PDP is to respond to reservation requests made by hosts connected to the Intserv access network. The response to these requests should take into account the policies set by the network administrator and the current resource usage of customers within the Intserv access network compared with the contracted agreement for provision of services within the Diffserv network region. A single PDP may interact with a number of PEPs thus increasing the scalability of this solution. This is possible as most of the processing load and resource utilization in the Intserv model is in the area of per flow classification and per flow scheduling, thus the signalling aspect is of less concern.

As well as communicating with the PEPs, the PDP should be able to communicate with routers within the Diffserv region as this enables more efficient usage of Diffserv network resources. As discussed in relation to the PEP, resources should be allocated within the Diffserv network only when there is a demand for them. This allows the routers to guarantee the provision of a minimum service level without the need for wasteful over provisioning of resources. The primary function of a router should not be changed from the requirement to forward IP packets. Routers should not expend too much of their resources on signalling with the PDP or dealing strictly with flows with reservations. By dynamically adjusting the bandwidth, memory and processing resources used for providing QoS within the router it is possible for this constraint to be achieved. In this regard, each RSVP reservation request entering the Diffserv network should not result in an adjustment of router configurations within the Diffserv network. Rather, an aggregation technique should be used to limit this potentially repetitive interaction between the PDP and the Diffserv network. The frequency at which changes are made to the Diffserv network elements should be optimized to enable efficient use to be made of resources within the Diffserv network while maintaining the scalability provided by the Diffserv solution. Additional functionality of the PDP may include the ability to communicate with other PDPs in adjacent networks to enable end-to-end QoS signalling. This functionality is described as bandwidth brokering. The existence of bilateral agreements between neighbouring Internet service providers is a pre-requisite for operations of this nature. End-to-end QoS can only be guaranteed if all the transit Diffserv and Intserv networks support the required behaviours and provision their resources accordingly. From an economic standpoint, the PDP can provide a platform from which per flow charges can be levied to customers. Adding QoS cap5abilities to a network will definitely result in additional capital expenditure being incurred by service providers. As they must continue to run economically viable businesses, it is logical for them to ensure that those customers who are receiving premium services are being charged accordingly. This business incentive will be a major driving force in encouraging network service providers to include QoS functionality in their product offerings. Billing would be a fairly trivial task as the resources used by a customer are tracked very precisely by the PDP and this data need only be processed by an accounting package to produce a bill. III. SIGNALLING MECHANISMS FOR QUALITY OF SERVICE PROVISIONING We will be specifically looking into the details of the control plane signalling required to achieve end-to-end QoS. This guaranteed QoS can best be achieved using a combination of the Intserv and Diffserv architectures. One of the challenges in inter-working Intserv and Diffserv is the requirement to perform signalling in both architectures without compromising the design requirements of either one. The

recommended method of dealing with this challenge is to apply policy based admission control to requests from the Intserv network. This portion of the project will entail the implementation of a PDP and the control plane functionality of a PEP. The majority of the work that will need to be done will revolve around the PDP implementation. It is suggested that the PDP must include intra-domain and inter-domain signalling functionality. This will allow end-to-end QoS signalling to be achieved across administrative boundaries between Diffserv networks. The signalling components that will be investigated are illustrated in Figure 2 below. PDP

COPS RSVP

PEP

COPS

PDP

SNMP

Router

Figure 2: Control plane of planned testbed It is envisioned that the Common Open Policy Service (COPS) protocol [6] will be used for sending policy decision requests and responses between the PEP and the PDP. The Resource Allocation Protocol working group of the IETF developed the COPS protocol. COPS uses a simple client/server model to add support for policy control over QoS signalling protocols and is thus ideally suited to extending RSVP signalling into a Diffserv network infrastructure. Furthermore, extending the use of COPS to communication between PDPs enables inter-domain communication and hence bandwidth brokerage functionality can be added to the PDP. The Simple Network Management Protocol (SNMP) [7] will be used for conveying configuration information between Diffserv routers and the PDP. SNMP allows management information for a network element to be queried and altered by a remote user or process. Thus, the current reservation load can be used to decide on the buffer and processor resources within a router that need to be dedicated to meeting the service guarantees. Current network congestion information can also be conveyed from the router back to the PDP. Figure 3 gives an overview of the network topology that will be used. This structure was chosen as it caters for the general case and can be extended and scaled to relate to most network configurations. The anticipated administrative boundaries between the different networks are indicated. In practice, they may not exist in these exact positions but these locations were chosen to allow this framework to be applied to a broad range of practical implementations. The focus in this project is specifically on “Diffserv Network 1” and its interactions with the other networks.

PDP

Traffic Source

PE ATM Switch

probability of their being enqueued vs. being dropped depends on whether the packet is in profile or out of profile.

PDP

Diffserv AF

Diffserv AF

Traffic Sink

PE

Traffic Source

Intserv Access Network

Figure 4 shows an architecture that may be used to achieve the service specified by RFC 2597. Note that in the network element illustrated below, the three drop precedence values have been aggregated into two. These drop precedences share a RIO queue as described previously. Each of the four sub-classes is allocated its own RIO queue in order to provide isolation between them. RIO Queue

Diffserv Network 1

Diffserv Network 2

Round Robin Scheduler

Figure 3: Overview of proposed testbed The initial evaluation stages will be to determine the feasibility of this approach. Once the testbed has been implemented and end-to-end QoS has been achieved, other issues including performance and scalability will be investigated. Areas to investigate in the performance arena would include the setup delays incurred through the combined usage of RSVP and a PDP. In the area of scalability it will be necessary to determine the maximum rate at which a PDP can process RSVP messages.

Figure 4: Four RIO queues leading to an output

Initial studies suggest that a PEP can be implemented on a Smart Port Card (SPC) [8] of a Washington University Gigabit ATM Switch. The switch, together with its SPCs will be used to model a core router. This configuration allows close integration with the switching hardware.

Using this design, core routers need only consider traffic aggregates and not individual flows when processing packets. This implementation does, however, introduce a number of problems. The problems, which fall into three categories, are listed below.

The PDP will be implemented on off the shelf PC hardware running NetBSD. The resource requirements placed on the PDP are less stringent as bottlenecks are not anticipated in the control plane.

1.

There is per flow unfairness within each AF sub-class [11]. In particular, there is unfairness when competing flows differ in the following areas: • Transport protocol: as networks approach capacity allocation, the unresponsive UDP flows receive higher throughput than the responsive TCP flows. • Round trip times: flows with longer round trip times are less robust than flows with shorter round trip times. They thus receive less than their fair share of the available bandwidth in both underprovisioned and over-provisioned networks. • Packet size: flows with larger packet sizes receive higher throughput than flows with smaller packet sizes. This is true in the case of both underprovisioned and over-provisioned networks.

2.

Using Random Early Detection or similar mechanisms such as RIO on TCP traffic has been shown to result in instability [12]. This is most marked in situations where link capacities are high and delays are long. These conditions are exactly what one expects to find across Diffserv networks in the Internet. The instability can have the following results: Increased end-to-end jitter Increased packet losses Underutilized network links Reduced responsiveness for interactive applications.

To Output Port

IV. IMPROVING FAIRNESS LEVELS IN THE AF CLASS The AF class is one of the service classes that were specified by the IETF for use within Diffserv networks. It was intended for traffic that requires guaranteed bandwidth. The AF class comprises four sub-classes of service each containing three drop precedence values. The four subclasses are intended to provide tiered levels of service. The three drop precedence values are intended for situations where traffic sources wish to inject additional traffic into the network at the risk of a higher number of packets being dropped. This mechanism works as follows: should a source exceed its negotiated sending rate, all offending packets are remarked with a higher drop precedence when they enter the Diffserv network. Traffic sources may thus trade off throughput with packet losses. RFC 2597 [9] specifies the behaviors that AF routers should exhibit. It makes no recommendations about the specific scheduling mechanisms that should be implemented. Random Early Detection with In/Out of profile (RIO) has, however, been found to work better than other flow unaware active queuing mechanisms [10] and it is a popular choice for AF networks. With RIO, although both in profile and out of profile packets are placed on the same queue. The

• • • • 3.

When aggregates containing many flows compete with aggregates containing fewer flows, the aggregates containing many flows receive more than their fair share of the available bandwidth [11]. A scenario

where this may occur is where two competing network traffic sources have identical service contracts with a Diffserv network. If one of the networks has a hundred flows and the other one has a thousand flows, the network traffic source with a thousand flows will consistently outperform the source with only a hundred flows. The factors mentioned above result in a situation where the behavior of the Diffserv network core isn’t predictable, but rather that it depends on a number of factors such as traffic type, end-to-end delay and the number of flows in an aggregate. As a result of this, the AF class can offer only relative service differentiation between classes and not absolute guarantees [13]. The value of providing a relative service to applications is questionable as real applications have requirements that are absolutely quantifiable. As a solution to the problems of unfairness between competing flows as well as the instability of TCP/RIO, this paper proposes employing flow aware core network elements instead of flow unaware active mechanisms such as RIO. The question of scalability is relevant as one of the features of Diffserv is that it was designed for large networks that Intserv couldn’t scale to. The following points relate to this issue. • Whereas Intserv routers have to perform both per flow RSVP accounting and per flow scheduling, the proposed routers would only be required to perform per flow scheduling. • Routing technology has advanced rapidly. In particular, modern routers are able to efficiently perform per flow scheduling at line speeds of 10 Gbps [14]. Most current Internet core routers have line speeds of up to 2.5Gbps. As a solution to the unfairness between competing AF aggregates, this paper proposes employing a mechanism whereby Diffserv network PDPs send information about competing traffic aggregates to the relevant core routers. The core routers are in turn required to ensure that each aggregate is allocated its fair share of the available bandwidth. Although it would be possible to implement the proposed routers incrementally on a Diffserv network, it would only be once all routers in the network implemented the proposed mechanisms and effective admission control existed that the behaviour of traffic in the core would become consistent and predictable. Only once this consistency and predictability has been achieved, would it become possible to quantitatively guarantee the services offered by a Diffserv network without significant over-provisioning. V. PROPOSED EVALUATION OF AF The testbed that will be used for the proposed evaluations will be the one described and illustrated towards the end of Chapter III. In the evaluations of AF, the focus will be on the scheduling mechanisms within the router. Because RFC 2597 specifies that sub-classes should be isolated, it will only be necessary to consider a single sub-class. The results will apply to each

of the four AF sub-classes. Similarly, only two drop precedence values will be considered. The rationale for this is firstly that the results could be extended to include three drop precedence values; and secondly that RFC 2597 permits the aggregation of the three drop precedence values to two. A. Unfairness Between Flows and RIO/TCP Instability The issue of unfairness between competing flows within the same AF sub-class as well as the issue of RIO/TCP instability will be investigated. In the first stage of evaluation, a single flow unaware RIO queue will be implemented at the router. In subsequent stages, a flow aware mechanism will be used. Here, each flow will be allocated a separate queue. Deficit Round Robin (DRR) scheduling will be used to service the queues. This mechanism is shown in Figure 5 for the case where there are N flows. DRR S c h e d u le r

N F IF O Q ueues

T o O u tp u t P o rt

N

N

Figure 5: Queuing and scheduling mechanism for N flows In the flow aware scheme, before a packet is enqueued, both the drop precedence value of the incoming packet and the current queue occupation level of the target queue will be considered in deciding whether to enqueue or drop the packet. Each queue will have two threshold levels that will be used to determine whether to enqueue or drop the incoming packet. This is illustrated in the following diagram. All packets dropped Only high drop precedence packets enqueued Buffer Occupancy Level

Empty

All arriving packets enqueued

Figure 6: Per flow drop levels on AF queue. It is important that the maximum burst size as well as the maximum permissible delay be considered when deciding on the setting of the drop thresholds. When addressing unfairness between competing flows, the throughput of the link between the router and the traffic sink will be varied so that results may be obtained for varying levels of congestion. A number of variants of input traffic types will be tested. In particular, comparisons will be made when flows vary in terms of the following:

• • •

Transport protocol Packet size Round trip time

It is expected that the flow aware solution will provide increased levels of fairness, especially in the case of an under provisioned network. When evaluating the instability that results when using RIO with TCP, the throughput of the link between the router and the traffic sink will be varied and the traffic sink will be varied in terms of delay. RIO will be compared with the flow aware scheme in terms of the following metrics: • Packet loss • End-to-end delay • Bottleneck link utilization It is expected that when the bandwidth-delay product is large, the flow aware solution will provide reduced packet losses, reduced end-to-end delay variation and improved bottleneck link utilization. B. Unfairness Between Competing Aggregates The issue of fairness between aggregates with different numbers of flows will be explored using a scenario where network traffic sources 1 & 2 are identical in terms of their aggregate service level agreements. They will, however, vary in terms of the number of flows emanating from them. As before, traffic from both network sources will be sent to a single router that will route all the data out along a single bottleneck link. The fairness of the bandwidth allocation along the bottleneck link will be evaluated. Once more, two stages of evaluation will be performed. In the first stage, the core router will not be aware of the bandwidth that should be allocated to each network traffic source aggregate. In the second stage, the PDP will explicitly inform the core router that each network traffic source should receive an equal share of the output link bandwidth. The core router will in turn perform aggregate aware scheduling. This aggregate awareness will be possible based on the subnet addresses of each network traffic source. The levels of fairness will be compared for the two series of evaluation. It is expected that the aggregate aware solution will provide consistently improved levels of fairness. VI. CONCLUSION The Diffserv and QoS in the Internet project focuses on the control plane issues and on scheduling mechanisms within Diffserv AF. By combining the Intserv and Diffserv architectures we will produce a framework that may be used to implement quantitative end-to-end QoS guarantees. This framework will be evaluated and tested using a network testbed that the authors will design and implement.

REFERENCES [1] R. Braden, D. Clark, S. Shenker, “Integrated Services in the Internet Architecture: an Overview”, RFC 1633, June 1994 [2] S. Blake et al, “An Architecture for Differentiated Services”, RFC 2475, December 1998 [3] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin,“Resource ReSerVation Protocol (RSVP) Version 1 Functional Specification”, RFC 2205 , September 1997 [4] Y. Bernet, “The Complementary Roles of RSVP and Differentiated Services in the Full-Service QoS Network, IEEE Communications Magazine”, February 2000 [5] Y. Bernet et al, “A Framework for Integrated Services Operation over Diffserv Networks”, RFC 2998, November 2000 [6] D. Durham, J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. Sastry, “The COPS (Common Open Policy Service) Protocol”, RFC 2748, January 2000 [7] J. Case et al, “A Simple Network Management Protocol (SNMP)”, STD0015, May 1990 [8] J. DeHart, “Washington University Smart Port Card”, http://www.arl.wustl.edu/arl/projects/ann/slides/spc.pdf January 2000 [9] Heinanen, J. Baker, F. Weiss, W. Wroclawske, J. “Assured Forwarding PHB Group", RFC 2597, June 1999 [10] Makkar, R. Lambadaris, I. et al. "Empirical Study of Buffer Management Scheme for DiffServ Assured Forwarding PHB" Proc. of Ninth International Conference on Computer Communications and Networks, Las Vegas, Nevada, October 2000. [11] Seddigh, N. Nandy, B. Pieda, P. "Bandwidth Assurance Issues for TCP Flows in a Differentiated Services Network" Proc. of the IEEE GLOBECOM, Rio De Janeiro, Brazil, December. 1999. [12] Low, S. Paganini, F. Wang, J. Adakha, S. Doyle, J. "Dynamics of TCP/RED and a Scalable Control" To appear in Proceedings of IEEE INFOCOM 2002. New York, NY. June 2002. [13] Christin, N. Liebeherr, J. Abdelzaher, T. “A Quantitative Assured Forwarding Service” To appear in Proceedings of IEEE INFOCOM 2002. New York,. June 2002. [14] Ezchip press release: "EZchip Introduces a 10G/OC192 Traffic Manager to Broaden its Next-generation Network Processor Architecture" [Online]. Available: http://www.ezchip.com/html/press_011022.html October 2001.