1

QoS IQoS I

Do Hyeong Im

2002. 04. 30

2

OutlineOutline

Controlling high-bandwidth flows at the congested router

Providing quality of service guarantees without per-flow state

3

Controlling high-bandwidth Controlling high-bandwidth flows at the congested routerflows at the congested router

4

ContentsContents

Introduction Related work RED-PD Identifying high bandwidth flows Preferential dropping Evaluation Conclusions

5

Introduction Introduction

FIFO queuing at the router Simple to implement and well-suited to the

heterogeneity of the Internet It does not protect other flows from high-bandwidth

flows

Per-flow scheduling mechanisms Providing max-min fairness But keeping state for all the flows

6

Related work (1)Related work (1) RED

To control the average queue length Poor performance under changing traffic load

CSFQ (Core-Stateless Fair Queuing) To achieve fair queuing without per-flow state in the core

routers To require an extra field in the packet headers

FRED (Flow Random Early Detection) The dropping probability of a flow depend on the number of

buffered packets from that flows SRED (Stabilized RED)

Cache of recently seen flows to determine the high bandwidth flows

7

Related work (2)Related work (2)

SFB (Stochastic Fair Blue) Multiple levels of hashing to identify high-bandwidth flows

CHOKe An incoming packet is matched against a random packet in

the queue When the number of flows is large and the high-bandwidth

flows have only a few packets in the queue

8

RED-PD (1)RED-PD (1)

Identifying high bandwidth flows Preferential dropping

9

RED-PD (2)RED-PD (2)

Difference from other schemes To improve the performance of low-bandwidth flow using a

small amount of state Predictable effect on the traffic going through the router

10

Identifying high bandwidth flows (1)Identifying high bandwidth flows (1)

Using the RED drop history To identify flows that are sending more than ƒ(r,p) ,

the reference TCP flow’s rate ( RTT r and packet

drop rate p)

prprf

