Comparing the utilization bounds of IntServ and DiffServ - CiteSeerX

Comparing the utilization bounds of IntServ and DiffServ

∗

S. Terrasa

S. S´aez J. Vila E. Hern´andez Universidad Polit´ecnica de Valencia, C/Camino de Vera s/n 46022 Valencia, SPAIN {sterrasa, ssaez, jvila, enheror}@disca.upv.es

Abstract This paper analyzes the trade-off of providing deterministic QoS guarantees versus achieving a good bandwidth utilization. This issue has been adressed with different philosophies under the IntServ and DiffServ approaches. This paper compares the achievable bandwidth utilization for IntServ and DiffServ approaches using, on one hand, the formulas given by the network calculus and, on the other, simulations of a realistic workload on a DiffServ architecture. Results allow, not only to compare the IntServ and DiffServ approaches, but also how pessimistic are the bounds provided by network calculus.

1

Introduction

Transporting multimedia traffic while guaranteeing a requiered Quality of Service (QoS) is a chalenging problem that has recived a lot of attention in recent years. Two main approaches has been developed: integrated services (IntServ) and differentiated services (DiffServ). IntServ architecture is based on reserving network resources between individual flows, while DiffServ architecture is based on provisioning network resources between traffic aggregates. Designing efficient algorithms for traffic control and resource allocation (or provisioning) in these approaches is very difficult since VBR (Variable Bit Rate) video is both delay-sensitive and has a high degree of burstiness. Although both the IntServ and DiffServ approaches can offer different service classes, the underlying discussion or the main trade-off between these two approaches is, basically, the one of deterministic guarantees versus bandwidth utilization. IntServ relies on admission control and can offer deterministic bandwidths and end-to-end delays to individual flows at the cost of placing strict resource reservations that guarantee the worst case scenario. Since this case occurrs very seldom, a lot of bandwidth is wasted. On the other hand, DiffServ prioritizes flows according to their service class and provides a much better bandwidth utilization, because no admission control is performed. The cost is a higher degree of uncertainty: it cannot offer guarantees to individual flows, the maximum delay and jitter are difficult to calculate, packet losses may occurr etc. It is obvious that higher priority classes will get a better service in DiffServ than in a flat service class, but the key question is: although deterministic guarantees cannot be offered, is it possible to quantify or to put put bounds on the QoS parameters provided by DiffServ?. The answer to this question is, perhaps, the main goal of a discipline known as Network Calculus. Some recent advances in network calculus [3] have established a delay bound for the Expedited Forwarding (EF) behaviour of DiffServ. On the other hand the realtion between reserved bandwidth and delay bound were also established by [12][13]. ∗

This work was supported by the Spanish Government Research Office (CICYT) under grant TIC99-1043-C03-02

P10/1

The primary goal of this paper is to compare the achievable bandwidth utilization for IntServ and DiffServ approaches using, on one hand, the formulas given by the network calculus using a realistic workload with QoS demands (maximum delay) and, on the other, simulations of a DiffServ architecture. Results using network calculus show that IntServ cannot guarantee beyond a 40% of bandwidth utilization but, surprisingly, DiffServ EF achieves even less than that. This rises another interesting issue: the goodness of theoretical bounds. From the above results, it is not clear whether the utilization bound for EF provided by the network calculus is not very accurate or whether DiffServ provides a good average case delay but a very bad worst case delay. That makes interesting to know the delay distribution. According to this, a second goal of this paper is to check how good are the formulas provided by network calculus. This is done through simulation. Results show that utilization bounds provided by network calculus are in general quite pessimistic. This paper is organized as follows: section 2 presents the main results of network calculus, section 3 describes the simultaion tools and workload description, section 4 describes the experiments and main results and, finally, section 5 concludes the paper.

2 2.1

Network calculus results Integrated services and GPS Scheduling

The integrated services architecture uses a per-flow management approach of the workload with QoS requirements. It is based on and admission control test, a resource reservation protocol (RSVP) to reserve bandwidth along the path that one connection crosses and GPS scheduling of the different flows. The GPS scheduler is an idealised fluid discipline that is easy to implement. A seminal work by Parekh and Gallager [12][13] introduces an equation to obtain the maximum delay when the traffic is leaky-bucket regulated at the input. This kind of traffic is constrained by the following function α(t) = σ + ρ(t) where σ is the bucket depth and ρ is the drain rate. Under this assumption, the end-to-end delay bound is a function of the reserved bandwidth in the links and usually calculated using a traffic and network model. This delay bound can be calculated by means of this equation: Di =

