Traffic shaping in aggregate-based networks: implementation and analysis

Computer Communications 28 (2005) 274–286 www.elsevier.com/locate/comcom

Traffic shaping in aggregate-based networks: implementation and analysis Markus Fidlera,*,1, Volker Sanderb,2, Wojciech Klimalab,2 a Department of Computer Science, RWTH Aachen University, 52064 Aachen, Germany Central Institute for Applied Mathematics, Research Centre Ju¨lich, 52425 Ju¨lich, Germany

b

Received 14 October 2004; accepted 14 October 2004 Available online 18 November 2004

Abstract The Differentiated Services architecture allows providing scalable Quality of Service by means of aggregating flows to a small number of traffic classes. Among these classes a Premium Service is defined, for which end-to-end delay guarantees are of particular interest. However, in aggregate scheduling networks such delay bounds suffer significantly from effects that are due to multiplexing of flows to aggregates. A way to minimize the impacts of interfering flows is to shape incoming traffic, so that bursts are smoothed. Doing so reduces the queuing delay within the core of a domain, whereas an additional shaping delay at the edge is introduced. This paper addresses the issue of traffic shaping analytically by extending known Network Calculus. An equation that allows computing tight per-flow output bounds in aggregate scheduling networks is derived and a solution for shaped interfering flows is provided. We then give an overview on the shaping capabilities of current legacy routers, showing deviations of actual implementations compared to the idealized view. Finally, the evolved analytical framework is applied to an example scenario and the results are compared to corresponding measurements. q 2004 Elsevier B.V. All rights reserved. Keywords: Aggregate scheduling; Differentiated services; Traffic shaping; Network calculus; Legacy routers

1. Introduction Differentiated Services (DS) [2] addresses the scalability problems of the former Integrated Services approach applying an aggregation of flows to a small number of traffic classes. Packets are identified by simple markings that indicate the respective class. In the core of the network, routers do not need to determine to which flow a packet belongs, only which aggregate behavior has to be applied. Edge routers mark packets and indicate whether they are

* Corresponding author. E-mail addresses: [email protected] (M. Fidler), [email protected] (V. Sander), [email protected] (W. Klimala). 1 This work was supported in part by the German Research Community (DFG) under grant graduate school (GRK) 643 Software for Communication Systems. 2 This work was supported in part by the Path Allocation in Backbone networks (PAB) project funded by the German Research Network (DFN) and the Federal Ministry of Education and Research (BMBF). 0140-3664/$ - see front matter q 2004 Elsevier B.V. All rights reserved. doi:10.1016/j.comcom.2004.10.005

within profile or, if they are out of profile, in which case they might even be discarded at the edge router. A particular marking on a packet indicates a so-called Per Hop Behavior (PHB) that has to be applied for forwarding of the packet. The Expedited Forwarding (EF) PHB [8] is intended for building a service that offers low loss and low delay, namely a Premium Service. It seems inevitable that tomorrow’s high-speed networks will be optically switched to a significant extent. One particular challenge that arises in this emerging scenario will be the co-existence of IP and optical services. Providing the existence of advanced management tools for optical domains, the question arises how to efficiently use the underlying transport capabilities in the non-optical domain, particularly given the fact that applications, today’s protocols, and IP-based services introduce bursts. An instrument that allows reducing the impacts of such bursts on network performance is to shape incoming traffic at the edge of a domain [17]. Queuing of the initial bursts is in this case performed at the edge, with the aim to minimize the delay

M. Fidler et al. / Computer Communications 28 (2005) 274–286

within the core. Especially, if heterogeneous aggregates have to be scheduled, shaping significantly reduces the impacts of different types of flows on each other [21]. In this paper we investigate and quantify the impacts of traffic shaping on queuing effects that are caused by traffic aggregation. The belonging theory on deterministic multiplexing has gained much attention recently [11,15,16] and in particular the issues of traffic shaping have been addressed in [18]. This paper extends our previous work presented in [10]. It differs from the approach that is investigated in [18] in that we only assume traffic shaping at the ingress routers of a domain instead of at the input ports of each router. The particular advantage of this solution is that it does not rely on any specific shaping support in the end-systems. While some operating systems have an optional support for traffic shaping, the QoS kernel extension of AIX [24] is an example for this, there is no general availability nor does a standardized programming interface exist for controlling this feature. Similarly, advances in application level protocols such as using TCP-Friendly Rate Control (TFRC)3 [13] on top of the Real-Time Transport Protocol (RTP) [23] do only apply for applications that make already use of these emerging protocols. The remainder of this paper is organized as follows: In Section 2 the required background on Network Calculus is given and extensions for traffic shaping are derived. Section 3 deals with the shaping capabilities of legacy routers. A comparative example is provided in Section 4. Section 5 concludes the paper. Proofs are given in the Appendix. Further related work is presented in [9,10], where the issue of traffic shaping is addressed in the context of admission control.

2. Network calculus Network Calculus is a theory of deterministic queuing systems that is based on the calculus for network delay presented in [5,6] and on Generalized Processor Sharing in [19,20]. Extensions and a comprehensive overview on current Network Calculus are given in [3,15]. Here, only some basic concepts are introduced briefly. Details are given for Network Calculus extensions that cover traffic shaping. In the sequel upper indices j indicate links respective the queuing and scheduling unit on an outgoing link and lower indices i indicate flows respective traffic trunks or traffic aggregates.

3 TFRC could also be implemented using a Congestion Manager [1] that relieves transport protocols and applications from having to (re-)implement congestion control. However, this concept would require a modification in the IP-stack.

275

2.1. Arrival constraints Flows can be described by arrival functions Fij ðtÞ that are given as the cumulated number of bits seen in an interval [0,t]. Arrival curves aji ðtÞ are defined to give an upper bound on the arrival functions, where aji ðt2 K t1 ÞR Fij ðt2 ÞK Fij ðt1 Þ for all t2Rt1R0. Theorem 1 (Minimum Arrival Curve) The minimum arrival curve that corresponds to a given arrival function Fij ðtÞ can be derived by self-de-convolution of Fij ðtÞ according to (1), where 5 denotes min-plus de-convolution [15]. aji ðtÞ Z Fij ðtÞ5Fij ðtÞ Z sup½Fij ðt C sÞ K Fij ðsÞ

(1)

sR0

A typical constraint for incoming flows is given by the leaky bucket algorithm, which allows for bursts of a certain size and a defined sustainable rate. Non-conforming traffic can either be shaped or dropped. Definition 1 (Single Leaky Bucket Constraint)The arrival curve that is enforced by a single leaky bucket with depth bji and token rate ri is the affine function that is given by (2) for tO0. It is zero for tZ0. aji ðtÞ Z bji C ri $t

(2)

