CS5229 Lecture 7: Queue Management

Queue Management

3 October 2008 NUS CS5229, Semester 1 2008/09 1

Not all ﬂows are
congestion controlled


1. Don’t need reliability, so
use UDP, which has no
congestion control


2. No incentive to limit
own sending rate


Sally Floyd and Kevin Fall
“Promoting End-to-End
Congestion Control in
the Internet”
TON, 1999


What mechanisms can we
add to the router to provide
incentives for congestion
control?


Idea: Identify unresponsive ﬂows,
then drop their packets or
regulate their rate.


Note: Not scalable to large
number of ﬂows
(eg in core routers).


How to identify
unresponsive ﬂows in a
router?


Approach 1:
Use TCP Throughput
Equation


The paper uses a rough approximation


MSS: Maximum packet size in bytes
over all outgoing links
p: Packet drop rates over all
outgoing links
RTT: Twice the 1-way propagation
delay of outgoing links

The expression will overestimate
the fair throughput for TCP.

Thus, not all unfriendly ﬂows will
be identiﬁed.


Approach 2:
Unresponsive Flows


Does the packet arrival rate of a
ﬂow reduce appropriately when
packet drop rate increase?


If packet drop rate increases by
x%, then packet arrival rate
should decrease by sqrt(x)%


Does Not Work:
when packet drop rate is constant


Does Not Work:
packet might be dropped by
earlier router


Does Not Work:
A ﬂow has an incentive to start
with high throughput


Approach 3:
Flows with
Disproportionate
Bandwidth


A ﬂow should share 1/n of
total bandwidth


When congestion is low
(packet drop rate is low),
skewness is OK.


Condition 1: If a ﬂow’s
bandwidth is more than ln(3n)/n
of the aggregate, then it is using
disproportionate share.

(ln(3n)/n : magic)

Condition 2: If a ﬂow’s
bandwidth is more than

For MSS=512 and RTT=0.05s

If a ﬂow’s bandwidth is more
than ln(3n)/n of the aggregate
ﬂow bandwidth, then it is using
disproportionate share.

(ln(3n)/n : magic)

Does Not Work:
ﬂows with short RTT will be
considered as disproportionate


Does Not Work:
the only ﬂow with sustained
demand (long live) will be
considered as disproportionate.


Sally Floyd and Van Jacobson
“Random Early
Detection Gateway for
Congestion Avoidance”
TON, 1993

Router’s
Queue Management


Manages sharing of
(i) buffer space
(ii) bandwidth


Q1: Which packet to drop
when queue is full?


Q2: Which packet to send
next?


FIFO + Drop Tail


Keep a single queue


Drop what?
Drop arriving packets
when queue is full


Send what?
Send the packet at
head of queue


Round Robin


One queue per ﬂow


Drop what?
Drop arriving packets from
ﬂow i when queue i is full


Send what?
Each ﬂow takes turn --
send the packet at the head
of the queues in a round
robin manner.

Advantages of
FIFO and Drop Tail


Simple to implement


Scale well
(no per-connection states)


Reduce delay for a bursty
connection
(e.g. VoIP)


Problems with
FIFO and Drop Tail


Problem 1
Bias against bursty trafﬁc

burstiness increases chances that the
queue will overﬂow


Problem 2
Global synchronization

connections reduce their windows
simultaneously, lowering utilization.


Problem 3
Queue size

higher bandwidth needs longer
queue, increasing delay. TCP tries to
keep the queue full


Problem 4
No isolation against
unresponsive ﬂows


Random Drop


Keep a single queue


Drop what?
Drop random packet in the
queue when queue is full


Send what?
Send the packet at
head of queue


No bias against bursty trafﬁc --
bursty arrival causes random
packets to be dropped.


Flows with higher rate occupy
more buffer spaces, have higher
chance to be dropped.


Signal ﬂows that is congesting
the network to slow down.


Random drop recovers from
congestion (full queue) by
dropping packets.


Early Random Drop


Drop what?
Drop arriving packet
randomly if queue is longer
than a threshold


Early random drop avoids
congestion (full queue) by
dropping packets before queue
is full.


RED
Random Early Detection


Drop what?
Drop arriving packet randomly
if average queue length is
above a threshold


Differences 1: Use average
queue length instead of
instantaneous length to absorb
transient congestion.


Differences 2: Dropping
probability should change
dynamically depending on
queue length.


Dropping Probability

1

Average Queue Length

foreach incoming packet X
calc average queue length
if minth < average < maxth
calc p
drop X with probability p
else if average > maxth
drop X

(Instead of dropping packets, we
can also set the ECN bit to
indicate congestion)


How to calculate average queue
length?

How to calculate drop probability?

How to set thresholds?


We can use exponentially
weighted average. On every
packet arrival:


Large wq : A burst of packets will
cause avg to increase too fast, hit
the max threshold

Small wq : avg increases too slowly
and we are unable to detect initial
stage of congestions.

packet arrival:


What if q drops to zero and no
packet arrives?

m is a function of period when
queue is empty

length?

How to calculate drop probability



Dropping Probability

1

pmax

Average
Queue Length

minth max th

length?

How to calculate drop probability



maxth - minth should be sufﬁciently
large otherwise average queue
size can oscillate beyond maxth
“need more research” for
optimal value.


Advantages of RED


No bias against bursty ﬂows
Less global synchronization
Control average queue length


RED does not deal with
unresponsive ﬂows


ns-2 demo


Variations of
RED

RED biases against ﬂow with
large packet size


We can ﬁx this by weighting drop
probability to packet size


A router can keep one queue per
ﬂow and apply RED to each one.


Drop probability can be weighted
with the priority of the ﬂow.


This is known as WRED and is
implemented in some Cisco
routers.


Simulation
Results

Four TCP flows starting at time 0.2, 0.4, 0.6 and 0.8


Conclusion:
RED increases throughput,
reduces delay, controls average
queue sizes, reduces global sync
and is fairer to bursty trafﬁc. It is
deployed in routers today.

But careful tuning of parameters
is needed.

CS5229 Lecture 7: Queue Management

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (16)

Similaire à CS5229 Lecture 7: Queue Management

Similaire à CS5229 Lecture 7: Queue Management (20)

Plus de Wei Tsang Ooi

Plus de Wei Tsang Ooi (20)

Dernier

Dernier (20)

CS5229 Lecture 7: Queue Management