σ + nLi Lmaxj + Σnj=1 R Cj

R≤p

(1)

where Li is the maximum packet size for the session i, Lmaxj is the maximum packet size in node j, Cj th bandwidth of the link j, and n the number of nodes. In order to simplify this delay expression, we can use the Ctot and Dtot parameters for definining the network. Where Ctot is nLi Lmax and Dtot is Σnj=1 Cj j . Note that equation 1 can be used only when the bandwidth reservation R is smaller than the peak reservation p. When R > p another expression that does not depend on the flow parameters must be used. In summary, the delay equations are: D=

σ + Ctot Dtot R

R≤p

(2)

M + Ctot Dtot R≥p≥ρ (3) R With these equations, the control admission test becomes very simple. For a new connection i with a given end-to-end delay Di , it is necessary to calculate the bandwidth reservation that makes the equation 2 or 3 less than D, and the sum of the bandwidth for all channels at the node less than the total link bandwidth Cj D=

P10/2

2.2

Differentiated services and EF traffic

Differentiated services is based on traffic aggregates [11]. Each of the aggregates that crosses a router belongs to a per-hop-behaviour (PHB). Per-hop-behaviours indicate how to schedule agregate packets and the amount of resources that can be used. Two PHBs have been standarized Assured Forwarding (AF) [6] and Expedited Forwarding (EF) [10]. The first one basically provides a betterthan-best-effort service while the second one can offer service with stringent QoS guarantees. To classify packets into differents agregates a 6-bits IP-header field is used. This field is named DSCP [2]. Although inside a DiffServ domain all the EF packets are seen like a traffic aggregate, at the domain boundaries each data flow is conformed following an arrival curve. Similarly to IntServ, there exists a network calculus due to Le Boudec [3] that provides an equation to obtain the maximum delay when each microflow of the aggreate leaky-bucket regulated at the input. In this formula, the end-to-end delay bound is a function of the traffic aggregate characteristics and the maximum number of hops that the connections cross. This delay bound can be calculated by means of this equation: D1 =

e+τ 1 − (h − 1)ν

(4)

where e is the node latency and h is a bound on the number of hops used by any flow. The terms ν and τ are traffic aggregate parameters and correspond to the utilization factor and the scaled burstiness. If each microflow is conformed according to the token bucket parameters (σ, ρ), and there are m microflows that cross the node, ν and τ can be written as: ν=

1 X ρi rm im

(5)

τ=

1 X σi rm im

(6)

and,

Figure 1: The bound D (in seconds) versus the utilization factor (ν) Figure 1 shows how varies the the bound D (vs. the utilization factor) in equation 4 with the number of hops (H ). The parameters of the simulation are: • e = 2 1500B rm , • Lmax = 1000b, • σi = 100B for all flows, • ρi = 32kb/s for all flows,

P10/3