The indexing refers to a flow i at a link or queuing and scheduling unit j. Note that the burst term bji in most cases depends on the point of observation, that is the link j, whereas the rate ri usually does not change throughout the network. Leaky buckets can be concatenated as shown in Fig. 1 to enforce and describe more complex arrival constraints. Definition 2 (Dual Leaky Bucket Constraint)Consider a dual leaky bucket configuration according to Fig. 1. Define j ðri ; b
i Þ, and ð
r i ; bji Þ to be the parameters of the first, respective j second leaky bucket, with r
i O ri and b
i O bji . The resulting arrival curve is defined by (3) for tO0. It is zero for tZ0. It allows for bursts of size bji , then it ascends by r
i until j t
ji Z ðb
i K bji Þ=ð
r i K ri Þ, and finally it increases with rate ri as

Fig. 1. Dual leaky bucket configuration.

276

M. Fidler et al. / Computer Communications 28 (2005) 274–286

and 2 according to (2) is again single leaky bucket constrained and given by (4). aj1 ðtÞ C aj2 ðtÞ Z bj1 C bj2 C ðr1 C r2 Þ$t

(4)

The result immediately extends to scenarios with n flows. In case of dual leaky bucket constraints the scenario is significantly more complicated. Corollary 2 (Multiplexing, Dual Leaky Bucket Case) Consider a traffic aggregate of two dual leaky bucket constrained flows 1 and 2 with parameters t
j1 and t
j2 according to (3). Assume a numbering of flows such that t
j1 % t
j2 . The corresponding aggregate arrival curve is given in (5). Fig. 2. Dual leaky bucket constraint.

aj1 ðtÞ C aj2 ðtÞ

shown in Fig. 2. aji ðtÞ

Z min½bji 8 < Z

:

j C r
i $t; b
i

C ri $t

bji C r
i $t;

if t% t
ji Z

j b
i C ri $t;

else

j b
i

K bji

r
i K ri

(3)

An arrival curve of the type in (3) applies, if a single leaky bucket constrained flow with the arrival curve aji ðtÞZ j b
i C ri $t traverses a combination of an ideal bit-by-bit traffic shaper with rate r
i and a packetizer with a maximum packet size lmax [3,14]. The concept of a packetizer was introduced with the intention to model the effect of variable length packets. In reality, flows are not continuous in time, due to a minimum granularity that needs to be taken into account. Packetizers are used to convert a continuous input into a packetized sequence with a given maximum packet size. As a consequence a burst size of bji Z lmax remains and the output arrival curve is dual leaky bucket constrained with j parameters ðri ; b
i Þ and ð
r i ; lmax Þ. Note that actual implementations differ from the combination of an ideal shaper and a packetizer. As a result bji R lmax applies. The shaper adds a j worst-case delay of ðb
i K bji Þ=
r i .

2.2. Multiplexing Aggregate scheduling networks, such as DS domains, are characterized by multiplexing of flows to traffic trunks, respective traffic aggregates. Fortunately, the traffic specification applied by Network Calculus allows for a very simple description of traffic aggregation: The aggregate arrival function, respective arrival curve of a number of flows or traffic trunks that are multiplexed is the sum of the individual arrival functions respective arrival curves. Corollary 1 (Multiplexing, Single Leaky Bucket Case) The aggregate of two single leaky bucket constrained flows 1

8 j b C bj2 C ð
r 1 C r
2 Þ$t; > > < 1 Z b
j1 C bj2 C ðr1 C r
2 Þ$t; > > : j j b
1 C b
2 C ðr1 C r2 Þ$t;

if t% t
j1 o t% t
j2 if tO t
j1 o t% t
j2

(5)

else

The result extends to traffic aggregate that consist of n dual leaky bucket constrained flows iZ1.n with parameters t
ji and in order numbering of flows such that t
ji % t
jiC1 , ciZ 1.nK1. Note that the ordering allows describing the aggregate arrival constraint by nC1 instead of 2n leaky buckets. The resulting aggregate arrival curve is an increasing, concave, and piece-wise linear function. 2.3. Aggregate scheduling The service that is offered by the scheduler on an outgoing link j can be characterized by a minimum service curve, denoted by bj(t). A network element with input arrival function Fij ðtÞ and output arrival function FijC1 ðtÞ is said to offer the service curve bj(t) if a time instance s exists for all t with tRsR0 for which FijC1 ðtÞK Fij ðsÞR bj ðtK sÞ holds. Definition 3 (Rate-Latency Service Curve)A special type of service curve is the rate-latency service curve that is given by (6), with a rate Rj and a latency Tj. The term [x]C is equal to x, if xR0, and zero otherwise. bj ðtÞ Z Rj $½t K T j C

(6)

Service curves of the rate-latency type are implemented for example by Priority Queuing (PQ) or Generalized Processor Sharing (GPS) respective Weighted Fair Queuing (WFQ), where certain transport resources that correspond to the rate Rj can be assigned to selected traffic. The latency Tj applies for non-preemptive scheduling, where in case of PQ low priority packets that are already in service have to complete service before high priority packets that arrive in

M. Fidler et al. / Computer Communications 28 (2005) 274–286

the meantime can be scheduled. Thus, Tj can be given as the quotient of the maximum packet size and the link rate. The same latency applies for Packet by packet GPS (PGPS) for which related models can be found in [19,15]. However, in aggregate scheduling networks resources are provisioned on a per-aggregate basis. As an immediate consequence, flows that belong to the same aggregate compete for resources. The problem has been addressed in [7,15] and the following equation for per-flow service curves for FIFO aggregate scheduling nodes has been derived. Theorem 2 (Aggregate Scheduling) Consider a flow 1 that is scheduled in FIFO order and in an aggregate manner with a flow, or a sub-aggregate 2 that is upper constrained by aj2 ðtÞ on a link j. Assume that the service curve that is seen by the aggregate is given by bj ðtÞ. Eq. (7) defines a family of service curves bjq ðtÞ with an arbitrary parameter qR0 that are offered to flow 1 only. The term 1tOq is one for tOq and zero for t%q. bjq ðtÞ Z ½bj ðtÞ K aj2 ðt K qÞC$1tOq

(7)

The application of (7) usually requires a thorough choice of one particular service curve by fixing the parameter q.

ajC1 1 ðtÞ

Based on the above concepts, bounds on the backlog and the delay can be derived to be the maximal vertical respective horizontal deviation between the arrival curve and the service curve. Further on, of particular interest for aggregate scheduling networks are constraints that can be derived for the output of a traffic trunk from a queuing and scheduling unit. Theorem 3 (Output Bound) If a traffic trunk i that is constrained by aji is input to a link j that offers a service curve bj, a tight output arrival curve ajC1 for flow i can be i derived by min-plus de-convolution of the arrival curve and service curve according to (8). ajC1 i ðtÞ

Z aji ðtÞ5bj ðtÞ

Z sup½aji ðt C sÞ K bj ðsÞ sR0

(8)

The following approach can be applied to derive tight per-flow output constraints in case of aggregate scheduling. Corollary 3 (Output Bound, Aggregate Scheduling) Substitution of (7) in (8) gives a family of flow 1 output constraints with parameter q. Any of these output constraints holds individually, thus the infqR0[.] is an output constraint, too [15]. The corresponding equation for the flow 1 output constraint ajC1 1 is given by (9).

  j j j C Z inf sup½a1 ðt C sÞ K ½b ðsÞ K a2 ðs K qÞ 1sOq  qR0

