1. CS-1652 Jack Lange University of Pittsburgh
The slides are adapted from the publisher’s material
All material copyright
J.F Kurose and K.W. Ross, All Rights Reserved

2. Principles of Congestion Control

3. Principles of 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!
Transport Layer

4. Causes/costs of congestion: scenario 1
unlimited shared output link buffers
Host A
lin : original data
Host B
lout
two senders, two receivers
one router, infinite buffers
no retransmission
large delays when congested
maximum achievable throughput
Transport Layer

5. Causes/costs of congestion: scenario 2
one router, finite buffers
sender retransmission of lost packet
Network traffic includes retransmissions (l'in > lin)
Host A
lout
lin : original data
l'in : original data, plus retransmitted data
Host B
finite shared output link buffers
Transport Layer

6. Causes/costs of congestion: scenario 2
lout
lin
idealization: perfect knowledge
sender sends only when router buffers available
lin : original data
lout
copy
l'in: original data, plus retransmitted data A
free buffer space!
finite shared output link buffers
Host B
Transport Layer

7. Causes/costs of congestion: scenario 2
Idealization: known loss packets can be lost, dropped at router due to full buffers
sender only resends if packet known to be lost
lin : original data
lout
copy
l'in: original data, plus retransmitted data A
no buffer space!
Host B
Transport Layer

8. Causes/costs of congestion: scenario 2
Idealization: known loss packets can be lost, dropped at router due to full buffers
sender only resends if packet known to be lost
R/2
lin
lout
when sending at R/2, some packets are retransmissions but asymptotic goodput is still R/2 (why?)
lin : original data
lout
l'in: original data, plus retransmitted data A
free buffer space!
Host B
Transport Layer

9. Causes/costs of congestion: scenario 2
Realistic: duplicates
packets can be lost, dropped at router due to full buffers
sender times out prematurely, sending two copies, both of which are delivered
R/2
when sending at R/2, some packets are retransmissions including duplicated that are delivered!
lout
lin
R/2
timeout
lin
lout
copy
l'in A
free buffer space!
Host B
Transport Layer

10. Causes/costs of congestion: scenario 2
Realistic: duplicates
packets can be lost, dropped at router due to full buffers
sender times out prematurely, sending two copies, both of which are delivered
R/2
when sending at R/2, some packets are retransmissions including duplicated that are delivered!
lout
lin
R/2
“costs” of congestion:
more work (retrans) for given “goodput”
unneeded retransmissions: link carries multiple copies of pkt
decreasing goodput
Transport Layer

11. Causes/costs of congestion: scenario 3
Q: what happens as lin and lin’increase?
four senders
multihop paths
timeout/retransmit
A: as red lin’ increases, all arriving blue pkts at upper queue are dropped, blue throughput g 0
Host A
lout
lin : original data
Host B
l'in: original data, plus retransmitted data
finite shared output link buffers
Host D
Host C
Transport Layer

12. Causes/costs of congestion: scenario 3
Host A
lout
Host B
Another “cost” of congestion:
when packet dropped, any “upstream transmission capacity used for that packet was wasted!
Transport Layer

13. Approaches towards congestion control
Two broad approaches towards congestion control:
End-end congestion control:
no explicit feedback from network
congestion inferred from end-system observed loss, delay
approach taken by TCP
Network-assisted congestion control:
routers provide feedback to end systems
single bit indicating congestion (SNA, DECbit, TCP/IP ECN, ATM)
explicit rate sender should send at
Transport Layer

14. Explicit Congestion Notification (ECN)
network-assisted congestion control:
two bits in IP header (ToS field) marked by network router to indicate congestion
congestion indication carried to receiving host
receiver (seeing congestion indication in IP datagram) ) sets ECE bit on receiver-to-sender ACK segment to notify sender of congestion
TCP ACK segment
source
destination
application
transport
network
link
physical
application
transport
network
link
physical
ECE=1
ECN=11
ECN=11
ECN=00
IP datagram
Transport Layer

15. TCP Congestion Control

16. TCP congestion control: additive increase multiplicative decrease
approach: sender increases transmission rate (window size), probing for usable bandwidth, until loss occurs
additive increase: increase CongWin by 1 MSS every RTT until loss detected
multiplicative decrease: cut CongWin in half after loss
additively increase window size …
…. until loss occurs (then cut window in half)
AIMD saw tooth
behavior: probing
for bandwidth
congestion window size
cwnd: TCP sender
time
Transport Layer

17. TCP Congestion Control: details
sender limits transmission:
Roughly:
send CongWin bytes, wait RTT for ACKS, then send more bytes
CongWin is dynamic, function of perceived network congestion
How does sender perceive congestion?
loss event = timeout or 3 duplicate acks
TCP sender reduces rate (CongWin) after loss event
three mechanisms:
AIMD
slow start
conservative after timeout events
LastByteSent - LastByteAcked  CongWin
rate =
CongWin
RTT
Bytes/sec
Why is congwin not in the packet headers?
Transport Layer

