QoS in integrated services based IP networks: The solution to the peak rate policing issue

QoS in integrated services based IP networks: The solution to the peak rate policing issue

ITC 18 / J. Charzinski, R. Lehnert and P. Tran-Gia (Editors) 9 2003 Elsevier Science B.V. All rights reserved. 1131 QoS in Integrated Services Based...

535KB Sizes 0 Downloads 47 Views

ITC 18 / J. Charzinski, R. Lehnert and P. Tran-Gia (Editors) 9 2003 Elsevier Science B.V. All rights reserved.

1131

QoS in Integrated Services Based IP Networks: The Solution to the Peak Rate Policing Issue Lorenzo Battaglia a and Ulrich Killat b aEADS Astrium, Satellite Systems Engineering for Navigation and Constellations Contact through www.battaglia.de bTechnical University of Hamburg-Harburg, Germany, Communication Networks Department Contact through [email protected] Quality of Service (QoS) can be guaranteed in any network, a priori from the used technology, only if the used admission control algorithm wisely shares the network's resources among the users. Any admission control algorithm on its turn can do so, only if every user respects the negotiated traffic parameters. Since any user could, maliciously or not, send at a higher rate than negotiated, i.e. use a higher share of resources than the negotiated one, in every network in which admission control is performed, a policing algorithm is used. An ideal policer should guarantee to reject no packet of a well-behaved user and police contract violation as rigidly as possible. All this independently of the characteristics of the monitored stream and of the background traffic. All this can be applied to IP networks based on Integrated Services (IntServ). In these networks two rates are negotiated between user and service provider: peak and average rate. In this paper we present the solution to the peak rate policing issue and provide the deriving worst case packet clusters that the policer could let into the network. Such knowledge could on its turn be used for the admission control algorithms. We adapt the Generic Cell Rate Algorithm (GCRA), well-known policer used in ATM networks, to police the peak rate of flows of packets with variable length. We intuitively call this algorithm Generic Packet Rate Algorithm (GPRA). We present an analytic dimensioning of the GPRA parameters which transforms it into an ideal peak rate policer. Independently of the characteristics of the policed flow and of the background traffic, the GPRA rejects no packets of a well-behaved user and rigidly polices any misbehaving user. With our results we lay the foundations of QoS in packet-switching networks that use packets of variable length. 1. I N T R O D U C T I O N The first step to guarantee QoS in any network is to introduce an admission control function and to equip it with a powerful policing function. Also in IntServ-based IP networks a policing function was introduced at the edges of the network, with the task to guarantee that the amount of traffic entering the network with QoS guarantees is at any time at most the negotiated one.

1132 A properly working policer should be transparent to the flows that respect the agreements, police any misbehaving flow as rigidly as possible, work independently of the interference of other flows, work fast and finally be simple to implement and cost effective. In IntServ any user requesting guaranteed service, specifies the traffic (TSpec) that will be offered and the desired service (RSpec). The TSpec takes the form of a token bucket with bucket depth b and a bucket rate r, plus a peak rate p, a minimum policed unit Smi,, and a maximum datagram size Sma,. About these quantities: 9 b,Smin,Smax" are measured in bytes; 9

is the average rate at which the user can at most send datagrams, and is measured in bytes of complete IP-datagrams per second; r:

is the maximum rate at which the user is allowed to send datagrams. measured in bytes of complete IP-datagrams per second.

9 p:

It is

Should the flow be accepted, it is required that for all time periods t the amount of data sent cannot exceed min(pt + M, rt + b)

(1)