sR0

(9) A solution of (9) for rate-latency service curves and single leaky bucket constrained flows 1 and 2 is provided in [15]. However, a general solution for arbitrary arrival curves has to our knowledge been missing so far. The relevant extensions of current theory considering ratelatency service curves and general arrival curves respective dual leaky bucket constraints are derived in the following. Theorem 4 (Output Bound, Rate-Latency Case) Consider two flows 1, and 2 that are aj1 , respective aj2 upper constrained. Assume these flows are served in FIFO order and in an aggregate manner by a node j that is characterized by a minimum service curve of the ratelatency type bj ðtÞZ Rj $½tK T j C. Then, the output of flow 1 is ajC1 upper constrained according to (10), where q is a 1 function of t and has to comply with (11). The proof can be found in the Appendix. A related equation for simple rate service curves is derived in [4]. j ajC1 1 ðtÞZa1 ðtCqðtÞÞ

qðtÞ Z 2.4. Output constraints

277

(10)

supvO0 ½aj1 ðvCt CqðtÞÞKaj1 ðt CqðtÞÞCaj2 ðvÞKRj $v Rj j CT ð11Þ

Corollary 4 (Output Bound, Single Leaky Bucket Case) In case of a single leaky bucket constrained flow or traffic trunk 1, with rate r1 and burst size bj1 , (11) can be simplified applying aj1 ðvC tC qðtÞÞK aj1 ðtC qðtÞÞZ r1 $v. As an immediate consequence, q becomes independent of t. With (10) we find that the output flow 1 is leaky bucket constrained with r1 and bjC1 according to (12). The same 1 result is also reported in [15]. b1jC1 Z aj1 ðqð0ÞÞ

(12)

Eq. (11) becomes (13) qð0Þ Z

supvO0 ½r1 $v C aj2 ðvÞ K Rj $v CTj Rj

(13)

If the flow or sub-aggregate 2 is leaky bucket constrained with rate r2 and burst size bj2 and if r1Cr2%Rj, the sup[.] in (13) is found for v/0 resulting in qZ bj2 =Rj C T j and bjC1 1 can be given by (14). b1jC1 Z bj1 C r1 $ðT j C bj2 =Rj Þ

(14)

Theorem 5 (Output Bound, Dual Leaky Bucket Case) Consider two flows or traffic trunks 1 and 2 that are aj1 , respective aj2 upper constrained, where aj2 is concave. Assume that these flows are served in FIFO order and in an

278

M. Fidler et al. / Computer Communications 28 (2005) 274–286

aggregate manner by a node j that is characterized by a minimum service curve of the rate-latency type. If the input j flow 1 is constrained by two leaky buckets with ðr1 ; b
1 Þ, j ð
r 1 ; bj1 Þ, and t
j1 Z ðb
1 K bj1 Þ=ð
r 1 K r1 Þ, the output flow is dual jC1 leaky bucket constrained with ðr1 ; b
1 Þ, and ð
r 1 ; bjC1 1 Þ, jC1 where bjC1 and b
1 are given by (15) respective (16). The 1 proof can be found in the Appendix. b1jC1 Z aj1 ðqð0ÞÞ

(15)

jC1 j b
1 Z b
1 C r1 $qðt
j1 Þ

(16)

The parameter q(t) according to (11) is given in (17) for tZ0 and in (18) for tZ t
j1 . qð0Þ Z

supvO0 ½aj1 ðvCqð0ÞÞ Kaj1 ðqð0ÞÞ Caj2 ðvÞKRj $v CT j Rj (17)

qðt
j1 Þ Z

supvO0 ½r1 $v C aj2 ðvÞ K Rj $v C Tj Rj

(18)

the supv[.] in the first form respective the second and third form of (19) and also in (18) are attained.

3. Legacy hardware The concept of leaky bucket shapers provides the framework for traffic shaping. A leaky bucket shaper consists of a bucket, which stores tokens, and a holding queue, where incoming packets can be buffered. Whenever a packet is forwarded from the holding queue to the outgoing interface, a number of tokens that correspond to the packet size, are placed into the bucket. Packets are forwarded as long as the bucket offers sufficient space for tokens without causing an overflow, until packets have eventually to be queued. The bucket has a depth of b and it leaks at a constant rate r. Thus, outgoing traffic cannot exceed a burst size of b and a sustainable rate of r. The idealized fluid-flow model of a perfect shaper can be implemented by setting the burst size b to zero. However, in packet networks a minimum granularity will

A pragmatic procedure to solve (17) is described below: Eq. (17) can have either of the three forms shown in (19), depending on the value of q itself. 8 > supvO0 ½
r 1 $v C aj2 ðvÞ K Rj $v C Rj $T j > > ; if qð0Þ% t
j1 K n > j > R > > < j j j j j
j qð0Þ Z supvO0 ½r1 $v C a2 ðvÞ K R $v C R $T C b1 K b1 ; else if qð0Þ% t
j 1 > Rj C r
1 K r1 > > > j j j j > > supvO0 ½r1 $v C a2 ðvÞ K R $v C R $T > : ; else Rj However, aj1 ðnC qð0ÞÞK aj1 ðqð0ÞÞ remains constant or decreases if q increases, therefore (19) has only one unique solution. Thus, all three forms of (19) can be evaluated, whereby the solution is found for the form of (19) for which q(0) falls into the indicated interval. Now consider a sub-aggregate with arrival constraint aj2 that consists of n dual leaky bucket constrained flows with arrival curves aj2;i , 1%i%n. The arrival curve aj2 consists of nC1 pieces, is piece-wise linear, increasing, and concave. Then, define v
and v according to (20) and (21). ( ) n n X X j r2;i $1tOt
j R R $1tO0 n
Z sup t : r
1 C r
2;i $1t%t
j C iZ1

2;i

iZ1

2;i

(20) ( n Z sup t : r1 C

n X iZ1

r
2;i $1t%t
j C 2;i

n X iZ1

) j

r2;i $1tOt
j R R $1tO0 2;i

(21) The supv[.] in (19) is found for the largest time instance v for which the first derivative of [.] is still positive. The corresponding time instances are, however, derived in (20) respective in (21). Thus, n
and n are the values of v for which

(19)

have to remain. In case of packets of a maximum size of lmax a bucket depth of at least bZlmax is required to allow for sound operation. However, many deployed routers do not provide the described functionality. Instead, performance optimized implementations of traffic shapers are used. The experiments we present in this paper were performed using Cisco 72xx routers, which do not support buckets that constantly leak at a given rate. Instead, the underlying traffic shaping does allow for some bursts. On this platform, traffic shaping is configured in terms of intervals, mean rates, and bursts [25]. Instead of a continuous decrease of tokens, the bucket is emptied at once at the end of defined, fixed sized intervals. The standard configuration for this is 25 ms. The bucket depth is then given by the mean rate, divided by the interval length. Hence, on an interval basis, the transmitted data cannot exceed the bucket depth. However, within the intervals the transmission can actually be performed at link speed. In order to check how this implementation of traffic shaping influences the behavior of a TCP flow, we monitored the network traffic of a TCP session at the sender with tcpdump and analyzed the trace file with the tcptrace