18. TCP Slow Start
Increase rate exponentially fast until first loss event or CongWin reaches ss-thresh
Loss
3 dup ACKs
Timeout
ssthresh – cwnd size at last congestion
When connection begins, CongWin = 1 MSS
Example: MSS = 500 bytes & RTT = 200 msec
initial rate = 20 kbps
available bandwidth may be
>> MSS/RTT
desirable to quickly ramp up to respectable rate
(500 / .2 ) * 8 = 20kbps
Why are timeouts and duplicate acks treated differently?
Transport Layer

19. TCP Slow Start
Host A
Host B
when connection begins, increase rate exponentially until first loss event:
Initially:
CongWin = 1 MSS
every RTT:
CongWin = 2 * CongWin
done by incrementing CongWin for every ACK received
summary: initial rate is slow but ramps up exponentially fast
one segment
RTT
two segments
four segments
time
Transport Layer

20. Refinement: inferring loss
Philosophy:
TCP RENO
After 3 dup ACKs:
CongWin = CongWin / 2
window then grows linearly
But after timeout event:
CongWin = 1
window then grows exponentially
to a threshold, then grows linearly
TCP TAHOE
After 3 dup ACKs OR a timeout event:
3 dup ACKs indicates network capable of delivering some segments
timeout indicates a “more alarming” congestion scenario
Transport Layer

21. TCP: switching from slow start to CA
Q: when should the exponential increase switch to linear?
A: when cwnd gets to 1/2 of its value before timeout.
Implementation:
variable ssthresh
on loss event, ssthresh is set to 1/2 of cwnd just before loss event
Transport Layer

22. Summary: TCP Congestion Control
New
ACK!
congestion
avoidance
cwnd = cwnd + MSS (MSS/cwnd)
dupACKcount = 0
transmit new segment(s), as allowed
new ACK .
dupACKcount++
duplicate ACK
slow
start
timeout
ssthresh = cwnd/2
cwnd = 1 MSS
dupACKcount = 0
retransmit missing segment
cwnd = cwnd+MSS
transmit new segment(s), as allowed
new ACK
dupACKcount++
duplicate ACK L
ssthresh = 64 KB L
cwnd > ssthresh
timeout
ssthresh = cwnd/2
cwnd = 1 MSS
dupACKcount = 0
retransmit missing segment
ssthresh= cwnd/2
cwnd = ssthresh + 3
retransmit missing segment
dupACKcount == 3
timeout
ssthresh = cwnd/2
cwnd = 1
dupACKcount = 0
cwnd = ssthresh
dupACKcount = 0
New ACK
ssthresh= cwnd/2
cwnd = ssthresh + 3
retransmit missing segment
dupACKcount == 3
fast
recovery
cwnd = cwnd + MSS
transmit new segment(s), as allowed
duplicate ACK
Transport Layer

23. 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.
Transport Layer

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

25. TCP throughput avg. TCP thruput as function of window size, RTT?
ignore slow start, assume always data to send
W: window size (measured in bytes) where loss occurs
avg. window size (# in-flight bytes) is ¾ W
avg. throughput is 3/4W per RTT
avg TCP thruput = 3 4 W
RTT
bytes/sec W
W/2
Transport Layer

26. TCP Futures: TCP over “long, fat pipes”
example: 1500 byte segments, 100ms RTT, want 10 Gbps throughput
requires W = 83,333 in-flight segments
throughput in terms of segment loss probability, L [Mathis 1997]:
➜ to achieve 10 Gbps throughput, need a loss rate of L = 2· – a very small loss rate!
new versions of TCP for high-speed
TCP throughput =
1.22 .
MSS
RTT L
Transport Layer

27. 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
Transport Layer

28. Why is TCP fair? Two competing sessions:
Additive increase gives slope of 1, as throughout increases
multiplicative decrease decreases throughput proportionally R
equal bandwidth share
loss: decrease window by factor of 2
congestion avoidance: additive increase
Connection 2 throughput
What is capacity?
What is the equal share?
loss: decrease window by factor of 2
congestion avoidance: additive increase
Connection 1 throughput R
Transport Layer

29. Fairness (more) Fairness and parallel TCP connections Fairness and UDP
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 !
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: TCP friendly
Transport Layer

30. Chapter 3: Summary principles behind transport layer services:
multiplexing, demultiplexing
reliable data transfer
flow control
congestion control
instantiation and implementation in the Internet
UDP
TCP
Next:
leaving the network “edge” (application, transport layers)
into the network “core”
Transport Layer