Chapter 6 TCP Congestion Control

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 • Congestion: • 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. CongWin rate = Bytes/sec RTT TCP Congestion Control • If CongWin < AdvertisedWindow, then the rate of the connection is • CongWin is dynamic, function of perceived network congestion

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: • 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. Starting data transfer • Should TCP just starting blasting away at the EffectiveWindow pace on each new connection? • Probably not…we don’t know how congested the network is • But we don’t want to take forever to get up to a good pace…

14. 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

15. time 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

16. Philosophy: • 3 dup ACKs indicates network capable of delivering some segments • timeout before 3 dup ACKs is “more alarming” Fast Recovery • 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

17. 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

18. 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.

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

20. 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

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

22. Why is TCP fair? Two competing sessions: • Additive increase gives slope of 1, as throughput increases • multiplicative decrease decreases throughput proportionally Connection 2 throughput equal bandwidth share R 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

23. 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 !