M. Fidler et al. / Computer Communications 28 (2005) 274–286

279

Fig. 3. Influence of shaping on a bursty TCP flow. The number of acknowledged bytes is plotted against time for the situation when the shaping is disabled (a) and enabled (b). The shaping mechanism significantly reduces traffic bursts.

program. Fig. 3 illustrates the results with 10 ms resolution. The dashed lines show the sequence number of the data that are transmitted. The solid lines indicate the received acknowledgments as a function of time. Since the transmission of acknowledgements is indirectly influenced by the shaper, it is an appropriate mechanism to show how the injected traffic load is affected by shaping. The experiment used a modified version of the ttcp program that allows to control the socket buffer write frequency. Here, TCP packets were sent at an average rate of 10 Mb/s. The socket buffer size was 256 kByte, to reflect long-distance transmissions across several domains. The virtual application uses data buffers of 256 kByte that are written periodically to the TCP socket. Thus, a bursty traffic profile is created. Note that TCP applications can always produce bursts of up to a full window. The effects of bursty and synchronized TCP sources are well-known in the Internet. In the left of Fig. 3 the shaper was disabled. We recognize the behavior of TCP that injects data at link speed, when the available window is allowing this. Here, the sender generates bursts of about 256 kByte. This burst structure is reflected by the acknowledged packets. In the right of Fig. 3 corresponding results with shaping are shown. By enabling shaping with an average rate of 12 Mb/s the bursty TCP flow is smoothed according to the shaper configuration. In this case, the acknowledgements were received in much smaller bursts. In

fact, we recognize the shaping parameters used in this scenario. Since the time interval for emptying the token bucket was 25 ms, we allowed for bursts of up to 12 Mb/ s$25 msZ0.3 Mb within each interval. Yet, a double step can be recognized at each write operation of the application. Recall that data is written to the socket at a mean rate of 10 Mb/s, whereas the mean shaping rate is 12 Mb/s. Thus, the bucket of the shaper will be emptied some time before a write operation takes place. Hence, the first step of 0.3 Mb is caused by the regular bucket depth b that can be fully exploited. However, if the write operation takes place shortly before the end of a 25 ms interval of the shaper, the bucket will immediately be emptied allowing the injection of a second burst of 0.3 Mb into the network. Thus, the interval-based shaper implementation has the unfortunate property that in a worst-case bursts of twice the bucket depth can pass the shaper and enter the network virtually at once.

4. Application scenarios and example evaluation Scalability is one of the main reasons for the introduction of aggregate scheduling to the DS framework. Yet, aggregate scheduling implies multiplexing of flows to traffic aggregates, which has significant impacts on traffic

280

M. Fidler et al. / Computer Communications 28 (2005) 274–286

properties as well as on QoS guarantees. While statistical multiplexing benefits from a large number of multiplexed flows, deterministic multiplexing does not. Each additional flow that is multiplexed to an aggregate increases the potential burst size of each other flow. Thus, the traffic specification of a flow or traffic trunk that applies at the egress of a DS domain differs from the initial traffic specification at the ingress, causing additional difficulties in multidomain scenarios. A feasible solution [17] that is investigated here is to shape flows with a large burst size, to achieve robustness against interference and to support scalability based on controlled competition for resources, even in case of a large number of interfering flows. This section combines the analytical treatment from Section 2 and the results from Section 3 on shaping in legacy hardware to provide an example application. 4.1. Test-bed implementation The scenario that is investigated is shown in Fig. 4. The network we use is a DS test-bed implementation that is based on a number of Cisco series 72xx routers. The investigated flows pass several links and among them a bottleneck link that is an ATM PVC with a gross rate of 50 Mb/s and a net rate of about 40 Mb/s, after subtracting ATM overhead. The EF PHB is implemented applying Priority Queuing (PQ) respective Low Latency Queuing (LLQ) in Cisco terminology. Attached to the PQ schedulers are leaky buckets that restrict the high priority traffic to a rate of 15 Mb/s and a burst size of 1.5 MByte. Excess traffic is discarded to avoid starvation of the low priority BE traffic. Note that the priority schedulers are non-preemptive, not only with respect to the IP datagram that is in service, but also with respect to the L2 queue on the ATM interface [22].

The L2 queue is controlled by the tx-ring-limit parameter that is set to four, which corresponds to configured queuing space for four MTUs. Here we apply the Ethernet MTU of 1.5 kByte. Three types of flows are transmitted. A BE gen-send/genrecv UDP flow periodically creates congestion. Note that BE traffic ideally does not have any influence on the priority queue. However, due to the non-preemptive L2 queue an additional delay of up to 1.2 ms can be measured for high priority traffic on the bottleneck link. The EF PHB is used by an aggregate of a UDP video stream generated by rude/crude and the ttcp TCP flow that is shown in Fig. 3(a). The video stream is a news sequence from [12] with an I-frame distance of 12 frames and a rate of 25 frames per second. The TCP flow applies the window scale option and uses a maximum window of 256 kByte that is 2 Mb to support a target throughput of 10 Mb/s up to a Round Trip Time (RTT) of about 200 ms, which is reasonable for long distance transmissions and multidomain scenarios. 4.2. Scenario without consideration of shaping Fig. 5 shows the video profile of the news sequence as it is input to the test-bed domain. The periodic structure of the frame size clearly shows the fixed encoding of the stream that consists of large I-frames and smaller P- and B-frames. The spacing of the video frames is 40 ms. For processing of the data a bin size of 10 ms has been applied. Further on, Fig. 5 shows the profile of the video as it is output from the test-bed. Large parts of the input and the output sequence match for the applied bin size of 10 ms, whereas a number of noticeable differences remain, where a frame has been delayed by the network. Most visible are the peaks that are

Fig. 4. Test-bed implementation and evaluation scenario.

M. Fidler et al. / Computer Communications 28 (2005) 274–286

Fig. 5. Video profiles.

generated, if two frames fall into the same bin, indicating a significant output burstiness increase. Fig. 6 gives the cumulative functions of the video input respective output that are called arrival functions in Network Calculus terminology. Due to the resolution almost no differences can be noticed between input and output. Corresponding minimum arrival curves can be derived by self-de-convolution of the arrival functions according to (1). The derived arrival curves for the video input respective video output are shown in Fig. 7. As Fig. 6 before, Fig. 7 only provides an overview, since the resolution does not allow distinguishing between input and output arrival curve. A detailed view on the leftmost part of the arrival curves is given by Fig. 8, now with a bin size of 1 ms. Here a significant difference of the burstiness between input and output can be noticed. The corresponding single leaky bucket constraint for the input is approximated by (22) with a burst size of binZ0.1 Mb and a rate of rZ2 Mb/s.

Fig. 6. Video arrival functions.

281

Fig. 7. Video arrival curves.

