TCP Congestion Control
TCP TahoeTCP RenoTCP Vegas
Internet Congestion Collapse In the late 80s, the Internet suffered a
congestion collapse
Host
Host
Host
Congestion!Packet drops!!
Data+ Retransmissions
More Drops!!!
Collapse
Why is Today’s Topic Important?
The algorithm for TCP congestion control is the main reason we can
use the Internet successfully today despite largely unpredictable user
access patterns and despite resource bottlenecks and
limitations. Without TCP congestion control, the Internet could have become history a long time ago.
Resource Management Solutions
Handling congestion pre-allocate resources so as to avoid congestion control congestion if (and when) is occurs
Two points of implementation routers inside the network (queuing discipline) hosts at the edges of the network (transport protocol)
Destination1.5-Mbps T1 link
Router
Source2
Source1
100-Mbps FDDI
10-Mbps Ethernet
Detecting Congestion Packet drops indicate congestion
Is that really true? Why does it work?
Src Dst
Packet
Ack
Drop
Timeout! No Ack =
Congestion!
Controlling Congestion – The Effect of Window Size
Note that sender’s window is equal to the number of sender packets in flight (in the network). Why?
A Window’s worth of packets
X acks
Window
X more packets
Source Destination
Controlling Congestion Reduce window less packets in
the network Increase window more packets in
the network Idea: Concept of a congestion
window – window is smaller when congestion is larger and vice versa
Additive Increase, Multiplicative Decrease
Each time a packet drop occurs, slash window size in half (multiplicative decrease) Multiplicative decrease is necessary to
avoid congestion When no losses are observed,
gradually increase window size (additive increase)
AIMD (cont)
In practice: increment a little for each ACKIncrement = (MSS*MSS)/CongestionWindow
CongestionWindow += Increment
Source Destination
…
Algorithm increment CongestionWindow by
one packet per RTT (linear increase)
divide CongestionWindow by two whenever a timeout occurs (multiplicative decrease)
AIMD (cont) Trace: sawtooth behavior
60
20
1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0
KB
Time (seconds)
70
304050
10
10.0
Problems What should the window size be
Initially? Upon packet loss and timeout?
Pessimistic window size? (e.g., 1) Additive increase is too slow in ramping
up window size – short connections will not fully utilize available bandwidth
Optimistic window size? Large initial burst may cause router
queue overflow
Slow Start
Objective: determine the available capacity quickly
Idea: Use CongestionThreshold as an
optimistic CongestionWindow estimate begin with CongestionWindow = 1
packet double CongestionWindow each RTT
(increment by 1 packet for each ACK)
When CongestionThreshold is crossed, use additive increase
Source Destination
…
Fast Retransmit Problem: coarse-grain TCP
timeouts lead to idle periods Fast retransmit:
Send an ack on every packet reception
Send duplicate of last ack when a packet is received out of order
Use duplicate ACKs to trigger retransmission
Packet 1
Packet 2
Packet 3
Packet 4
Packet 5
Packet 6
Retransmitpacket 3
ACK 1
ACK 2
ACK 2
ACK 2
ACK 6
ACK 2
Sender Receiver
Self Clocking and Slow Start Each packet’s transmission is “clocked” by an ACK –
no bursts develop
W=1 W=2 W=4 W=5 W=6 W=7
Slow Start
…
Self Clocking in Operation Each packet’s transmission is “clocked” by an ACK –
no bursts develop
W=32
……
Self Clocking Interrupted During timeouts, ACKs are drained from the network.
Self clocking is interrupted. Next transmission causes a burst. Hence, slow start!
W=32
……Lost
Timeout
Retransmission
Ack32
16 packet burst
Cut window in 1/2
ACKsDrained!!
Self Clocking and Fast Retransmit / Fast Recovery
When fast retransmit is used, the packet is retransmitted before all ACKs are drained. Slow start is not needed
W=32
……Lost
FastRetransmission
Cut window in 1/2
TCP Vegas Uses congestion avoidance instead
of congestion control Vegas: Congestion avoidance: Predict
and avoid congestion before it occurs Tahoe, Reno: Congestion control:
React to congestion after it occurs Question: How to predict
congestion?
TCP Vegas
Idea: source watches for some sign that router’s queue is building up and congestion will happen too; e.g., RTT grows sending rate
flattens
60
20
0.5 1.0 1.5 4.0 4.5 6.5 8.0
KB
Time (seconds)
Time (seconds)
70
304050
10
2.0 2.5 3.0 3.5 5.0 5.5 6.0 7.0 7.5 8.5
900
300100
0.5 1.0 1.5 4.0 4.5 6.5 8.0
Sen
ding
KB
ps
1100
500700
2.0 2.5 3.0 3.5 5.0 5.5 6.0 7.0 7.5 8.5
Time (seconds)0.5 1.0 1.5 4.0 4.5 6.5 8.0Q
ueue
siz
e in
rou
ter
5
10
2.0 2.5 3.0 3.5 5.0 5.5 6.0 7.0 7.5 8.5
Observation Packet accumulation in the network can be
inferred by monitoring RTT and sending rate
Bottleneck LinkOverloadedRouter
Sending Rate
cwnd
Sending Rate = cwnd / RTT
Algorithm
Let BaseRTT be the minimum of all measured RTTs (commonly the RTT of the first packet)
If not overflowing the connection, thenExpectRate = CongestionWindow/BaseRTT
Source calculates ActualRate once per RTT Source compares ActualRate with ExpectRate
Diff = ExpectedRate - ActualRateif Diff <
increase CongestionWindow linearlyelse if Diff >
decrease CongestionWindow linearlyelse
leave CongestionWindow unchanged
Algorithm (cont)
Parameters = 1 packet = 3 packets
70605040302010
KB
Time (seconds)
0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 5.0 5.5 6.0 6.5 7.0 7.5 8.0
0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 5.0 5.5 6.0 6.5 7.0 7.5 8.0
CA
M K
Bps
240200160120
8040
Time (seconds)