balaji prabhakar active queue management and bandwidth partitioning algorithms balaji prabhakar...
TRANSCRIPT
High PerformanceSwitching and RoutingTelecom Center Workshop: Sept 4, 1997.
Balaji Prabhakar
Active queue management and bandwidth partitioning algorithms
Balaji Prabhakar
Departments of EE and CSStanford University
2
Overview of lecture
• Active queue management– Background
• CHOKe: a randomized AQM algorithm– The basic algorithm– Enhancements– A model and fluid analysis
• AFD: a bandwidth partitioning algorithm– Description of algorithm and performance
3
The Setup
• In a congested network with many users– whose quality-of-service (QoS) requirements are
different
• Problems:– allocate bandwidth– control queue size and hence delay
4
Approach 1: Network-centric
• Network node: fair queueing– we’ve fair queueing (WFQ) in EE 384X
• User traffic: any typeproblem: complex implementation
5
Approach 2: User-centric
• Network node: simple FIFO + AQM schemes– AQM: Active Queue Management (e.g. RED)
• User traffic: congestion-aware (e.g. TCP)problem: requires user cooperation
6
Network node:
– simple FIFO buffer– AQM schemes with enhancement to provide fairness: preferential dropping packets
User traffic: any type
Current trend
7
AQM and RED
• Passive queue management: DropTail – when the output buffer is full, simply drop an arriving packet– this signals congestion to sources
• DropTail had a number of problems1. TCP sources send packets in bursts (due to ack compression).
So, drops occur in bursts, causing TCP sources to Slow-Start
2. Synchronization between various sources could occur: they end up using bandwidth in periodic phases, leading to ineffeciences.
• RED was designed to fix these problems– drops incoming packets randomly based on congestion level– this signals the onset of congestion to the sources who will back-
off (if they are responsive) – thus, RED avoided bursty dropping, synchronization, etc.
8
AQM and RED
• Although RED is simple to implement – it can’t prevent an unresponsive flow from eating up all the
bandwidth– because, a source that simply doesn’t back-off when there are
packet drops will end up causing the others to back-off and eat up the available bandwidth.
• So, a lot of research was dedicated to finding AQM schemes that would be simple to implement and partition the bandwidth fairly; or, at least prevent a single flow from taking up all the bandwidth
9
A Randomized Algorithm: First Cut
• Consider a single link shared by 1 unresponsive (red) flow and k responsive (green) flows
• Suppose the buffer gets congested
• Observe: It is likely there are more packets from the red (unresponsive) source
• So if a randomly chosen packet is evicted, it will likely be a red packet
• Therefore, one algorithm could be:
When buffer is congested evict a randomly chosen packet
10
Comments
• Unfortunately, this doesn’t work because there is a small non-zero chance of evicting a green packet
• Since green sources are responsive, they interpret the packet drop as a congestion signal and back-off
• This only frees up more room for red packets
• Next: Suppose we choose two packets at random from the queue and compare their ids, then it is quite unlikely that both will be green
• This suggests another algorithm:
Choose two packets at random and drop them both if their ids agree
• This works: That is, it limits the maximum bandwidth the red source can consume
11
The CHOKe Algorithm
• Builds on the previous observation
• Is a randomized algorithm
• Turns out to have an easily analyzable performance via fluid models
• The last point is interesting, since it shows how surprisingly accurate fluid models are for modeling TCP- and UDP-type traffics
12
The CHOKe Algorithm
Admit new packet
Arriving packet
y
ny
Drop both packets
Draw a packet at random from queue
end
end
n
Drop the new packet
end
Admit packet witha probability p
end
y
nAvgQsize <= Minth?
Both packets from same flow?
AvgQsize <= Maxth?
13
Simulation Comparison: The setup
R11Mbps
10MbpsS(2)
S(m)
S(m+n)
TCP Sources
S(m+1)
UDP Sources
S(1)
R2
D(2)
D(m)
D(m+n)
TCP Sinks
D(m+1)
UDP Sinks
D(1)
10Mbps
14
1 UDP source and 32 TCP sources
UDP's arrival rate = 2 Mbps
0
200
400
600
800
1000
0 50 100
Time (second)
Th
rou
gh
pu
t (K
bp
s))
DropTail: UDP's ThroughputRED: UDP's ThroughputCHOKe: UDP's Throughput
15
CHOKe: Bandwidth Shares
32 TCP, 1 UDP (r = 2 Mbps) Simulation
1
10
100
1000
1 4 7 10 13 16 19 22 25 28 31
Flow Number
Th
rou
gh
pu
t (K
bp
s)) CHOKe's throughput
Ideal Fair Share
16
CHOKe: Drop Decomposition
0%
20%
40%
60%
80%
100%
1 4 7 10 13 16 19 22 25 28 31
Flow Number
Dro
p P
erc
en
tag
e (
%) Drop due to matches
Drop due to RED
17
CHOKe: Varying UDP Loadings
98.3%
97.5%
95.0%
87.0%74.1%
57.3%
45.8%34.8%
23.0%
0
50
100
150
200
250
300
350
400
100 1000 10000
UDP Arrival Rate (Kbps)
Th
rou
gh
pu
t (K
bp
s))
UDP Throughput with mark forUDP Dropping PercentageAverage TCP Throughput
18
CHOKe: Varying UDP Loadings
32 TCPs, 5 UDPs (with same arrival rate)
0
200
400
600
800
1000
1200
100 1000 10000Total UDP Arrival Rate (Kbps)
Th
rou
gh
pu
t (K
bp
s)) Total UDP Throughput
Total TCP Throughput
19
CHOKe: 5 UDPs, 5 samples
0
200
400
600
800
1000
1200
100 1000 10000
Total UDP Arrival Rate (Kbps)
Thr
ough
put
(Kbp
s)
Total UDP Throughput
Total TCP Throughput
20
Mechanizing Multiple Drops
Divide region (minth, maxth) into subregions R1,
R2, … Rk;
If Qavg Rm, drop dm packets (e.g. dm = 2 * m)
minthMaxth
R1R2Rk
21
Self-adjusting CHOKe
99.3%
93.7%89.7%
82.3%61.1%
54.0%38.3%
22.2%6.6%0
200
400
600
800
1000
1200
1400
100 1000 10000
Total UDP Arrival Rate (Kbps)
Thr
ough
put (
Kbp
s)
Total UDP Throughput with mark fordropping percentageTotal TCP Throughput
22
A Fluid Analysis
discards from the queue
permeable tube with leakage
23
Some notation
• N: total number of packets in the buffer
• Li(t): rate at which flow i’s packets cross position t of buffer • 0 = entrance and D = exit
• pi: fraction of flow i’s packets dropped at ingress = fraction of flow i’s packets dropped in buffer (since drops occur in pairs)
i : rate at which flow i packets arrive
24
The Equation
• Li(t)t - Li(t +t)t = i Li(t)t /N
=> - dLi(t)/dt = i Li(t) N
Li(0) = i (1-pi )
Li(D) = i (1-2pi )
• This first order differential equation can be solved explicitly for Li(t), 0 < t < D
25
Simulation Comparison: 1UDP, 32 TCPs
0
50
100
150
200
250
300
350
0.1 1 10Arrival Rate
Thr
ough
put
fluid model
CHOKe ns simulation
26
Fluid Analysis of Multiple Samples
• With M samples
Li(t)t - Li(t +t)t = Mi Li(t)t /N
=> - dLi(t)/dt = Mi Li(t) N
Li(0) = i (1-pi )M
Li(D) = i (1-pi )M - Mi pi
27
Comparison: 1 UDP, 2 Samples
0
20
40
60
80
100
120
140
0 0.5 1 1.5 2UDP Arrival Rate(Mbps)
UD
P T
hrou
ghpu
t(K
bps)
NS SimulationFluid Model
28
Size-based Schemes – drop decision based on the size of FIFO queue– e.g. RED
History-based Schemes– keep a history of packet arrivals/drops to guide drop decision– e.g. SRED, RED with penalty box
Content-based Schemes – drop decision based on the current content of the FIFO queue – e.g. CHOKe
Overview of packet dropping schemes
Unfortunately, while the above are simple, they can’t perform like WFQ in terms of accurate bandwidth partitioning– need more information to drop packets better AFD: Approximate Fair Dropping
29
• Track the last N arriving packets
• Of these, let mi come from flow i– note: we’re tracking all packets sent, not just those admitted
• Use this to drop further flow i packets fairly– that is, when a flow i packet arrives, find Di such that
mi (1-Di ) = mfair (fair share)
• if Di is positive, drop incoming packet with probability Di
• else, just admit packet
Main idea of AFD
30
• The fair share is estimated dynamically by looking at the size of the queue
– mfair = mfair - a*(Qlen– Qref ) • Qlen is the real queue length (measured)• Qref is the reference queue length (set by the operator)• a is the averaging parameter (a design parameter), could be self adjusting
Main idea of AFD (cont’d)
31
• How to efficiently track mi
– If the number of flows is small (in the order of thousands): directly measure
– Otherwise: (the number of flows is in the order of millions) use a “flow table” which has summary information
Key design issue
32
Fraction of Flows
• State requirement on the order of # of large flows
Flow table: How many flows to track?
33
4 1
2 4
Data Buffer
Flow Table: N=115 1
2 4
Need to decrement so that mi accurately estimates flow arrival rate -- simply decrementing a random counter won’t work -- too much bias against large flows
Di
Flow table
34
• Choose a flow randomly from the flow table– Prob(flow i chosen) = 1/Nf (Nf : # of flows)
• Once a flow is chosen, decrement it multiple times proportionally to its count– Nd= b*mi
Decrementing
35
All TCP’s maximum window size = 300 FIFO buffer size = 300 packets All packets sizes = 1 Kbyte
(variable packet sizes also easy to implement) N = 500, b = 0.06
AFD performance
7 groups with 5 flows in each:
3 groups with different aimd parameters:
1.0/0.9, 0.75/0.30, 2.0/0.5
2 groups with different binomial parameters
1 group with long RTT 70ms
1 group of normal TCP (1.0/0.5)
36
0
100
200
300
400
500
RED AFD-FT
Thr
ough
put (
kbps
)
37
100
150
200
250
300
350
400
100 200 300 400 500 600
Simulation T ime (Sec)
Th
rou
gh
pu
t (K
bp
s)
Group1 Group2Group3 Group4Group5 Group6Group7
Throughput vs time
38
Drop Probabilities(note differential dropping)
0
0.05
0.1
0.15
0.2
RED AFD-FT
Dro
p P
roba
bili
ty