∗

Comparing the utilization bounds of IntServ and DiffServ

S. Terrasa S. Sáez J. Vila
E. Hernández
Universidad Politécnica 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 archi-
tecture 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 un-
derlying 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 max-
imum 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, sec-
tion 3 describes the simultaion tools and workload description, section 4 describes the experiments
and main results and, finally, section 5 concludes the paper.

2 Network calculus results

2.1 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:

σ + nLi Lmaxj
Di = + Σnj=1 R≤p (1)
R Cj
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:

σ + Ctot
D= Dtot R≤p (2)
R
M + Ctot
D= 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

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 better-
than-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:
e+τ
D1 = (4)
1 − (h − 1)ν
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 (5)
rm im
and,
1 X
τ= σi (6)
rm im

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 (7)

3 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 (Real-
Time Optimization Utilities) and DUSTIN (DistribUted Simulation Tool for IP Networks).
The evaluation of the theoretical utilization bounds of IntServ and DiffServ provided by net-
work 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 Rate (bits/s) Peak rate (bits/s)

Jurassic Park 326.953 2.990.800
MTV 615.105 5.730.000
Soccer 678.213 4.679.400
Terminator 272.618 1.989.000
Lambs 182.788 3.355.600
Advertisement 547.246 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 MPEG-
encoder (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 con-

trol 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 connec-
tions 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 exper-
iment 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 deter-
ministic 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ández 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ández and J. Vila. A new approach to optimise bandwidth reservation for real-time
video transmissión 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áez, J. Vila, and E. Hernández. 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