Transcript Document

Congestion Avoidance
Created by
M Bateman, A Ruddle & C Allison
As part of the TCP View project
Congestion Avoidance
• Congestion control: reduce sending rate after bottleneck
link is congested and its packet buffers overflow
• Congestion avoidance: reduce sending rate when
bottleneck link is saturated, but before a queue builds up at
the packet buffers
• TCP Tahoe/Reno do congestion control, not avoidance
• Comparison of congestion control and avoidance
• Suppose a “congestion control” connection competes for
network bandwidth with a “congestion avoidance”
connection. Who would get more bandwidth?
• What is better for the network: avoidance or control?
The DECbit Approach
• Developed for Digital Network Architecture (DNA) in late 80’s
• Packets carry “Congestion Experienced” (CE) bit in their header
• Routers set the CE flag when they have an average queue size of at
least one packet
–
–
–
–
When would a router have a positive average queue size?
Why monitor average instead of instantaneous queue?
How can we estimate the average queue size?
Why wait for an average queue of at least one packet?
• Receivers return the CE bit to the sources using their ACKs
• Sources monitor fraction of packets that have CE bit set
• If more than 50% of packets have seen CE=1, sources reduces sending
window by certain fraction; otherwise, the window is increased by a
packet (AIMD)
• Note: this approach requires some support by the routers
Average queue estimation
• What do we mean by “busy period” for a link?
• Average instantaneous queue size over last busy
period, plus current busy period
• Why to include the last busy period?
Queue length
Current
time
Previous
cycle
Averaging
interval
Current
cycle
Time
Random Early Detection
• Designed for use with TCP’s congestion control algorithms
• Similar objectives with DECbit, but routers send implicit
feedback to sources, by dropping packets early, instead of
setting a special bit
• “Early drop” means that router starts dropping packets
before its buffers overflow, at the early onset of congestion
– Specifically, RED drops packets probabilistically, based on
relation of average queue size AvgLen to queuing MinThreshold
and MaxThreshold
– If AvgLen < MinThreshold, enqueue arriving packet
– If MinThreshold < AvgLen <MaxThreshold,
• Calculate probability P
• Drop arriving packet with probability P
– If MaxThreshold < AvgLen, drop arriving packet
Queue size estimation
• First-order weighted running average:
– AvgLen = (1-weight) * AvgLen + weight * SampleLen
– Weight is normally around 0.1 (and often a negative
power of two)
– How often should we sample the queue size?
– What if packets have not arrived for a while?
Queue length
Instantaneous
Average
Time
Queue thresholds in RED
• Objective: maintain an average queue size
between Min-to-MaxThreshold
– How does this compare to DEC’s “at-least-one-packet
on the average” scheme
– Trade-offs in selecting these two thresholds
– How large should the total buffer space be?
MaxThreshold
MinThreshold
AvgLen
Drop Probability in RED
• Why to drop packets probabilistically?
• What is the relation between the number of
dropped packets and the throughput of a
connection?
P(drop)
1.0
MaxP
AvgLen
MinT hresh
MaxThresh
Source based congestion control
• What if we don’t have any support from routers?
– Source-based solutions
• Basic idea: sources watch for some sign from the
network that congestion will soon happen
• Different ways to do this:
– Reduce sending rate upon gradual increase of the
Round-Trip Times
– Increase or decrease window based on sign of :
• (LastWindow-PrevWindow) * (LastRTT-PrevRTT)
– Decrease window when sending rate starts flattening
out, even though window has been increasing
– Compare expected throughput and measured
throughput (used in TCP Vegas)
Queue size in router
Sending KBps
KB
Basic idea of TCP Vegas
70
60
50
40
30
20
10
0.5
1.0 1.5
2.0
2.5 3.0
3.5 4.0 4.5
T ime (seconds)
5.0
5.5
6.0
6.5
7.0 7.5
8.0 8.5
0.5
1.0 1.5
2.0
2.5 3.0
3.5 4.0 4.5
T ime (seconds)
5.0
5.5
6.0
6.5
7.0 7.5
8.0 8.5
0.5
1.0 1.5
2.0
2.5 3.0
3.5 4.0 4.5
T ime (seconds)
5.0
5.5
6.0
6.5
7.0 7.5
8.0 8.5
1100
900
700
500
300
100
10
5
TCP Vegas
• BaseRTT: minimum of all measured RTTs
• ExpectedRate = CongestionWindow/ BaseRTT
• ActualRate = UnAckedBytes / LastRTT
– Measured once per RTT at sender
• Diff = ExpectedRate – ActualRate
– If Diff > X, decrease congestion window
– If Diff < Y, increase congestion window
– How would you choose the thresholds X and Y?
• How does TCP Vegas compare with TCP Reno?
– Would you prefer to use TCP Vegas if everyone else
uses Reno?
– Would it be fair to use TCP Reno if everyone else uses
Vegas?