bytes, with r _ p and b > M. Note that, due to the tolerances M and b and to the fact that b > M, equation (1) cannot be trivially written as rt + b for all t E T~+. An IntServ-supporting IP edge-router has two broad functional divisions: the forwarding path and the control plane. The control plane provides functions like admission control and resource reservation. In the forwarding path a classifier identifies the packets according to the flow they belong to. A token bucket checks for each flow if the parameters r and b are the negotiated ones 1. Finally a packet scheduler forwards the packets to the corresponding output ports, according to the routing decisions. No datagram peak rate (p) policing device checks if p and M measured at the network access point are the negotiated ones. This implies that for all time intervals t for which pt § M < rt + b holds, a higher amount of data with guaranteed service would be let into the network, invalidating the decision of any admission control algorithm. In such way the QoS of other well-behaved flows would be endangered. This is obviously unacceptable. We started our investigations with the task to solve the peak rate policing issue in IntServ-based IP networks, after having solved the Usage Parameter Control (UPC) issue in ATM networks (see [4] for a complete handling). As peak datagram rate policer we chose the in ATM standardised rate policer, the Generic Cell Rate Algorithm (GCRA) [2] because with our dimensioning the GCRA proved to perform for ATM and in the same scenario far better than its competitors [3]. We made the GCRA capable of policing streams of packets having variable length and called this generalized policer Generic Packet Rate Algorithm (GPRA). The GCRA depends on two parameters" the Increment I and the Limit L. Similarly we denoted the GPRA parameters by IB and LB, where the suffix B denotes that the parameters are expressed in bytes. Since in general a user has more than one active connection (i.e. flow) at a time and they share 1The dimensioning of this token bucket, due to its equivalence to the GPRA, could be done using a procedure similar to the one we present in the sequel

1133 the same physical link to the IP edge-router, we decided to solve the peak rate policing issue for a flow passing through a FIFO multiplexer before entering the IP edge-router. Note that in [6] this issue is not addressed. The question is then: which parameters M and p should a user negotiate for a flow, if all the active flows share the link through a FIFO multiplexer? Is it possible to dimension the GPRA in such way that it behaves like an ideal policer? In this paper we analytically provide the required GPRA dimensioning, independently of the characteristics and of the behaviour of the other flows that share the link and without any restrictive assumptions (in contrast to previous GCRA dimensioning methods as proposed for instance in [5], [7] and [10]). The simplicity of GPRA guarantees its speed of operation and its low-cost. This paper is organized as follows. In Section 2 we model the problem. In Section 3 the GCRA is presented, in Section 4 the GPRA. Section 5 shows how to dimension the GPRA parameters. In Section 6 our results are compared to those obtained with a GCRA, in the case of packets (all) with the same length like in ATM. Finally, Section 7 provides the user with the required formulae to determine the peak rate traffic parameters to negotiate, and the network provider with the appropriate GPRA parameters' dimensioning. 2. M O D E L L I N G T H E P R O B L E M

We consider the peak rate policing of a flow, whose packets pass through a FIFO multiplexer before entering the provider's edge-router (see Figure 1). Let r and p respectively be the average and the maximum negotiated rate of the flow to police. Let S,~in and Sm~x be its smallest and the biggest negotiated packet size. Let the multiplexer have N inputs and be equipped with a buffer of BB bytes. About the other N - 1 flows, also referred as background traffic, no hypotheses are made. We assume that when a packet enters the multiplexer, all its S bytes enter it at once. A packet is discarded by the multiplexer if its length S is bigger than the available free space. We assume the buffer length BB to be bigger than Sm~x. In the edge-router packets are classified according to the flow they belong to, sent to a token bucket policer (which polices the average rate r, see Figure 2), and accordingly sent to the packet scheduler with QoS guarantees or not. In order to police also the peak rate p, we slightly modify the policing unit by adding a GPRA (see Figure 3). The scheduler guarantees the negotiated QoS only to those packets which comply with the negotiated p (GPRA) and r (token bucket). 3. T H E G E N E R I C

CELL RATE ALGORITHM

We only briefly recall some useful concepts of the GCRA. We refer to a GCRA(I, L) and consider the policing of a stream of cells, i.e. of packets (all) of the same length (in ATM this length is of 53 bytes). Let's consider a possible realisation of the departure process of such a stream from a queueing system. Let's denote by ta(i) the discrete time instant in which the i-th cell of the monitored stream arrives at the policer and by TAT(i) its Theoretical Arrival Time. Whenever ta(i) > TAT(i) the cell is accepted and the following TAT is given by

TAT(i + 1) = ta(i) + I.

1134

Figure 1. The considered topology. The unmarked packets belong to the monitored connection. Of the edge-router only the forwarding path is shown, with the policing function taken out of the scheduler for clarity.

FromClassifier

~---@To Scheduler(withQoS) To Scheduler(BestEffort) TokenPool(Capacity= b)

Fi) T~ok~ Generator(Rate= r) Figure 2. The token bucket policer used for the mean rate enforcing.

