Analysis of the interoperation of the Integrated Services and Differentiated Services Architectures M. Fabiano P.S. and M.A. R. Dantas Departamento da Ciência da Computação, Universidade de Brasília, 70.910-970 mario@cic.unb.br Abstract The Integrated Services and the Differentiated Services architectures are the two main proposals for providing Quality of Service in IP networks. In spite of the fact that each of these architectures are being developed by different groups and have different characteristics and goals, there are many advantages in their use in a common framework. This paper analyses the main subjects related to the interoperability of IntServ and DiffServ networks through the use of simulation and analytical models. In addition, several rules of thumb are derived and schemes for the implementation are proposed. Keywords : QoS, IntServ, DiffServ, Networks 1. Introduction There is a strong need for service differentiation in the Internet. The growing popularity of real-time applications and the commercial requirements of Service Providers are creating a strong demand for a simple and effective way to distinguish traffic and provide different network treatment to each traffic class. In the last years, two main proposals to implement this in IP networks have emerged : the Integrated Services[8] and the Differentiated Services [9] architectures. The Integrated Services architecture has as its main characteristics the dynamic reservation of network resources prior to traffic transmission and a per-flow granularity in the traffic distinction and treatment. It is suitable for applications which require more predictable network service than is available with the traditional IP best-effort packet delivery model. The reservation is accomplished by using a signaling protocol such as RSVP and can be initiated by an application, which specifies the characteristics of its traffic. Provision of end-to-end QoS control is based on the concatenation of network elements" along the data transmission path. Each network element implement admission control, resource reservation and traffic policing in a per-flow basis, resulting in a dynamic and efficient network resource management. On the other hand, this also leads to a poor scalability, which is the main reason of the poor acceptance of the Integrated Services architecture as a solution for providing Quality of Service in the Internet. There are two different services currently defined for the Integrated Services architecture. The first is the Guaranteed Service, which specifies strong quality requirements for the treatment of conformant traffic, including quantitative bounds for delay and packet loss. This service is more suitable for applications with strict service requirements, such as non-adaptive real-time. The other is the Controlled Load Service which has no quantitative requirements and has as its main purpose to provide an approximation of the behavior of an unloaded best-effort network for application traffic. The Differentiated Services architecture proposes a scalable model for traffic differentiation by pushing the complexities to the borders of the networks and simplifying the core. In this scheme, the traffic is classified, marked, policed and possibly shaped by the routers in the networks edges, while the ones in the core only implements the treatment provided for the different classes of traffic. The traffic differentiation inside the network is achieved by the marking of a field (Differentiated Service field or DS field) in the header of IP packets: packets with the same value in the DS field receive the same treatment inside the network. Packets in different flows can have the same value in the DS field, providing the aggregation of traffic.
There are two types of treatments (known as Per Hop Behaviors or PHBs) which can be implemented for the traffic in a network with Differentiated Services. One is the Assured Forwarding PHB Group which provides a very high probability of delivery for packets in conforming flows. The AF PHB Group specification [] provides four different classes of traffic with three different drop precedences in each class, resulting in twelve different PHBs. Buffer space and other network resources must be allocated to each class. In addition, an active queue management algorithm such as RIO [4] must be used in each class to implement the drop precedence. The Expedited Forwarding PHB is the second PHB already specified by the IETF []. The main purpose of this PHB is to emulate a leased line which can be use to provide quality of service to applications with strong requirements. Some good examples of such applications are the ones related to telephony or videoconferencing over IP networks. In a real network, it will be more likely that both the IntServ and the DiffServ models will be deployed than just one of them. The reason is that each standard has different characteristics which can be seen as complementary. The Integrated Services model has a flow orientation which helps to assure that network resources are optimally used. In this model, quantitative QoS applications use an explicit setup mechanism (e. g. RSVP) to request resources from the network, which can accept or reject each request. This is called explicit admission control. On the contrary, Differentiated services use a flow aggregation traffic control with no signaling, which can be quite ineffective. The DiffServ model has the advantage of being scalable (as a result of its flow aggregation granularity), while the IntServ model raises concerns about scalability. It is possible to combine the Integrated Services and the Differentiated Services models, and yet obtain the best characteristics of each to provide end-to-end QoS. Such a framework is being designed in the IETF [13]. In this work, we investigated subjects related to the implementation of Controlled Load service over a network with Differentiated Services. With this aim, simulations were used to study several aspects of this implementation. Many of these aspects were discussed in other works [2] [13], but to the best of the author s knowledge they were never evaluated with a focus on the implementation. 2. Subjects Related to the Implementation of the Controlled Load Service over Differentiated Service Networks The Controlled Load service doesn t require quantitative guarantees from the network, simplifying its implementation in a Differentiated Services domain. The essence of this service is that conforming traffic must experiment a network treatment which must approximate the one received by best-effort traffic under unload conditions. This characteristic also turns this service best suited to be implemented in a DiffServ domain using the PDB Group Assured Service, saving networks resources and simplifying the implementation [2]. However, there are some requirements which must be satisfied by any successful Controlled-Load implementation [1]: the packet dropping behavior for flows conforming to their reservation must be minimal (in [1] it is specified that the percentage of packets not successfully delivered must closely approximate the basic packet error rate of the transmission medium ); the packet queuing delay must be little or nonexistent over all timescales significantly larger than the required for the maximum size data flow to be transmitted at the flow s requested transmission rate ; the network element must continue to provide the contracted the quality of service to those flows not experiencing excess traffic; excess controlled-traffic should be prevented from unfairly impact the handling of arriving best-effort traffic; consistent with 3 and 4, excess traffic should be forwarded whenever possible. For responsive flows in an Assured Forwarding PDB, the accomplishment of these requirements is not straightforward. As noticed in several works [3][4][5][6][7], the packet dropping scheme based on the profile marking at the edges of the network and in active queueing management mechanisms used in the AF PDB, does not deliver enough service differentiation between flow aggregates. In [3] and [4], it has been observed that TCP flows in AF PDBs with higher Round-Trip-Times receive less network resources and have a lower overall throughput than the others. In [3] is has been also noticed that TCP sources with higher reservation rates often doesn t reach them, while connections with small rates often reach or exceed them. For the Controlled-Load Service implementation, the analysis will comprise three different parts. First, the packet dropping characteristics will be investigated for responsive and non-responsive traffic. After, the fairness of
per-aggregation and per-flow policing will be studied. Finally, the delay will be evaluated against flows with similar traffic profile characteristics. 3. Simulation Topology The network topology chosen for the simulation was a Dumb Bell, shown in figure 1. This topology was chosen on account of its simplicity, which facilitates the analysis of the results of the simulations. The simulations were run with 50 sources of traffic during 100 seconds, which were configured in all the simulations to start transmitting on a random moment between the first 20 seconds. Each link from one source to the network core had a bandwidth of 10 Mbps, and the network core itself had a link of 5 Mbps. All the simulations were performed using the NS2 [14] simulator. In the simulations it was assumed that best effort traffic wouldn t interact with flows with reserved resources in the same traffic class. This assumption derives from the Controlled Load specification [1], which requires an isolation between best-effort traffic and excess Controlled Load traffic. Figure 1: Simulated topology 4. Analysis of the Packet Dropping characteristics As noticed in several works [3] [5] [6], the Assured Service PHB needs more network resources than the ones required by the flow reservations in order to deliver the quality of service expected for each traffic flow. This means that the sum of the reserved rates for the flows in a AF class shall be lower than its bandwidth. Thus, in order to study the support of the Controlled Load Service in a AF PHB, the admission control procedure must. We investigated the packet dropping behavior of a DiffServ network with three different parameters: the ratio between the reserved bandwidth and the AF class bandwidth, the token bucket size of the flows and the packet discard probability in the network core. Our aim was to study the influence of these parameters in the support of packet dropping requisites of Controlled-Load flows in a DiffServ network. With this objective, we simulated a Differentiated Service domain with the topology shown in figure 1. Simulations were run first to investigate the influence of the out-of-profile packet dropping discard probability over the conforming packet dropping behavior of an AF aggregation. As pointed in [13], this parameter can have a strong effect in the number of discarded packets and in the throughput of responsive (TCP) flows. In the simulations, 50 FTP sources were used to emulate long-lived TCP connections. Each FTP flow was policed against a token bucket similar to the one specified in the traffic specification (Tspec) for Controlled Load service flows, and each flow had the same token bucket size (10 packets) and rate. The token bucket rate for the flows was varied between 10000 bps and 10000 bps in the simulations in order to vary the rate of the reserved and total bandwidth between 20% and 100%. In addition, the packet discard probability of out-of-profile packets was varied between
0.05 and 0.1 and the RIO parameters used were 10/20/[0.5 1.0] for out-of-profile packets and 29/40/0.01 for conformant packets. Table 1 (below) shows the packet dropping results. Each simulation was run 5 times with the same parameters. The results shown are the average for the 5 simulations. Discard Probability Service 0.5 0.6 0.7 0.8 0.9 1.0 Ratio 10% 12.0 10.0 7.0 3.8 2.2 2.6 20% 17.4 11.4 6.8 1.6 2.6 2.0 30% 16.6 11.4 2.6 2.0 1.8 0.6 40% 7.8 5.2 6.0 6.4 3.8 2.0 50% 211.8 221.4 204.6 205.8 217.6 200.2 Table 1: Green Packet Dropping Results The simulations show that for low values of the service ratio (ratio between the reserved bandwidth and the total bandwidth), the number of discarded packets is small and conformant to the Controlled Load requisites. In addition higher values for the out-of-profile packets discard probability diminish the number of packets discarded. For service ratios with reserved share of 50 % and above, the number of packets discarded grows abruptly to values out of the quality requisites for the Controlled Load service. Moreover, the influence of the packet discard probability is small. A second sequence of simulations was run to investigate the effects of the variation of the token bucket size in the profile of each flow in the packet dropping behavior of the network.. With this aim, 50 FTP sources were configured with a service profile (token bucket size and token bucket rate) which varied during the simulations. The profile rate for each flow was varied from 20 kbps to 100 kbps, which resulted in a variation of the ratio of the reserved bandwidth and the total bandwidth in the network core from 20% to 100%. The bucket size was varied from 1 packet to 20 packets. The results summarized in summarized in table 2 show the overall number of in-profile packets discarded. Bucket Size Service 2 4 6 10 16 20 Ratio 20% 178 196 117 110 70 133 30% 227 92 34 40 46 61 40% 398 33 14 36 52 86 50% 377 91 41 318 455 551 60% 340 146 116 1796 2608 2990 70% 342 75 1379 2809 3930 4017 Table 2: Bucket Size Results The simulations show that the token bucket size influence the in-profile packet dropping behavior for high service rates. For service rates of 60% and above, variations of the bucket size from 6 packets to 20 packets caused huge variations in the number of dropped packets. In addition, small sizes of the bucket size (2 and 4 packets) caused a great number of packet drops. This aspect was observed for all the values of the service rate simulated. 5. Analysis of Per-Flow and Per-Aggregation Policing in the CL implementation over DiffServ networks In [2] and [13] there is a strong suggestion for the use of per-aggregation policing in the implementation of the Controlled-Load Service over DiffServ networks. In this approach, each aggregation is policed against a token bucket created using the rules for sum of reservations described in [1]. The per-aggregation policing has the advantage of being more scalable than the per-flow policing. However, it is not clear if this advantage comes at the price of worsening unfairness at the network core. In a AF Differentiated Services network there is no isolation between the flows in the same aggregation, as there is in a Integrated Services network. Thus, it is expected that for busty flows there will be unfairness, as flows with excess traffic get more resources than well-behaviored ones. Plus, excess traffic can cause congestion in the core of the network, degrading the quality delivered to in-profile flows (green packets). Although these characteristics where studied in some works before [3][4][5][6], they were never analyzed in the context of the CL support in a DiffServ domain. It is interesting to see how these characteristics can affect a possible implementation of a Controlled-Load Service over a DiffServ domain with per-flow and per-aggregate policing.
Our first simulation was run in a Dumb Bell topology and has as its objective to study the impact of the use of aggregation policing in responsive (TCP) flows. With this aim, the simulation was run with 50 FTP sources in a network with per-flow policing and aggregation policing. The RED parameters used were 10/20/0.1 for red packets and 20/40.0.02 for green packets. The flows have different characteristics of RTT and assured throughput, in order to discover the impact of the differentiation of the policing in the flow s traffic characteristics. The results are shown in the graphics below. Goodput (bytes/s) 16000 15000 14000 13000 12000 11000 10000 9000 0 50 100 150 200 250 RTT (ms) Goodput (bytes/s) 16000 15000 14000 13000 12000 11000 10000 9000 0 50 100 150 200 250 RTT (ms) Figure 2(a) and 2(b): Goodput distribution with per flow (a) and per aggregation (b) policing Figures 2(a) and 2(b) show the goodput (average throughput of successfully delivered packets) variation with the service ratio, wich was raried form 10% to 100%. The 50 FTP flows were grouped in 5 classes of delay: 5ms, 50 ms, 100ms,150ms and 200 ms. Each class had 10 flows with the same characteristics. The results shown are the average goodput obtained for the flows in each class. The simulations show that there is not a remarkable difference in the achieved rate of the flows in a network with per-flow policing and in a network with peraggregation policing. Next we studied the impact of excess non-responsive (UDP) traffic in responsive TCP flows. The aim of this sequence of simulations was to investigate if the per-flow policing can provide more protection for the in-profile flows than the one provided by per-aggregation policing. Simulations were run with 30 FTP sources and 20 nonresponsive sources, ten of which generated excess traffic. The excess traffic generated was configured to obtain a rate which varied from 10% to 55% of the total traffic. Thus, the sum of the excess rate and the reserved rate varied from 55% to 100% of the core link bandwidth. Bandwidth (bytes/s) 15000 14000 13000 12000 11000 10000 9000 55 65 75 85 95 Excess Traffic Rate and Reserved Rate (%) Figure 3: Bandwidth of Responsive flows in a network with excess non-responsive traffic As shown in figure 3, there isn t a remarkable difference in the bandwidth obtained with per-flow policing and the one obtained with aggregation policing. The packet dropping characteristics observed (not shown) also didin t provided differences between the two types of flows for responsive traffic.
7. Conclusion and Further Work In this work we studied some aspects of the interoperation of the Integrated Services and the Differentiated Services architectures. The packet dropping behavior of the interoperation of the Controlled Load service and the Assured Forwarding Service was studied with the evaluation of the bucket size and packet discard probability influence for responsive traffic. Results showed that the packet discard probability can influence the number of inprofile packets for low service rates (less than 40%) discarded. On the other hand, the bucket size has stringer influence over the packet discard behavior for higher sevice rates (60% and above). In addition two types of policing were evaluated: per-flow and per-aggregation. The results showed that both types of policing have the same characteristics of flow protection from excess traffic and isolation. However, the peraggregation policing has advantages when compared to the per-floe policing, related to its scalability characteristics. Future works will study the delay aspects of the interoperability, with special attention to the implementation of the Guaranteed Service of the IntServ architecture over Differentiated Service networks. References [1] J. Wroclawski. Specification of the Controlled-Load Network Element Service, RFC 2211, september 1997 [2] A. Charny and J. Wroclawski. Integrated Service Mappings for Differentiated Service Networks, IETF Draft, march 2000 [3] J. Ibanez and K. Nichols. Preliminary Simulation Evaluation of an Assured Service, IETF Draft, August 1998. [4] D. Clark and W. Fang. Explicit Allocation of Best-Effort Packet Delivery Service, ACM Transactions on Networking, Vo. 6, Number 4, august 1998, pp. 361-373 [5] M. Goyal, A. Durresi, R. Jain and C. Liu. Performance Analysis of Assured Forwarding, IETF Draft, october 1999. [6] J. F. Rezende. Assured Service Evaluation. In IEEE Global Telecommunications Conference- GLOBECOM 99 (Rio de Janeiro, December 1999) [7] S. Sahu, P. Nain, D. Towsley, C. Diot and V. Firoiu, On Achievable Service Differentiation with Token Bucket Marking for TCP. UMASS CMPSCI Tech Report, december 1999 [8] J. Heinanen, F. Baker, W. Weiss and J. Wroclawski. Assured Forwarding PHB Group, RFC 2597, June 1999 [9] S. Floyd and Van Jacobson. Random Early Detection Gateways for Congestion Avoidance. IEEE/ACM Trasactions on Networking, August 1993 [10] V. Jacobson, K. Nichols and L. Zhang. A two-bit Differentiated Services Architecture for the Internet, RFC 2638, june 1999 [11] V. Jacobson, Differentiated Services Architecture. talk in the Integrated Services Working Group at the Munich IETF meeting, august 1997 [12] A. Charny. Delay Bounds in a Network with Aggregate Scheduling, IETF Draft Work in Progress, february 2000 [13] Y. Bernet, P. Ford, R. Yavatkar, F. Baker, L. Zhang, M. Speer, R. Braden, B. Davie, J. Wroclawski., E. Felstaine. A Framework for Integrated Services Operation over Diffserv Networks. IETF RFC 2998, november 2000 [14] The Network Simulator ns-2: Documentation. December 2000. http://www.isi.edu/nsnam/ns/.