5.1),(

11

Identifying high bandwidth flows Identifying high bandwidth flows (2)(2)

Congestion epoch length

Maintaining the packet drop history over K x CL(r,p) seconds

Partitioning the history into M lists RED-PD identifies flows with losses in at least K of M

lists K = 3, M = 5, r = 40ms and p = 1%

p

r

pprfprCL

5.1),(

1),(

12

Preferential dropping (1)Preferential dropping (1)

Pseudo code for reducing a flow’s dropping probability

13

Preferential dropping (2)Preferential dropping (2)

Pseudo code for increasing a flow’s dropping probability

14

Evaluation (1)Evaluation (1)

Probability of identification

15

Evaluation (2)Evaluation (2)

Fairness

Multiple CBR flowsflow 1 : 0.1Mbps, flow 2 : 0.5 Mbps, every subsequent flow : 0.5 Mbps more than the previous flow

Mix of TCP and CBR flowsflow 1-9 : TCP flows with RTTs of 30,50,70 ms

flow 10-12 : CBR flows with 5,3,1 Mbps respectively

16

Evaluation (3)Evaluation (3)

Response time The speed of RED-PD’s reaction depends on the

ambient drop rate and the arrival rate of the monitored flow

1 CBR flow and 9 TCP flows

The CBR flow starts with a rate of 0.25 Mbps, increases it to 4 Mbps at t=50s, and decreases it back to 0.25 Mbps at t=250s. The RTT of the TCP flows ranged from 30 to 70 ms.

17

Evaluation (4)Evaluation (4)

Effect of R, the target RTT

Increasing R

More flows are monitored

Decreasing the ambient drop rate

Increasing the bandwidth available to the unmonitored flow

18

Conclusions Conclusions

RED-PD Using drop history to identify high-bandwidth

flows and controlling their throughput in times of congestion

Applicable to the current Internet

19

Providing quality of service Providing quality of service guarantees without per-flow stateguarantees without per-flow state

20

Contents Contents

Introduction Related work Quality of service model Signaling protocol Fault tolerance Dynamic packet scheduling Region aggregation Conclusions

21

Introduction Introduction Improving the QoS provided by Internet

Integrated service (Intserv) QoS is based on scheduling protocol Each router maintains per-flow state Scalability problem Difficult to maintain in a distributed environment

Differentiated service(Diffserv) A few bits are reserved in each packet to indicate its per-

hop behavior(PHB) At each router packets are classified and forwarded

according to their PHB High levels of QoS and network utilization cannot be

accomplished

22

Related work (1)Related work (1) Some attempts to provide the QoS level of

Intserv without any per-flow state at the core routers

The signaling protocol and the packet scheduling protocol must function without per-flow state

Dynamic packet state Each packet carries enough information to reproduce

its deadline at each router Unable to compute the deadline accurately if a channel

has a variable delay Flow aggregation

Cannot be used across multiple domains

23

Related work (2)Related work (2) Signaling methods without per-flow state

Observation methods To estimate the resource requirement by

observing the traffic through the router Inaccurate estimation

Bandwidth broker methods Resource reservation is managed by a

bandwidth broker Centralized brokers are vulnerable to faults Distributed brokers have the difficulty of

maintaining their state synchronized

24

Quality of service model (1)Quality of service model (1)

Some notations

s

s

ifs

ifs

s

if

if

if

f

C

E

A

L

L

L

p

R

,,

,,

max

max,

,

,

bandwidth reserved for flow f

ith packet of f, i≥1

length of packet pf,i

maximum of Lf,j ,where 1≤j ≤i

maximum packet length at s

arrival time of pf,i at scheduler s

exit time of pf,i from s

bandwidth of the output channel of s

upper delay bound of the output channel of s

25

Quality of service model (2)Quality of service model (2)

Ss,f,i the time at which the first bit of pf,i is forwarded by s

Fs,f,i the time at which the last bit of pf,i is forwarded by s

Rf forwarding rate of s

Ss,f,1 = As,f,1

Ss,f,i = max(As,f,i, Fs,f,(i-1)) , for every i, i >1

Fs,f,i = Ss,f,i + Ls,f,i / Rf , for every i, i ≥1

Rate-guaranteed schedulerEs,f,i ≤ Ss,f,i + δs,f,i , for every input flow f of s and every i, i >1

δs,f,i the delay of packet pf,i at scheduler s

Ss,f,i + δs,f,i deadline of at s

26

Quality of service model (3)Quality of service model (3) The delay of a packet across a sequence of schedulers Let t1, t2,…,tk be a sequence of k rate-guaranteed

schedulers traversed by flow f , for all i

1

1

1

1

,,,,1,,

k

x

k

x

txiftxiftiftk SS

}{max ,,1

,, xfsix

ifs

where

27

Quality of service model (4)Quality of service model (4) Scheduling test

To ensure packets exit by their deadline Rate-dependent delay

f

sf CR

Rate-independent delay

For all t, t > 0,

sff

ffsfs CtL

L

Rttf

max

max

,, 1

)(,,

where δs,f is the delay of flow f at scheduler s

(1)

(2)

28

Signaling protocol (1)Signaling protocol (1) How much information is needed?

In case (1), the total of the reserved rates of flows and the rate of output channel

In case (2), a count of input flows in each (rate, delay) pair

Objective To maintain the above information current at each

node Soft state

Each flow periodically send Refresh messages along the path to its destination

29

Signaling protocol (2)Signaling protocol (2) We assume the scheduler uses rate dependent delay and test (1) Each scheduler s updates its state every T seconds in the

following way:SumRatess := ShadowSumRatess;

ShadowSumRatess := 0;

SwapBitss := ¬ SwapBitss;

Whenever s receives a Refresh message from f, the following is performed

if bf,s ≠ SwapBitss then

ShadowSumRatess := ShadowSumRatess + Rf;

bf,s := SwapBitss

end if

forward Reserve towards the destination of f

When the destination receives this message, it returns a RefreshAck message back to the source of f

30

Signaling protocol (3)Signaling protocol (3) When a new flow f is created

Upon receiving a Reserve message from f at sif SumRatess + Rf ≤ Cs then

ShadowSumRatess := ShadowSumRatess + Rf;

SumRatess := SumRatess + Rf;

bf,s := SwapBitss ;

forward Reserve towards the destination of f

else

Return a Reject message towards the source of f

end if

Upon receiving a Reject message for flow f if SwapBitss= bf,s then

ShadowSumRatess := ShadowSumRatess - Rf ;

SumRatess := SumRatess - Rf;

else

SumRatess := SumRatess - Rf;

endif

Forward Reject towards the source of f

31

Signaling protocol (4)Signaling protocol (4)

32

Signaling protocol (5)Signaling protocol (5) How often should the source of a flow send a Refresh

message? D : on the time for signaling message to traverse the network The interval between the successive transmissions of Refresh

messages should be at most T - D

33

Fault toleranceFault tolerance

Delayed or lost signaling messages If a source does not receive a RefreshAck, then the source

terminates the flow This should occur rarely

Link failure & Process failure The path from source to destination may change before the

flow is terminated

Routing changes If the path of f changes, its message are dropped where the

change occurred,causing the termination of f

34

Dynamic packet scheduling (1)Dynamic packet scheduling (1)

Consider two consecutive schedulers, s and t, of flow fAt,f,i ≤ St,f,i ≤ Ss,f,i + Δs,f,i +πs

assume At,f,i = Ss,f,i + Δs,f,i +πs for all pf,i

then

St,f,i = At,f,i = Ss,f,i + Δs,f,i +πs

Before s forwards pf,i to t, s computes Ss,f,i and store Ss,f,i in pf,i

If pf,i arrives earlier than Ss,f,i, it is kept in a buffer until time Ss,f,i, then it is considered “arrived” and may be scheduled for transmission

But all schedulers must have a common clock

35

Dynamic packet scheduling (2)Dynamic packet scheduling (2)

Scheduler s computes the early departure of pf,i, denoted εs,f,i, as follows

εs,f,i = Ss,f,i + Δs,f,i – Es,f,I

Disadvantages If the output channel has variable delay, then is not

computed accurately Assume some schedulers have clocks which run fast, and

forward packets to a scheduler with a normal clock

=> This will cause excessive delays to other flows of the normal scheduler

36

Region aggregation (1)Region aggregation (1)

Taking advantage of the hierarchical structure of internetworks The gateways are nodes in the network The circuits between gateways are output channels with

variable delay Gateways have synchronized clocks using the NTP protocol

37

Region aggregation (2)Region aggregation (2)

The packets of all the flows sharing the same circuit are aggregated together to become a single flow g

The aggregation should be done in a fair manner A lower per-hop delay is possible for the aggregated

flow than for the individual flows

38

Conclusions Conclusions

Approach to provide QoS guarantees without per-flow state at each router Signaling protocol

Maintaining a constant amount of state per router

Accurate and resilient to process and link failures

Packet scheduling technique A combination of the dynamic packet state and

flow aggregation