ain ðtÞ Z 0:1 Mb C 2 Mb=s$t

(22)

The measurement of the output yields the single leaky bucket constraint in (23), with an increased burst size of boutZ0.17 Mb. Different parameter sets are possible. However, for a fixed rate only one choice of the output burst size results in a tight constraint. aout ðtÞ Z 0:17 Mb C 2 Mb=s$t

(23)

Analytically the scenario can be addressed as follows: All links except the bottleneck link are over-provisioned and have only marginal impact. For ease of presentation these links are neglected during the analysis. The bottleneck link offers a service curve of b(t) according to (24) to the aggregate of the video stream and the TCP flow. bðtÞ ¼ 40 Mb=s,½t K 1:2 msþ

(24)

The latency of TZ1.2 ms results from the non-preemptive L2 queue on the ATM bottleneck interface, as discussed above. The arrival curve of the interfering TCP stream can

Fig. 8. Video arrival curves.

282

M. Fidler et al. / Computer Communications 28 (2005) 274–286

be described partly by TCP parameters and partly by the target data rate of the application, respective by the policing parameters of the ingress router. Here we apply a window size of 256 kByte and a rate of 10 Mb/s corresponding to the arrival curve in (25). aTCP ðtÞ Z 2 Mb C 10 Mb=s$t

(25)

With (14) the burstiness of the video stream as it is output from the bottleneck link can be derived according to (26).

 bTCP bout Z bin C r T C R

 2 Mb Z 0:1 Mb C 2 Mb=s 1:2 ms C Z 0:2 Mb 40 Mb=s ð26Þ The analytical output burst size clearly exceeds the measured output burst size of 0.17 Mb. However, further improvement of the analytical results based on the equations for shaped traffic is feasible. 4.3. Scenario with consideration of shaping Note that additional information on the TCP flow is available, namely that it passes a Fast Ethernet link before being multiplexed with the video stream. Using the path MTU discovery option of TCP, we obtain a Maximum Segment Size (MSS) for the TCP connection that is equivalent to the MTU size of the Fast Ethernet link. Thereby the Ethernet link acts as a traffic shaper, however, with a comparably large shaping rate of about 100 Mb/s$1500/(1500C18)Z98.8 Mb/s, accounting for 18 Bytes of Ethernet encapsulation, and a remaining burst size of one Ethernet MTU that is 0.012 Mb. Thus, the arrival curve of the TCP stream can be refined to be the dual leaky bucket constraint in (27). aTCP ðtÞ Z min½0:012 Mb C98:8 Mb=s$t; 2 Mb C10 Mb=s$t (27) The corresponding time constant t
TCP of the dual leaky bucket constraint is given in (28). t
TCP Z

2 Mb K 0:012 Mb Z 22:4 ms 98:8 Mb=s K 10 Mb=s

(28)

To derive the output bound for the video stream Eqs. (12) and (13) are applied. The parameter q(0) is derived in (29) according to the definition in (13). supvO0 ½r$v C aTCP ðvÞ K R$v CT R supvO0 ½2 Mb=s$v C aTCP ðvÞ K 40 Mb=s$v Z C 1:2 ms 40 Mb=s ð29Þ

qð0Þ Z

The sup[.] is found for vZ t
TCP Z 22:4 ms and q(0)Z35.5 ms results. With (12) we find the output burst

size bout in (30). bout Z ain ðqð0ÞÞ Z 0:1 Mb C 2 Mb=s$35:5 ms Z 0:171 Mb (30) The resulting video output constraint is aout ðtÞZ 0:171 MbC 2 Mb$t, which is significantly tighter than the output burst size derived in (26) before and quite close to the measured output constraint in (23). With respect to multidomain scenarios the question about the traffic specification of the traffic as it is input to a downstream domain arises. The naive approach would be to apply the traffic specification of the source throughout all domains that are involved and to add traffic shapers at domain’s egress routers that ensure that the output conforms to the specification. Doing so adds an additional worst-case shaping delay of (0.071 Mb)/ (2 Mb/s)Z36 ms to reduce the output burst size from 0.171 to 0.1 Mb, applying a rate of 2 Mb/s. The re-shaping delay has to be added to the per-domain edge-to-edge delay bound of the video transmission that has been measured to be 56.4 ms. Clearly the concept of re-shaping the domain’s outbound traffic is not generally applicable. In particular with respect to deterministic performance bounds the process is not scalable, since each interfering flow penalizes the video stream from the above example in two ways: It introduces extra delays due to competition for resources within the domain, here about 52.7 ms, and it influences the traffic profile such that additional re-shaping delays apply at the egress router of the domain, here 36 ms. The preferred solution is to shape interfering flows at the ingress of the source domain. Here, the video stream initially only has a comparably small burst size, whereas the TCP stream is inherently bursty. Yet, we have shown in [22] that shaping TCP streams allows for a very smooth operation, where the goodput can be significantly larger than if congestion control with the saw-tooth characteristic applies. For the next experiment the TCP stream is shaped on the ingress router of the test-bed with an average shaping rate of 12 Mb/s, as shown in Fig. 3(b). Following the discussion on shaping in legacy hardware from Section 3, the burstiness is decreased from initially 2 Mb to 2$12 Mb/s$25 msZ 0.6 Mb, where a worst-case burst size of two times the configured bucket depth remains due to the intervalbased shaper implementation. Fig. 9 shows the arrival curves for the video input and output, if the interfering TCP stream is shaped. The corresponding single leaky bucket constraint for the input is ain(t)Z0.10 MbC2 Mb/s$t as before. The single leaky bucket constraint for the output follows from the measurement according to (31), with a burst size of bZ0.11 Mb. aout ðtÞ Z 0:11 Mb C 2 Mb=s$t

(31)

The analysis yields the following: The arrival curve of the interfering TCP stream is dual leaky bucket constrained

M. Fidler et al. / Computer Communications 28 (2005) 274–286

283

Clearly, the analytic bound became tighter, but still it is negatively affected by the large TCP burstiness that remains after shaping, where in the worst case bursts of two times the bucket depth can enter the network. The measured edge-to-edge delay bound for the video stream is 12.2 ms. An additional worst case re-shaping delay of 5 ms applies to reduce the measured output burstiness of the video stream from 0.11 Mb again to 0.1 Mb.

5. Conclusions

Fig. 9. Video arrival curves with TCP shaping.

and can be described by (32). aTCP ðtÞ Z min½0:6 Mb C 12 Mb=s$t; 2 Mb C 10 Mb=s$t (32) The flow of interest, that is the video stream, is as before constrained by a single leaky bucket, thus Eqs. (12) and (13) can be applied. The parameter q(0) as defined by (13) is given in (33). qð0Þ Z

supvO0 ½2 Mb=s$v C aTCP ðvÞ K 40 Mb=s$v C 1:2 ms 40 Mb=s (33)

Obviously the sup[.] is found for v/0 ms and q(0)Z16.2 ms results. With (12) we find the video output burst size bout according to (34). bout Z 0:1 Mb C 2 Mb=s$16:2 ms Z 0:132 Mb

