1. 1 TCP Congestion Control

2. 2 TCP Segment Structure source port # dest port # 32 bits application data (variable length) sequence number acknowledgement number rcvr window size ptr urgent data checksum F SR PAU head len not used Options (variable length) RST, SYN, FIN: connection management (reset, setup teardown commands) # bytes rcvr willing to accept ACK: ACK # valid counting by bytes of data (not segments!) Also in UDP URG: urgent data (generally not used) PSH: push data now (generally not used)

3. 3 TCP Flow Control receiver: explicitly informs sender of (dynamically changing) amount of free buffer space  RcvWindow field in TCP segment sender: keeps the amount of transmitted, unACKed data less than the most recently received RcvWindow sender won’t overrun receiver’s buffers by transmitting too much, too fast flow control receiver buffering RcvBuffer = size of TCP Receive Buffer RcvWindow = amount of spare room in Buffer Questions: 1.What is the maximum size of RcvBuffer? 2. Can sender estimate the size of RcvBuffer? 3. Can receiver change its RcvBuffer size in the middle of a session? 4. Can Sender know the change?

4. 4 Outline  Principle of congestion control  TCP/Reno congestion control

5. 5 Principles of Congestion Control Big picture:  How to determine a flow’s sending rate? Congestion:  informally: “too many sources sending too much data too fast for the network to handle”  different from flow control!  manifestations:  lost packets (buffer overflow at routers)  wasted bandwidth  long delays (queueing in router buffers)  a top-10 problem!

6. 6 History  TCP congestion control in mid-1980s  fixed window size w  timeout value = 2 RTT  Congestion collapse in the mid-1980s  UCB  LBL throughput dropped by 1000X!

7. 7 Some General Questions  How can congestion happen?  What is congestion control?  Why is congestion control difficult?  Will congestion disappear in the future due to technology advances (e.g. faster links, routers)?  How does TCP provide congestion control?

8. 8 flow 2 (5 Mbps) flow 1 router 1router 2 10 Mbps 5 Mbps 20 Mbps Cause/Cost of Congestion: Scenario 1  Flow 2 has a fixed sending rate of 5 Mbps  We vary the sending rate of flow 1 from 0 to 20 Mbps  Assume  No retransmission  The link from router 1 to router 2 has infinite buffer  Throughput: packets go through 10 Mbps 20 Mbps sending rate by flow 1 (Mbps) Total throughput of flow 1 & 2 (Mbps) 5 10 sending rate by flow 1 (Mbps) Delay at link 1 5 5  maximum achievable throughput  large delays when congested 0 0 delay due to randomness

9. 9 flow 2 (5 Mbps) flow 1 router 1 10 Mbps 5 Mbps 20 Mbps Cause/Cost of Congestion: Scenario 2  Assume  No retransmission  The link from router 1 to router 2 has finite buffer  Throughput: packets go through 5 Mbps sending rate by flow 1 (Mbps) Total throughput of flow 1 & 2 (Mbps) 5 10 5  when packet dropped at the link from router 2 to router 6, the upstream transmission from router 1 to router 2 used for that packet was wasted! 0 router 3 router 4 router 2 router 5 router 6 What if retransmission?

10. 10 Summary: The Cost of Congestion Cost  High delay  Packet loss  Wasted upstream bandwidth when a pkt is discarded at downstream  Wasted bandwidth due to retransmission (a pkt goes through a link multiple times) Load Delay Throughput kneecliff congestion collapse packet loss

11. 11 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 Two broad approaches towards congestion control:

12. 12 Open-loop vs. Closed-loop Open-loop:  A flow does not adjust its sending rate dynamically according to the status of the network  Need reservation to avoid congestion collapse Closed-loop:  A flow adjusts its rate dynamically according to the status of the network

13. 13 End-to-end vs. Hop-by-hop End-to-end congestion control:  A flow determines its rate Hop-by-hop:  Routers on the path implement flow control between each other  e.g. ATM credit-based  Scheduling for flows at a link

14. 14 Implicit vs. Explicit Implicit:  congestion inferred by end systems through observed loss, delay Explicit:  routers provide feedback to end systems  explicit rate sender should send at  single bit indicating congestion (SNA, DECbit, TCP ECN, ATM)

15. 15 Window-based:  Congestion control by controlling the window size of a transport scheme, e.g. set window size to 64KBytes  Example: TCP Rate-based:  Congestion control by explicitly controlling the sending rate of a flow, e.g. set sending rate to 128Kbps  Example: ATM Rate-based vs. Window-based

16. 16 Self-Clocking of Window-based Schemes

17. 17 Outline  TCP Overview  Principle of congestion control  TCP/Reno congestion control

18. 18 TCP Congestion Control  Closed-loop, end-to-end, implicit, window-based congestion control  Transmission rate limited by congestion window size, cwnd, over segments:  w segments, each with MSS bytes sent in one RTT: throughput  w * MSS RTT Bytes/sec cwnd

19. 19 TCP Congestion Control: Basic Question  Ideally, we want to set the window size (approximately) to the product of available bandwidth (for this flow) and round-trip delay  However,  We don’t know these parameters at the beginning of a flow  Further, the available bandwidth and round-trip are changing, because of  competing flows

20. 20 TCP Congestion Control: Basic Structure  Two “phases”  SlowStart  congestion avoidance (AIMD)  Important variables:  cwnd: congestion window size  ssthresh: threshold between the slow-start phase and the congestion avoidance phase  Many versions of TCP  TCP/Tahoe: this is a less optimized version  TCP/Reno: this is what we are talking about today; most OSs today implement TCP/Reno  TCP/Vegas: currently not used

21. 21 TCP Congestion Control Implementation Initially: cwnd = 1; ssthresh = infinite (64K); For each newly ACKed segment: if (cwnd < ssthresh) /* slow start*/ cwnd = cwnd + 1; else /* congestion avoidance; cwnd increases by 1 per RTT */ cwnd += 1/cwnd; Triple-duplicate ACKs: /* multiplicative decrease */ cwnd = ssthresh = cwnd/2; Timeout: ssthresh = cwnd/2; cwnd = 1;

22. 22 TCP AIMD  AIMD [Jacobson 1988]: Additive Increase : In every RTT W = W + 1*MSS Multiplicative Decrease : Upon a congestion event W = W/2 Sender Receiver TCP Acknowledgment Packets 0 Time Congestion Window Size AI MD 1 RTT Data Packets Network

23. 23 TCP Slow Start  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  When connection begins, increase rate exponentially fast until first loss event  double CongWin every RTT  done by incrementing CongWin for every ACK received  Why call it slowstart: initial rate is slow but ramps up exponentially fast

24. 24 TCP Slow-start ACK for segment 1 segment 1 cwnd = 1 cwnd = 2 segment 2 segment 3 ACK for segments 2 + 3 cwnd = 4 segment 4 segment 5 segment 6 segment 7 cwnd = 6 Initially: cwnd = 1; ssthresh = infinite (64K); For each newly ACKed segment: if (cwnd < ssthresh) /* slow start*/ cwnd = cwnd + 1; Timeout or Triple Duplicate ACKs: /*slowstart stops*/ cwnd = 8

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

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

27. 27 TCP/Reno: Big Picture Time cwnd slow start congestion avoidance TD TD: Triple duplicate acknowledgements TO: Timeout TO ssthresh congestion avoidance TD congestion avoidance slow start congestion avoidance

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