• rm = 149, 760M b/s, and • Cm = +∞ As it can be seen, for 10 hops the bound is valid only for small utilization factors due to the 1 equation 4 explodes at ν < h−1 . However, it does not mean that the worst case delay does grow to infinity [5]. In some cases the network may be unbounded; in some other cases (such as the unidirectional ring, there is always a finite bound for all ν < 1. In any case, in the general case, it can be assumed that the network is unbounded. Although DiffServ does not use admission control tests, it is possible to guarantee a maximum given delay bound for an aggregate by restricting the admitted workload to meet equation 4. For a new connection i with an end-to-end delay Dmaxi it is necessary to calculate D1 (adding the terms (σi , ρi ) to τ and ν respectively) and in order to guarantee all the flows, verify that: min(Dmaxi ) ≥ hD1

3

(7)

Simulation environment

This section describes the workload used to evaluate the bounds given by network calculus and the simulations tools used to obtain real results about delay and utilization bounds.

3.1

Simulation tools description

The experiments described in the next sections use two different simulation tools: RTNOU (RealTime Optimization Utilities) and DUSTIN (DistribUted Simulation Tool for IP Networks). The evaluation of the theoretical utilization bounds of IntServ and DiffServ provided by network calculus were evaluated using the RTNOU simulation tool. RTNOU 1 is a C++ program that implements admission control tests of different service disciplines in an IntServ environment. Basically, RTNOU is able to compute a set of guaranteed flows among a wokload generated using real traces of multimedia files. The evaluation of the real utilizations bounds of DiffServ-EF were evaluated using the DUSTIN simulation tool. DUSTIN is basically an event driven simulation tool. It has been implemented in Java following the Object-Oriented paradigm. It has been design using the DiffServ conceptual model of Bernett [1], which offers an abstract view of all the DiffServ’s elements, i.e., classifiers, meters, schedules and so on. The low level structure of the simulation tool is based on some root classes, and provides an easy way to build up from a simple meter to a whole DiffServ domain. The main contribution of the DUSTIN simulator is to allow the construction of complex DiffServ routers by combining and interconnecting the set of datapath elements defined by Bernett in a DAG (Direct Acyclic Graph). The router structure can be easily specified in configuration file. DUSTIN also provides means for distributed simulation. Figure 2 shows an ingress node configuration. As it can be seen, in an ingress node, there are basically inputs, which are responsible of the traffic conditioning (by means of clasifiers, meters and actions) and outputs, which are responsible of scheduling packets belowing to different aggregates, and DUSTIN allows to model them at any abstraction level and it is also able to take differents measurements. The main parameters that can be measured are: • Timing measures. • Packet loss. 1 This program and the C source code of some of the experiments and admision control tests of the services disciplines are avaiable from http://www.disca.upv.es/ehheror/RTNOU.html

P10/4

Figure 2: Ingress node configuration • Bandwidth utilization. • Queues depth. • etc. For more details about the DUSTIN simulation tool see [15]

3.2

Workload description

The main goal of these experiments is evaluating the bandwidth utilization level provided by IntServ and DiffServ using both, network calculus formulas and simulation measurements. The bandwidth utilization is defined as the sum of the mean bandwidth of the accepted flows in a node divided by the link bandwidth. This level gives a clear evidence of eficiency of the service discipline to be evaluated The new experiment developed to obtain this level is an improvement of a experiment proposed in [7] to calculate the link-blocking ratio level, defined as the probability that a new traffic may not be admitted because there are not enough network resources to transmit this traffic. The proposed simulations focus on one switch of the network and it is assumed that the chosen switch is the bottlenek for all the flows passing through it. This switch determines, therefore, whether an incoming flow can be accepted into the network or not. It is also assumed that this switch operates at 155Mbps (corresponding to an OC-3 ATM link) and multiplexes a traffic mix consisting of six ttypes of video flows (the following MPEG1 Rose traffic: Advertisement, Jurassic, MTV, Lambs, Soccer and Terminator). Film Jurassic Park MTV Soccer Terminator Lambs Advertisement

Rate (bits/s) 326.953 615.105 678.213 272.618 182.788 547.246

Peak rate (bits/s) 2.990.800 5.730.000 4.679.400 1.989.000 3.355.600 4.771.400

Table 1: MPEG1 Rose traffic traces

This traffic traces (table 1) are a part of the well-know MPEG1 traces studied by O.Rose from the University of Wurzburg [14]. These sequences have been encoded with the Berkeley MPEGencoder (version 1.3) with a capture rate of 25fps.

P10/5

Flow arrivals are generated according to a Poisson process with a parameter α and their duration are exponentially distributed with mean 1/β. The ratio α/β characterizes the load offered to the link (the average number of flows that would exist at any time at a link with no capacity limitation). Each flow has traffic characteristics, which are chosen ramdomly from the characteristics of the six types of traffic. A million flows were generated in each simulation run.

4

Comparing the efficiency of IntServ vs. DiffServ admission control tests

The goal of this section section is to compare the utilization bounds of the IntServ and DiffServ approaches. The first subsection is devoted to compare the theoretical bounds provided by network calculus, while the second subsection is devoted to check how good are the bounds provided by the formulas of network calculus. This is done through simulation using the DUSTIN simulator.

4.1

Comparing theorical bounds

The theoretical bounds given by network calculus were evaluated by implementing the packetised versions of the admission control tests of IntServ (GPS) and DiffServ (EF): 1. IntServ test: GPS optimal bandwidth reservation based on equation 1 and using method developed in [8]. This is performed by the RTNOU simulator. [9]. 2. DiffServ test: Although DiffServ does not use primarily admission control tests, it is possible to guarantee a maximum given delay bound for an aggragate by restricting the admitted workload to meet equation 4. This is performed by the RTNOU simulator using the equation 7. The goal of this experiment is to compute the bandwidth utilization level in a single node (considered to be the botteleneck) provided by the above admission control tests when the QoS requirement is given by an end-to-end delay requirement of the flow of d (excluding propagation delays) that was uniformly distributed in [50ms, 1s]. The bandwidth utilization level is obtained by dynamically calculating the mean bandwidth level (the sum of the mean bandwidth of the chanels accepted) of the flows accepted by the above formula. When a channel is accepted or leaves the node, the temporal mean bandwidth level is updated, so this value gives a dynamic vision of the bandwidth utilization. Therefore, the bandwidth utilization level is obtained as the average of the mean bandwidth level divided by the link bandwidth.

Figure 3: Number of accepted flows Figure 3 shows the number of accepted flows for IntServ and DiffServ-EF when the workload is varied from 0 to 500 flows. Figure 4.1 shows the mean bandwidth utilization level. Since the P10/6

equation for DiffServ-EF varies with the number of hops, the results are shown for a 2, 5 and 10 hops. The results of this simulation reveal in first place that the mean bandwidth utilization level to guarantee a maximum dterministic delay is very low. Up to a 40% for IntServ, and surprsingly even less for DiffServ-EF.

Figure 4: Utilization Factor The main reason of this result is the named aggregate effect. This effect is caused when we try to guarantee maximum delay to individual flows inside the aggregate. Note in equation 4 that the delay bound D is a bound for all the flows inside it, and so, if we have to guarantee individual flows, in the admision control test (equation 7) we have to impose the aggregate’s maximum delay is less than the minimum of the Dmax for all the flows, so as to guatentee all of them. It is not clear whether the utilization bound for EF provided by the network calculus is not very accurate or whether DiffServ provides a good average case delay but a very bad worst case delay. That makes interesting to know the delay distribution. The differeces between 2, 5 and 10 hops is due to the dependency between the number of hops and the utilization factor, as we had explain en section 2.2. The equation 4 tries to capture that the more nodes a flow can cross, the more unforseeable the traffic is, and so the more burstiness it causes. Another conclusion from this experiment is that, for both approaches, IntServ and DiffServ, there is a critical load that causes the tests to start rejecting channels (in this sample, approximately 100). When load is higher than 200, the utilization increases very slowly and the number of rejected workloads is very high.

4.2

Comparing real traffic

The previous section showed that the theoretical utilization bounds for achieving a deterministic delay are very low. In addition, the bound for DiffServ is even lower than for IntServ. This lead us to check via simulation thge accuracy of the theoretical bounds and the reason for these results using the DUSTIN simulator described in section 3.1. Unlike in the previous experiment, the basic idea of this simulation is to establish new connections without any admission control test. The traffic is labeled as EF (expedited forwarding) [10] so as to have low delay, low jitter and low loss rate. The ingress node will schedule this traffic at the highest priority and the only limit to the traffic aggregate is that the node will start dropping packets when the arrival rate is higher than the link capacity. This experiment uses the same workload generated by the RTNOU simulator in the first experiment as an input file to the DUSTIN simulation tool, before it pass through the admision control test. This makes that the offered workload is not guarantee . With these workload we are able to reproduce the same scenario of the first experiment and making the results comparable.

P10/7

Figure 5: Load file description

Figure 6: DRST configuration The workload information is taken from a text file by the RTNOU simulation tool. As it can be seen in figure 4.2, this file contains information about the video, its QoS parameters (maximum delay), its traffic characteristics (the token bucket parameters (σ, ρ, peak)), and timing information (start time and the duration).

(a) BW utilization vs. n? connections

(b) Loss rate results .

Figure 7: Results of QoS parameters Figure 4.2 shows the simulation tool configuration. The topology used in this experiment is very simple. Ten video servers connected to an ingress node, that is considered to be the botteleneck. Each server provides a different number of simultaneous connections (or flows) depending on the simulaton parameters. The number of simultaneous connections varies in the interval [100..500] in steps of 50 connections. There is a load distributor which is reponsible of distributing the workload among the different video servers. Each video server has so many video players as different individual flows it has to send, so each video player represents an individual flow. This the way in which aggregate flows are generated. The number of video players is set as a simulation parameter. All the metrics, bandwidth utilization, P10/8

packet loss and maximum delays, are measured at the output of the ingress node. Figure 7.a shows the bandwidth utilization results of this experiment together with the results of the teorical bounds (see section 4.1). As it can be shown, real bandwidth utilization results are much more better than theorical results. It grows linearly with the number of the flows, and reaches up to a the 99% of bandwith utilization with 500 simultaneous flows. This result reveals that a EF service is able to guarantee the maximum delay bound with independence of the amount of traworst case analysisffic and, thus providing a full utilization of the channels. The penalty that has to be paid for that is packet losses: packets are dropped when the arrival rate is higher than the link capacity. However the interesting result is that a higher utilization can be achieved with a very low loss rate. Figure 7.b shows the packet loss rate. It can be seen that up to 300 (which represents the 80% of the link utilization) flows the loss rate is null. When the number of simultaneous flows increases so does the packet loss rate, but in any case the maximum rate is very low (0.082%).

(a)dmax /Dmax

(b)dmax distribution results

Figure 8: Maximum delay results Finally, and due to the drop action, and as it can be seen in figure 8.a, there are no missing deadlines since the queue depth does not grow enough to produce high delays at the ingress node. Although there are no missing deadlines, the maximum delay observed is the 78ms, which is inside the maximum delay range ([50ms, 1s]). So, in order to know how far is this worst maximum delay to the average delay, it is necessary to show the maximum delay distribution. Figure 8.b shows the maximum delay distribution with 500 simultaneous flows. As it can be seen the average case is around 30ms, which is less than a half the worst maximum delay. This result shows that it will be intersting to use statistical methods for the maximum delay analysis instead of worst case analysis, so as to provide better utilization results.

5

Conclusions and Future Work

This paper has shown the bounds to utilization limits provided by network calculus when deterministic end-to-end delays are required. These bounds have shown to be very low (up to a 40%) both in the IntServ and DiffServ approaches. Simulations have shown that these limits are very pessimistic and higher utilizations can be achieved by allowing some small amount of packet loss rates. The conclusions that can be extracted from these experiments are twofold: On one hand it can be said that the traditional network calculus analysis based on estimating bounds for the worst case provides innacurate and pessimistic utilization bounds that lead to infrautilization of resources. There are some ther areas where QoS is also a key issue, like real-time systems, where the

P10/9

traditional theory of the worst case analysis is being renewed introducing some statistical methods for the analysis [4]. On the other hand, it can be also concluded that multimedia applications should be designed in flexible way to tolerate some samll amount of packet losses, since this seems the best way to get a better resource utilization.

References [1] Y. Bernet, S. Blake, D. Grossman, and A. Smith. An informal management model dor dissserv routers, February 2001. draft. [2] D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss. Architecture for differenciated services, December 1998. [3] J. Y. Le Boudec and P. Thiran. Network Calculus. Springer Verlag LNCS 2050, June 2001. [4] J.L. Diaz, D.F. Garcia, K. Kim, C.G. Lee, L. Lo Bello, J.M. Lopez, S.L. Min, and O. Mirabella. Stochastic analysis of periodic real-time systems. In Proc. of the 23rd IEEE Real-Time Systems Symposium, pages 289–300, 2002. [5] F. Farkas and J.Y. Le Boudec. A delay bound for a network with aggregate scheduling. In Proceedings of Sixteenth UK Teletraffic Symposium on Management of Quality of Service, page 5, Harlow, UK, May 2000. [6] J. Heinanenand T. Finland, F. Baker, W. Weiss, and J. Wroclawski. Assured forwarding phb group, September 1999. RFC2597. [7] V. Firoiu, J. F. Kurose, and D. F. Towsley. Efficient admission control for EDF schedulers. In INFOCOM (1), pages 310–317, 1997. [8] E. Hern´andez and J. Vila. A fast method to opimise network resources for video-on-demand transmission. In IEEE Proceedings of Euromicro 2000, pages 440–447, Sep 2000. [9] E. Hern´andez and J. Vila. A new approach to optimise bandwidth reservation for real-time video transmissi´on with deterministic guarantees. Real-Time Imagin, 2001. [10] V. Jacobson, K. Nichols, and K. Poduri. An expedited forwarding phb, June 1999. RFC2598. [11] K. Nichols, S. Blake, F. Baker, and D. Black. Definition of the differenciated services field (ds field) in the ipv4 and ipv6 headers, December 1998. [12] A.K. Parek and R.G. Gallager. A generalized processor sharing approach to flow control in integrated services: a single node case. IEEE/ACM transactions on Networking, 2(2):344–357, June 1993. [13] A.K. Parek and R.G. Gallager. A generalized processor sharing approach to flow control in integrated services: the multiple node case. IEEE/ACM Transaction on Networking, 1(3):137– 150, April 1994. [14] O. Rose. Statistical properties of MPEG video traffic and their impact on traffic modeling in ATM systems. volume 20, pages 397–406, 1995. [15] S. Terrasa, S. S´aez, J. Vila, and E. Hern´andez. Drst: A new network simulation tool for a differentiated services. In Proceedings of International Simposium on Performance Evaluation of Computer and Telecomunication Systems, page 5, San Diego, CA, US, July 2002.

P10/10