(34)

If in addition the shaping effect of the Ethernet link is taken into account, the interfering TCP stream is constrained by three leaky buckets according to (35).

In this paper we have addressed the impacts of traffic shaping on aggregate scheduling networks. We applied the notation of dual leaky bucket constrained arrival curves to extend the analytical framework of Network Calculus to cover relevant traffic shaping issues. A general per-flow service curve has been derived for FIFO aggregate scheduling rate-latency service elements. This equation has been solved for the special case of dual leaky bucket constrained flows and dual leaky bucket output constraints have been derived. Note that we can model input and output of rate-latency service elements by the same type of arrival curve, only differing with respect to parameters, which is a very fortunate property, since it allows addressing multiplenode scenarios. In particular our analytical result can be applied to networks, where traffic shapers are in effect at ingress routers only, whereby the dual leaky bucket property of shaped traffic trunks can still be derived to hold within the core of the network. We provided an overview on the shaping capabilities of current router hardware and showed relevant deviations compared to the concept of the ideal shaper, which have also been comprised by our analytical modeling. Finally we discussed an application scenario that illustrates the application of traffic shaping and compares measurements with derived analytical bounds.

aTCP ðtÞ Z min½0:012 Mb C 98:8 Mb=s$t; 0:6 Mb C 12 Mb=s$t; 2 Mb C 10 Mb=s$t

(35)

The relevant time constant t
TCP is given in (36). t
TCP Z

0:6 Mb K 0:012 Mb Z 6:8 ms 98:8 Mb=s K 12 Mb=s

(36)

The parameter q(0) defined by (13) is derived in (37). qð0Þ Z

supvO0 ½2 Mb=s$v C aTCP ðvÞ K 40 Mb=s$v C 1:2 ms 40 Mb=s (37)

The sup[.]is found for vZ t
TCP Z 6:8 ms and q(0)Z11.8 ms results. The improved video output burst size bout according to (12) is derived in (38). bout Z 0:1 Mb C 2 Mb=s$11:8 ms Z 0:124 Mb

(38)

Appendix A Proof 1 (Proof of Theorem 4)With sup0%s%q ½aj1 ðtC sÞK ½bj ðsÞK aj2 ðsK qÞC$1sOq Zaj1 ðtC qÞ, (A1) follows from (9).   jC1 a1 ðtÞ Z inf sup aj1 ðt C qÞ; sup½aj1 ðt C sÞ qR0 sOq  (A1) j j C K ½b ðsÞ K a2 ðs K qÞ  Then, service curves of the rate-latency type bj ðtÞZ R $½tK T j C are assumed. The condition Rj $ðsK T j ÞK aj2 ðsK qÞR 0 can be found to hold for qRq 0 with q 0 Z supsO0 ½aj2 ðsÞK Rj $s=Rj C T j , whereby q 0 RT j. The derivation of this condition is based on (A2) and (A3) that j

284

M. Fidler et al. / Computer Communications 28 (2005) 274–286

are obtained from [15]. j

inf ½R $ðs K T sOq

j

A thought experiment, which shows that the derived bound is attained, can be found in [9]. It mimics a proof that is provided for the special case of a single leaky bucket constrained trunk 1 in [15].,

Þ K aj2 ðs K qÞ

Z inf ½Rj $v K aj2 ðvÞ K Rj $T j C Rj $q vO0

Z Rj $q K Rj $T j K sup½aj2 ðvÞ K Rj $v

(A2)

vO0

Rj $q K Rj $T j K sup½aj2 ðvÞ K Rj $vR 0 vO0 5 qR sup½aj2 ðvÞ K Rj $v=Rj vO0

CTj

ðA3Þ

Thus, (A4) can be derived for qRq 0 , from which (A5) follows immediately. qRq

KR $

ðs K T

j

sOq j Þ C a2 ðs K qÞ

C aj2 ðvÞ K Rj $v Case 1 (tZ0). For tZ0 (A12) can be immediately derived from (A11).

vO0

K Rj $ðv C q K T j Þ C aj2 ðvÞ

(A5)

*

For different values of q a q is defined in (A6) as a function of (tCq). With q * R q 0 (A7) can be given. q* ðt CqÞ Z

supvO0 ½aj1 ðt CvCqÞKaj1 ðt CqÞ Caj2 ðvÞKRj $v CT j Rj (A6)

sup½aj1 ðt CvCqÞKaj1 ðt CqÞCa2 ðvÞKRj $v vO0

KRj $ðq KT j Þ,0; if q,q*

