1. Chapter 6 TCP Congestion Control
Networking
CS 3470, Section 1

2. TCP Congestion Control
TCP congestion control introduced into the Internet in the late 1980s
Roughly eight years after the TCP/IP protocol stack had become operational

3. TCP Congestion Control
Immediately preceding late 1980s, the Internet was suffering from congestion collapse—
hosts would send their packets into the Internet as fast as the advertised window would allow
congestion would occur at some router (causing drops)
and the hosts would time out and retransmit their packets, resulting in even more congestion

4. TCP Congestion Control
Informally: “too many sources sending too much data too fast for network to handle”
Different from flow control!
Manifestations:
Lost packets (buffer overflow at routers)
Long delays (queueing in router buffers)
a top-10 problem!

5. TCP Congestion Control
A Congestion Window called CongWin is used by the source to limit how much data it is allowed to have in transit at a given time.
The congestion window is congestion control’s counterpart to flow control’s advertised window.

6. TCP Congestion Control
Once a given source has CongWin packets in transit, an ACK arrival signals that one of its packets has left the network
Then it is safe to insert a new packet into the network without adding to the level of congestion
By using ACKs to pace the transmission of packets, TCP is said to be self-clocking.

7. TCP Congestion Control
We now modify TCP’s effective window
MaxWindow = MIN(CongestionWindow, AdvertisedWindow)
EffectiveWindow = MaxWindow − (LastByteSent − LastByteAcked)
That is, MaxWindow replaces AdvertisedWindow in the calculation of EffectiveWindow.

8. TCP Congestion Control
If CongWin < AdvertisedWindow, then the rate of the connection is
CongWin is dynamic, function of perceived network congestion
rate =
CongWin
RTT
Bytes/sec

9. TCP Congestion Control
Great, so how does the sender perceive congestion?
Loss event = timeout or 3 duplicate ACKs
TCP sender reduces rate (CongWin) after loss event

10. TCP Congestion Control
Three mechanisms make up TCP congestion control:
Additive Increase/Multiplicative Decrease (AIMD)
Slow Start
Fast Retransmit and Fast Recovery

11. TCP AIMD Multiplicative Decrease: Additive increase:
Cut CongWin in half after loss event
Additive increase:
Increase CongWin by 1 MSS every RTT in the absence of loss events: probing
Long-lived TCP connection

12. TCP AIMD
Packets in transit during additive increase, with one packet being added each RTT.

13. TCP Slow Start When connection begins, CongWin = 1MSS
Example: MSS=500 bytes and RTT = 200 msec
Initial rate = 20 Kbps
Available bandwidth may be much greater than MSS/RTT
Desirable to quickly ramp up to respectable rate
When connection begins, increase rate exponentially fast until first loss event

14. TCP Slow Start (more)
When connection begins, increase rate exponentially until first loss event:
double CongWin every RTT
done by incrementing CongWin for every ACK received
Summary: initial rate is slow but ramps up exponentially fast
Host A
Host B
one segment
RTT
two segments
four segments
time

15. Fast Recovery After 3 dup ACKs: But after timeout event:
Philosophy:
3 dup ACKs indicates network capable of delivering some segments
timeout before 3 dup ACKs is “more alarming”
After 3 dup ACKs:
CongWin is cut in half
window then grows linearly
But after timeout event:
CongWin instead set to 1 MSS;
window then grows exponentially
to a threshold, then grows linearly

16. Fast Recovery
Q: When should the exponential increase switch to linear?
A: When CongWin gets to 1/2 of its value before timeout.
Implementation:
Variable Threshold
At loss event, Threshold is set to 1/2 of CongWin just before loss event
Congestion window

17. Summary: TCP Congestion Control
When CongWin is below Threshold, sender in slow- start phase, window grows exponentially.
When CongWin is above Threshold, sender is in congestion-avoidance phase, window grows linearly.
When a triple duplicate ACK occurs, Threshold set to CongWin/2 and CongWin set to Threshold.
When timeout occurs, Threshold set to CongWin/2 and CongWin is set to 1 MSS.

18. TCP sender congestion control
CongWin and Threshold not changed
Increment duplicate ACK count for segment being acked
SS or CA
Duplicate ACK
Enter slow start
Threshold = CongWin/2,
CongWin = 1 MSS,
Set state to “Slow Start”
Timeout
Fast recovery, implementing multiplicative decrease. CongWin will not drop below 1 MSS.
CongWin = Threshold,
Set state to “Congestion Avoidance”
Loss event detected by triple duplicate ACK
Additive increase, resulting in increase of CongWin by 1 MSS every RTT
CongWin = CongWin+MSS * (MSS/CongWin)
Congestion
Avoidance (CA)
ACK receipt for previously unacked data
Resulting in a doubling of CongWin every RTT
CongWin = CongWin + MSS,
If (CongWin > Threshold)
set state to “Congestion Avoidance”
Slow Start (SS)
Commentary
TCP Sender Action
State
Event

19. TCP throughput
What’s the average throughput of TCP as a function of window size and RTT?
Ignore slow start – these phases are typically short
Let W be the window size right before loss occurs.
When window is W, throughput is W/RTT
So fast, but cannot last
Just after loss, window drops to W/2, throughput to W/2RTT.
Average throughput: .75 W/RTT

20. TCP Fairness
Fairness goal: if K TCP sessions share same bottleneck link of bandwidth R, each should have average rate of R/K
TCP connection 1
bottleneck
router
capacity R
TCP
connection 2

21. Why is TCP fair? Two competing sessions:
Additive increase gives slope of 1, as throughput increases
multiplicative decrease decreases throughput proportionally
Connection 2 throughput R
equal bandwidth share
loss: decrease window by factor of 2
congestion avoidance: additive increase
loss: decrease window by factor of 2
congestion avoidance: additive increase
Connection 1 throughput R
Assumptions: same MSS and RTT, nothing else using link

22. Fairness (more) Fairness and UDP Multimedia apps often do not use TCP
do not want rate throttled by congestion control
Instead use UDP:
pump audio/video at constant rate, tolerate packet loss
Research area: congestion control for UDP
Fairness and parallel TCP connections
nothing prevents app from opening parallel connections between 2 hosts.
Web browsers do this
Example: link of rate R supporting 9 connections;
new app asks for 1 TCP, gets rate R/10
new app asks for 11 TCPs, gets R/2 !