FromClassifier [------~~---~ I GPRA~ ~ To Scheduler(BestEffort)

j~_~_.. To Scheduler(withQoS) ~NC To Scheduler(BestEffort) I_~ _1~/Pool (Capacity= b) _ ~ G e n e r a t o r (Rate= r)

Figure 3. The policing function with the token bucket and the GPRA.

1135 If t~(i) <_ TAT(i) the cell is accepted only if

T A T ( i ) - L <_t~(i) holds and the next T A T is given by

TAT(i + 1) = T A T ( i ) + I. Also in ATM, if a cell is not accepted, it can be taken out of the network or simply be marked as non-compliant. The basic time unit of the GCRA is called time slot. One time slot is the time needed by the link to send a cell. In this way the GCRA refers only indirectly to the link rate Rti,k. 4. T H E G E N E R I C

PACKET

RATE ALGORITHM

Clearly things change in a system with variable packet length. In order to further benefit from the queueing theory for discrete time systems, a basic packet length unit and a basic time unit have to be chosen. We then consider a byte as the basic packet length unit and a time slot as the basic time unit. We redefine a time slot as the service time for a byte in the considered queueing system. To make the GPRA work as the GCRA with an implicit link rate Ru,k, we introduce a new quantity the Peak Byte Rate (PBR), in bytes per time slot, as

PBR =

p Rlink

"

In ATM, once an I is negotiated, after a cell arrives, the following is expected to arrive at the earliest I time slots later. For instance, if the first monitored cell arrives at time slot ta(1), the following is expected at

ta(2)=I+t~(1). Similarly for the PBR policing after the first packet of a flow arrives, let its size be of S(1) bytes, the second packet is expected to arrive, independently of its length S(2) but of course according to the amount of bytes arrived with the first packet and to the negotiated IS, at the earliest at t. B(2) = IB" S ( 1 ) + t. B(1) where t. B(i) denotes the arrival time slot of packet i of the monitored stream. The TAT updating has then to be modified, since in the GCRA the packet length (being assumed as constant) doesn't play any role. We denote by TAT B the modified TAT and by TATB(i) the theoretical arrival time of the i-th packet at the policer. If a packet, say the ith, arrives at the policer after TATB(i), it is accepted and

TATB(i + 1) = t. B(i) + [B " S(i). If this packet arrives before TATB(i), it is accepted only if

T A T s ( i ) - LB < ta B(i). If this is the case, then

TATB(i + 1) = TATs(i) + Is" S(i).

1136

5. D I M E N S I O N I N G

THE GPRA

PARAMETERS

Due to the different delays that the packets of each flow experience in the multiplexer, a source may appear to send at a higher rate than negotiated (see Figure 4) even in case it is well-behaved: how should then I s and LB be dimensioned in the GPRA in the edge router? In order to rigidly police contract violation by the source we set I s = 1 / P B R . In order to dimension LB appropriately, i.e. in order to to guarantee to discard no packets of a well-behaved user, we apply the notion of the L coverage area 2 to the worst case sequence into which a well-behaved flow can be transformed when passing through a FIFO multiplexer.

, ,

i~

, ,

~,

Figure 4. Due to the influence of the background traffic, even the packets of a well-behaved stream with a given PBR can leave the multiplexer with an apparent higher peak rate than negotiated. In this example P B R - 0.5 and the first packet is delayed of A time slots. The apparent PBR is at the beginning 1, equal to 100% of the Rlink. The GPRA should tolerate such behaviour.

5.1. The Notion of the L Coverage A r e a for P a c k e t s of V a r i a b l e Length Any stream of n packets arriving at the GPRA is uniquely identified by the sequence of the discrete time instants tas(i), i = 1, 2, ..., n, at which the monitored packets enter the policer and by the sequence S(i), i = 1, 2, ..., n, of their sizes. Let T A T s ( i ) , i = 2, 3, ..., n, be the corresponding sequence of the Theoretical Arrival Time in bytes of the ith packet at the GPRA. Whenever the ith packet arrives at the policer before its TATs any L s >_ T A T s ( i ) -

taB(i)

makes the G P R A accept that packet. We define LCAB, for the ith packet as L e A s ( i ) = [TATB(i) - taB(i)] + i.e. the smallest value of LB that allows the policer to accept it. Obviously a LCAB of 0 time slots is already enough to accept any packet arriving after its TATs. Considering the whole sequence and defining LcAsmax = m a x { L e A s ( 2 ) , L e A s ( 3 ) , ..., LCAB(n)} 2See [4] for further applications of this method.

1137

any LB > LCABmax allows then to accept all the packets of a well-behaved flow without losses. Such an a posteriori dimensioning of LB will be valid for any sequence taB(i), i -- 1, 2, ..., and S(i), i = 1, 2, ..., n, if derived from the worst case sequence into which the monitored stream can be transformed by the background traffic. Setting LB to LCABmaz guarantees that no packet of a well-behaved user is discarded. Any smaller LB would lead to a positive probability to reject a packet of a well-behaved flow. Any bigger LB would tolerate packet clusters which wouldn't ever occur in the stream of a well-behaved user. 5.2. T h e W o r s t C a s e S e q u e n c e The worst case sequence into which the monitored stream passing through a network can be transformed by the background traffic, is clearly the stream (or set of streams) for which the sequences taB(i), i = 1, 2, ..., and S(i), i = 1, 2, ... are so that LCABmaz is the biggest possible. It can be proved that the worst case sequence occurs if the first packet of the monitored connection is delayed the most by the background traffic, the other monitored packets arrive at the earliest possible at the multiplexer and are not further delayed by other background traffic packets. Intuitively this can be interpreted as the biggest possible burst of packets of a well-behaved flow that can occur due to the influence of the background traffic. 5.3. R e s u l t s We proved that in the worst case sequence: 9 S(1) is equal to Smi, and finds upon arrival BB

--

Stain + 1 bytes in the buffer..

9 A burst of at most PBR 1- PBR

"1

(BB -- Sm,. +

(2)

1)/+ Sma~ I

bytes occurs, and the last packet of the burst has length Smax. 9 The last packet of the burst arrives at the earliest at time slot

PBR (BB-Smi, + 1- PBR

I)]+ t~B(1)

9 The LCAB sequence is non-decreasing and has a maximum at the arrival slot of the last packet of the burst. Since for the last packet the TATs is

I-PBR

+to~(i) P B R

then

[ """

1-PBR

LCABmax =

~,J...~S

PBR

PBR 1- PBR

]

(BB - S~,,., + 1)/. I

(3)

1138

This can be interpreted as follows. According to (2) when the last packet of the worst case burst arrives at the multiplexer it finds in it already PBR (Bs-Srni,+l)] 1- PBR

M -

bytes of back-to-back packets of its flow. When the first packet of this burst arrives at the GPRA, the T A T s incrementing will start. The last packet of the burst, instead of arriving at the GPRA M . IB time slots later, will enter the GPRA M time slots later. Being this packet compliant it shall be accepted. Only with an LCABrnax -~ M " I s - M, or bigger, the GPRA will accept this packet as compliant. Recalling that I s = 1 / P B R it is easy to see that this coincides with equation (3). The GPRA then rigidly polices any misbehaving source and discards no packet of a well-behaved user, by setting 1 =

PBR I-PBR

PBR

-

1- PBR (Bs-

S~in + l)

or, in terms of p and Rtink

xB

=

Rlink P

LB

=

~

This by simply knowing the negotiated p, the rate of the link connecting the user to the IP network, the length of the buffer in the multiplexer (BB) and the length of the smallest packet the source can send, Stain. Curiously enough the maximum packet length Smax doesn't play any role in equation (3). It's anyway important to remember that we have assumed BB > Smax and that Sm~, is fundamental as far as the biggest possible packet cluster is concerned (2). If WBrnax, the maximum delay a monitored packet can experience when passing through the multiplexer, was known with a high reliability, then

where obviously

WBrnax ~ B B - Stain + 1.

1139

6. C O M P A R I S O N

TO T H E P C R P O L I C I N G RESULTS

We compare now the previous results obtained assuming a variable packet length, to those we obtained assuming a constant packet length [4]. Let all packets have a length of one byte, so that one time slot is again the service time for a packet, which we can call again cell. In such way BB can be written as B, in cells, Stain = Sm~ = 1 and clearly the P B R - P C R , where PCR stands in ATM for Peak Cell Rate. Let T p c n - 1 / P C R . Also LCABmax can be written as L c A m ~ and equation (3) as LCAmax=

[

]

I 1

[TP~--!B1-[TPc-R ~

-

1

"

Since

[[T.c~ t_ ] [TpcI_IB] >_T P C R [ T P c ~ _ I B ] _ [ T P c R _ Ii B] t B]

_

TpcR

1) T p c R1-

= (Tpcn-

1B1 > - B,

then (5)

LCAmax >_ B,

which is a tight upper bound of our PCR policing results, for which LCAmax = B. In [3] we showed through simulations in realistic ATM scenarios that with this dimensioning the GCRA behaves like an ideal PCR policer. 7. H O W T O U S E T H E S E R E S U L T S : M A P P I N G

TO p AND M

The IntServ requirement that for the peak rate policing in no interval t more than pt+M

bytes can enter the network with QoS guarantees, is equivalent to a leaky bucket with leak rate p and bucket size M. The GPRA, being derived from the GCRA, is equivalent to such a leaky bucket with (6)

Is

=

Rti, P

,

LB

--

M-

Rti P

(7)

.

A source willing to send packets of length between S, ni,~ and Smax bytes, with a peak rate p over a link with rate Rti,k should than negotiate a

P

+

--~

Rti,k -- P

(BB-Smin+l)

-

~(BB-Smin+l) Rti,~k -- P

,

where BB is the length of the buffer in the FIFO multiplexer at the user side. The network provider shall then dimension the GPRA parameters using equations (6) and (7).

1140 8. C O N C L U S I O N S We have solved the peak rate policing issue in IntServ-supporting IP networks by adding a GPRA, a modified version of the GCRA, the standardised ATM rate policer. With the here-presented GPRA parameters' dimensioning, the functionality of any admission control algorithm is not endangered by misbehaving users, since every misbehaving flow is policed as rigidly as possible, independently of the characteristics (e.g. self-similarity) of the policed flow and of the background traffic. The knowledge of the worst case cluster patterns that the policer would let into the network, in this paper analytically described, could be used to dimension flow admission control algorithms. Note that with this policer the negotiated QoS is guaranteed to all complying users, since no packet of a well-behaved user will ever be discarded. REFERENCES

1. A. Atlasis, G. Stassinopulos, A. Vasilakos, Leaky bucket mechanism with learning algorithm for A TM traffic policing, IEEE Symp. on Comp. and Commun.- Proc. 1997. IEEE Los Alamitos, CA, pp 68-72 2. ATM Forum, Traffic Management Specification V4.0, af-tm-0056.000, April 1996. 3. L. Battaglia, F. Guardado, U. Killat PCR Policing: A Comparison of Fuzzy Policers Versus GCRA, KiVS 2001, Hamburg, Germany. 4. L. Battaglia The Usage Parameter Control Issue in ATM Networks, ISBN 3-83111055-7, 2001. 5. P. Boyer, F.M. Guillemin, M.J. Servel, J.P. Coudreuse Spacing Cells Protects and Enhances Utilization of ATM Network Links, IEEE Network Magazine, Vol. 6, No. 5, September 1992, pp 38-49. 6. R. Braden, D. Clark, S. Shenker Integrated Services in the Internet Architecture: an Overview, RFC 1663. 7. P. Castelli, A. Forcina, A. Tonietti Dimensioning Criteria .for Policing Functions in A TM Networks, INFOCOM '92. 8. V. Catania, G. Ficili, S. Palazzo, D. Panno, A .fuzzy decision maker for source traffic control in high speed networks, Proc. 1995 Int. Conf. on Network Protocols (ICNP 95), Tokyo, Nov. 7-10, 1995. 9. C. Douligeris and G. Develekos, A Fuzzy Logic Approach to Congestion Control in ATM Networks, Proc. IEEE ICC '95, Seattle, WA, June 1995. 10. F. Huebner, Dimensioning of a Peak Cell Rate Monitor Algorithm Using DiscreteTime Analysis, ITC 14 / J. Labetoulle and J.W. Roberts (Editors). 11. Z. Jiang, Z. Liu Improved algorithm of usage parameter control in A TM networks, Int. Conf. on Commun. Tech. Proc., ICCT vol. 1, 1996. IEEE, Piscataway, N J, pp 24-27. 12. M. Laubach Classical IP and ARP over ATM, RFC 1577, January 1994. 13. L. Mason, A. Pelletier, J. Lapointe Toward optimal policing in A TM networks, Computer Communications, vol. 19, no. 3, Mar 1996, pp 194-204. 14. A. Tarraf, I. Ibrahim, and T. Saadawi, A novel neural network traffic enforcement mechanism for ATM networks, IEEE J. Select. Areas Commun., vol. 12, no. 6, pp. 1088-1096, Aug. 1994.