(A7Þ

Then, with (A6) and (A7) the outer sup[.] in (A5) can be solved and (A8) is derived.  ðtÞ Zinf inf ½aj1 ðt CqÞ; 0 inf ½aj1 ðt CqÞ ajC1 1 qOq*

q %q%q*

Csup½aj1 ðt CvCqÞ Kaj1 ðt CqÞCaj2 ðvÞKRj $v vO0  KR $ðq KT Þ j

(A11)

ðA4Þ

j j ajC1 1 ðtÞ Z inf0 ½sup½a1 ðt C qÞ; sup½a1 ðt C v C qÞ qRq

ðqðtÞ K T j Þ$Rj Z sup½aj1 ðv C t C qðtÞÞ K aj1 ðt C qðtÞÞ vO0

j j ajC1 1 ðtÞ Z inf0 ½sup½a1 ðt C qÞ; sup½a1 ðt C sÞ j

Proof 2 (Proof of Theorem 5)Based on (11), q(t) is derived here for a dual leaky bucket constrained flow 1. The sub-aggregate 2 arrival curve is assumed to be concave to simplify the proof. Concavity is probably not required, yet, the aggregate of a number of dual leaky bucket constrained flows is concave anyway. Especially the supvO0[.] in the numerator of (11) is of interest for the following derivation. It is given by (A11).

j

(A8Þ

The inf[.] in (A8) is found for qZq*, resulting in (A9) and (A10), which proofs Theorem 4. j ajC1 1 ðtÞ Za1 ðt CqÞ

(A9)

supvO0 ½aj1 ðv Ct CqÞ Kaj1 ðt CqÞCaj2 ðvÞKRj $v qZ CT j Rj (A10) Here, q!q 0 is not investigated. Instead, it can be shown that the bound in (A9) and (A10) for qZq*Rq 0 is attained. Thus, we cannot find a better solution if q!q 0 is considered.

qðt Z 0Þ Z

supvO0 ½aj1 ðv C qÞ K aj1 ðqÞ C aj2 ðvÞ K Rj $v CTj Rj (A12)

j With ajC1 1 ðtÞZ a1 ðtC qðtÞÞ according to (10) we find the jC1 output burst size b1 Z aj1 ðqð0ÞÞ, which proves (15). Case 2 ð0! t! t
j1 K qðtÞÞ. Note that q(t) can be greater than t
j1 for all tR0, so that case 2 does not apply. However, this instance is covered by case 3 and addressed here only for illustrative purposes. If qðtÞR t
j1 for all tR0 then qð0ÞR t
j1 and (A11) simplifies to (A27), so that q(t) is constant for all tR0. With qðtÞZ qð0ÞR t
ji
jC1 according to (15) and (16). it follows that bjC1 i Z bi Further on, since r
1 R r1 , the parameters ð
r i ; bijC1 Þ of the dual leaky bucket constraint become redundant. The trunk 1 output constraint is reduced to a single leaky jC1 bucket constraint with parameters ðr1 ; b
1 Þ. For 0! t! t
j1 K qðtÞ a differentiation is made concerning the variable v(t), for which the supvO0[.] in (A11) is found. We distinguish between two cases: vðtÞC tC qðtÞ! t
j1 and vðtÞC tC qðtÞR t
j1 . Case 2a ðð0! t! t
j1 K qðtÞÞo ðt! t
j1 K vðtÞK qðtÞÞÞ. The sup[.] in (A11) is derived based on (A13–A15) for 0% t% t
j1 K qðtÞ and t% t
j1 K vðtÞK qðtÞ.

aj1 ðv C t C qÞ Z bj1 C r
1 $ðv C t C qÞ

(A13)

aj1 ðt C qÞ Z bj1 C r
1 $ðt C qÞ

(A14)

aj1 ðv C t C qÞ K aj1 ðt C qÞ Z r
1 $v

(A15)

Replacing (A15) in (A11) yields (A16) ðq K T j Þ$Rj Z

sup 0!v%t
j1KtKq

½
r 1 $v C aj2 ðvÞ K Rj $v

(A16)

M. Fidler et al. / Computer Communications 28 (2005) 274–286

For continuously differentiable and concave a2(v), the sup[.] in (A16) is found for a unique v, where vaj2 ðvÞ=vvZ Rj K r
1 with 0! v% t
j1 K tK q. Thus, v is independent of t, which can also be shown to hold for non-continuously differentiable, for example piecewise linear, aj2 ðvÞ. Now, define DtO0 with tC Dt% t
j1 K qðtC DtÞ and tC Dt% t
j1 K vK qðtC DtÞ. At time tCDt a modified qðtC DtÞZ qðtÞC Dq can be observed. However, with (A16) we find that q is independent of t and constant over the investigated interval, so that DqZ0. j With ajC1 1 ðtÞZ a1 ðtC qÞ according to (10) the output arrival curve of trunk 1 increases with ajC1 1 ðtC DtÞK j j ajC1 r 1 $Dt. Thus, 1 ðtÞZa1 ðtC DtC qC DqÞK a1 ðtC qÞZ
with case 1 the leaky bucket parameters ð
r 1 ; bjC1 1 Þ in Theorem 5 are proven for case 2a. Case 2b ðð0! t! t
j1 K qðtÞÞo ðtR t
j1 K vðtÞK qðtÞÞÞ. Again, the sup[.] in (A11) is derived based on (A17– A19) for 0! t% t
j1 K qðtÞ and tR t
j1 K vðtÞK qðtÞ. Note that j bj1 C r
1 $t
j1 Z b
1 C r1 $t
j1 j

aj1 ðv C t C qÞ Z b
1 C r1 $ðv C t C qÞ Z bj1 C r
1 $t
j1 C r1 $ðv C t C q K t
j1 Þ

ðA17Þ

aj1 ðt C qÞ Z bj1 C r
1 $ðt C qÞ

(A18)

aj1 ðv C t C qÞ K aj1 ðt C qÞ Z r
1 $ðt
j1 K t K qÞ C r1 $ðv C t C q K t
j1 Þ

ðA19Þ

Substitution of (A19) in (A11) yields (A20) ðq K T j Þ$Rj Z

sup ½
r 1 $ðt
j1 K t K qÞ C r1 $ðv C t C q K t
j1 Þ

vRt
j1KtKq

C aj2 ðvÞ K Rj $v

(A20)

Again, for continuously differentiable and concave a2(v), the sup[.] in (A20) is found for a unique v, where va2 ðvÞ =vvZ Rj K r1 with vR t
j1 K tK q. As before, v is independent of t, which can also be shown to hold for noncontinuously differentiable aj2 ðvÞ. However, for tZ t
j1 K vðtÞK qðtÞ the special case of va2 ðvÞ=vv! Rj K r1 and va2 ðvÞ=vvO Rj K r
1 can be attained, which is excluded here and addressed afterwards. Now, define DtO0 with tC Dt% t
j1 K qðtC DtÞ. At time tCDt a modified qðtC DtÞZ qðtÞC Dq can be observed. As given by (A19) we find a decrease of ðDtC DqÞ$
r 1 and an increase of (DtCDq)$r1 for the sup[.] in (A11). With (A20), Dq can be defined according to (A21)

 r K r
qðt C DtÞ K qðtÞ Z Dq Z ðDt C DqÞ$ 1 j 1 R Z KDt$

r
1 K r1 Rj C r
1 K r1

285

Fig. A1. Example case of (A11).

Fig. A1 gives an example, which illustrates Eq. (A11) for this case. The arrival curves of trunks 1 and 2 are shown, whereby the trunk 1 arrival curve is dual leaky bucket constrained. It is moved to the left by tCq and downwards by bj1 C r
1 $ðtC qÞ. Further on, the rate of the service curve R is displayed. Obviously, the value of v for which the sup[.] is found is not affected, if the arrival curve of trunk 1 is moved further to the lower left corner. However, the value of the sup[.] in (A11) decreases as shown by (A19). j With ajC1 1 ðtÞZ a1 ðtC qÞ according to (10) we find that the output arrival curve of trunk 1 increases with jC1 j j ajC1 1 ðtC DtÞK a1 ðtÞZ a1 ðtC DtC qC DqÞK a1 ðtC qÞZ ðDtC DqÞ$
r 1 ! Dt$
r 1 . Thus, applying DqZ0 yields the leaky bucket parameters ð
r 1 ; bjC1 1 Þ in Theorem 5, which overestimate the output arrival curve. Yet, arrival curves are defined to give an upper bound on the respective arrival functions, which allows loosening arrival constraints. Now, the special case with tZ t
j1 K vðtÞK qðtÞ and va2 ðvÞ=vv! RK r1 is covered, where r1 $ðvC tC qK t
j1 ÞZ 0 in (A20). Define DtO0 with Dt/0, which results in a corresponding Dq. For DtOKDq the sup[.] in (A20) allows applying smaller values v that fulfill vR t
j1 K tK q. For continuously differentiable and concave trunk 2 arrival curves eventually va2 ðvÞ=vvZ RK r1 is reached for vZ t
j1 K tK DtK qK Dq. However, the sup[.] in (A20) is found for vZ t
j1 K tK DtK qK Dq as long as va2 ðvÞ=vv! RK r1 . Thus, we find that vC tC qZ t
1j is constant, which allows deriving (A22) from (A20) ðq K T j Þ$Rj Z r
1 $ðt
j1 K t K qÞ C aj2 ðt
j1 K t K qÞ K Rj $ðt
j1 K t K qÞ

(A22)

Similar to the derivation of (A21), we derive (A23) from (A22) (A21)

We find that Dq!0 and DtOKDq, so that tC DtO t
j1 K vK qðtC DtÞ holds for tR t
j1 K vK qðtÞ and DtO0.

Dq Z

aj2 ðt
j1 K t K Dt K q K DqÞ K aj2 ðt
j1 K t K qÞ Rj C ðDt C DqÞ$

Rj K r
1 Rj

(A23)

286

M. Fidler et al. / Computer Communications 28 (2005) 274–286

In the absence of a concrete trunk 2 arrival curve, we cannot derive a solution for (A23). However, a range for Dq can be given. For differentiable and concave trunk 2 arrival curves aj2 ðtÞ we know that va2 ðvÞ=vvR Rj K r
1 at vZ t
j1 K tK q. Otherwise the sup[.] in (A11) is found for v! t
j1 K tK q and case 2a applies. Thus, (A24) can be given as an upper bound Dq%KðDt C DqÞ$

Rj K r
1 Rj K r
1 C ðDt C DqÞ$ Z0 Rj Rj (A24)

Further on, with va2 ðvÞ=vv% Rj K r1 for vR t
j1 K tK q, we find (A25) DqRKðDt C DqÞ$ Z KðDt C DqÞ$

Rj K r 1 Rj K r
1 C ðDt C DqÞ$ Rj Rj

r
1 K r1 Rj

(A25)

The lower bound in (A25) is the same equation as derived in (A21), which yields (A26), so that DtRKDq holds DqRKDt$

r
1 K r1 Rj C r
1 K r1

(A26)

Now, with 0R DqRKDt$ð
r 1 K r1 Þ=ðRj C r
1 K r1 Þ, we apply the same argumentation as before and apply DqZ0, yielding the leaky bucket parameters ð
r 1 ; bjC1 1 Þ in Theorem 5. Case 3 ðtR t
j1 K qðtÞÞ. For tC qðtÞR t
j1 , (A27) can be derived immediately from (A11) qðtÞ Z

supvO0 ½r1 $v C aj2 ðvÞ K Rj $v CTj Rj

(A27)

Note that q(t) according to (A27) is constant for tR t
j1 K qðtÞ. Further on, qð0ÞR qðtR t
j1 K qðtÞÞ, since r
1 R r1 is assumed. With (10) the output arrival curve of trunk 1 j is given as ajC1 The conditions 1 ðtÞZ a1 ðtC qðtÞÞ. j j j tC qðtÞR t
1 , and thus a1 ðtC qðtÞÞZ b
1 C r1 $ðtC qðtÞÞ hold for tR t
j1 K qðtÞ. Resulting, the output arrival curve of trunk 1 increases with rate r1 for tR t
j1 K qðtÞ. The output burst jC1 jC1 j size b
1 can be derived as b
i Z aj1 ðtC qðtÞÞK r1 $tZ b
1 C jC1 j j

r1 $qðtÞ for any tR t
1 K qðtÞ, so that bi Z b1 C r1 $qðt
j1 Þ jC1 holds, which proves that ðr1 ; b
1 Þ according to (16) is a trunk 1 output constraint.,

References [1] H. Balakrishnan, H. Rahul, S. Seshan, An integrated congestion management architecture for Internet hosts, Proceedings of ACM SIGCOMM Computer Communication Review 29 (4) (1999) 175–187.

[2] S. Blake, et al., An Architecture for Differentiated Services, RFC 2475 1998. [3] C.-S. Chang, Performance Guarantees in Communication Networks, TNCS, Springer, 2000. [4] V. Cholvi, J. Echagu¨e, J.-Y. le Boudec, Worst case burstiness increase due to FIFO multiplexing, Elsevier Performance Evaluation 49 (1–4) (2002) 491–506. [5] R.L. Cruz, A calculus for network delay. Part I: network elements in isolation, IEEE Transactions on Information Theory 37 (1) (1991) 114–131. [6] R.L. Cruz, A calculus for network delay. Part II: network analysis, IEEE Transactions on Information Theory 37 (1) (1991) 132–141. [7] R.L. Cruz, SCEDC: Efficient Management of Quality of Service Guarantees, Proceedings of IEEE Infocom, 1998 pp. 625–634. [8] B. Davie, et al., An Expedited Forwarding PHB, RFC 3246 2002. [9] M. Fidler, Providing Internet Quality of Service based on Differentiated Services Traffic Engineering, PhD Thesis, Aachen University, 2003. [10] M. Fidler, On the Impacts of Traffic Shaping on End-to-End Delay Bounds in Aggregate Scheduling Networks, LNCS 2811, Proceedings of Cost 263 QoFIS, Springer, 2003. pp. 1–10. [11] M. Fidler, V. Sander, A parameter based admission control for differentiated services networks, Elsevier Computer Networks Journal 44 (4) (2004) 463–479. [12] F. Fitzek, M. Reisslein, MPEG-4 and H.263 video traces for network performance evaluation, IEEE Network Magazine 15 (6) (2001) 40–54. [13] M. Handley, S. Floyd, J. Padhye, J. Widmer, TCP friendly rate control (TFRC): protocol specification, RFC 3448 2003. [14] J.-Y. Le Boudec, Some properties of variable length packet shapers, Proceedings of ACM Sigmetrics, 2001 pp. 175–183. [15] J.-Y. Le Boudec, P. Thiran, Network Calculus: A Theory of Deterministic Queuing Systems for the Internet, LNCS 2050, Springer, 2002. [16] L. Lenzini, E. Mingozzi, G. Stea, Delay Bounds for FIFO Aggregates: A Case Study, LNCS 2811, Proceedings of COST 263 QoFIS, Springer, 2003. pp. 31–40. [17] K. Nichols, V. Jacobson, L. Zhang, A two-bit differentiated services architecture for the Internet, RFC 2638 1999. [18] E. Ossipov, G. Karlsson, The Effect of Per-input Shapers on the Delay Bound in Networks with Aggregate Scheduling, LNCS 2899, Proceedings of MIPS, Springer, 2003. pp. 107–118. [19] A.K. Parekh, R.G. Gallager, A generalized processor sharing approach to flow control in integrated services networks: the single-node case, IEEE/ACM Transactions on Networking 1 (3) (1993) 344–357. [20] A.K. Parekh, R.G. Gallager, A generalized processor sharing approach to flow control in integrated services networks: the multiple-node case, IEEE/ACM Transactions on Networking 2 (2) (1994) 137–150. [21] V. Sander, Design and Evaluation of a Bandwidth Broker that Provides Network Quality of Service for Grid Applications, PhD Thesis, Aachen University, 2002. [22] V. Sander, M. Fidler, Evaluation of a Differentiated Services based Implementation of a Premium and an Olympic Service, LNCS 2511, Proceedings of Cost 263 QoFIS, Springer, 2002. pp. 36–46. [23] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP: a transport protocol for real-time applications, RFC 1889 1996. [24] AIX Documentation, System Management Guide: Communications and Networks, TCP/IP Quality of Service (QoS). [25] Cisco Documentation, Policing and Shaping, Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2.