1. EE 122: Congestion Control and Avoidance Kevin Lai October 23, 2002

2. laik@cs.berkeley.edu2 Problem  At what rate do you send data?  flow control -make sure that the receiver can receive -sliding-window based flow control: receiver reports window size to sender higher window  higher throughput throughput = wnd/RTT  congestion control -make sure that the network can deliver

3. laik@cs.berkeley.edu3 Solutions  Everyone sends as fast as they can -excess gets dropped -very bad idea: leads to congestion collapse  Reserve bandwidth -low utilization -never have packet drops, queueing delays  Congestion control and avoidance -high utilization -occasionally have packet drops, queueing delays

4. laik@cs.berkeley.edu4 Non-decreasing Efficiency under Load  Efficiency = useful_work/time  critical property of system design -network technology, protocol or application  otherwise, system collapses exactly when most demand for its operation  trade lower overall efficiency for this? Load Efficiency knee cliff ok?good

5. laik@cs.berkeley.edu5 Congestion Collapse  Decrease of network efficiency under load -efficiency = utilization of bandwidth  Waste resources on useless or undelivered data  Network layer -load  drops,  1 fragment dropped  Transport layer -retransmit too many times -no congestion control / avoidance

6. laik@cs.berkeley.edu6 Transport Layer Congestion Collapse 1  network is congested (a router drops packets)  the receiver didn’t get a packet  sender waits, but not long enough -timeout too short,  retransmit again -adds to congestion, increases likelihood that retransmission will be dropped, or delayed  rinse, repeat  assume that everyone is doing the same  network will become more and more congested -with duplicate packets rather than new packets  Solution: fix timeout (previous lecture)

7. laik@cs.berkeley.edu7 Transport Layer Congestion Collapse 2  Waste resources on undelivered data  A flow sends data at a high rate despite loss  Its packets consume bandwidth at earlier links, only to be dropped at a later link 90% loss bw wasted ignores loss Penalized

8. laik@cs.berkeley.edu8 Congestion Collapse and Efficiency  knee – point after which -throughput increases slowly -delay increases quickly  cliff – point after which -throughput decreases quickly to zero (congestion collapse) -delay goes to infinity  Congestion avoidance -stay at knee  Congestion control -stay left of (but usually close to) cliff Load Throughput Delay kneecliff over utilization under utilization saturation congestion collapse

9. laik@cs.berkeley.edu9 TCP Congestion Control  Operate to the left of the cliff -less efficient than operating at the knee, but requires less support from network  Solution: Carefully manage number of packets in network -starting up: increase number of packets allowed -equilibrium: maintain constant number of packets must probe periodically for more available bandwidth -congestion: decrease number of packets allowed

10. laik@cs.berkeley.edu10 TCP Congestion Control Components  Measure available bandwidth -slow start fast, hard on network -additive increase/multiplicative decrease slow, gentle on network  Detecting congestion -timeout based on RTT (last lecture) robust, causes low throughput -duplicate acks (Fast Retransmit) can be fooled, maintains high throughput  Recovering from loss -Fast recovery: avoid slow start when few packets lost

11. laik@cs.berkeley.edu11 Congestion Window (cwnd)  Limits how much data can be in transit  Integrate with flow control  implemented as # of bytes, describe as # packets EffectiveWindow = MaxWindow – (LastByteSent – LastByteAcked) MaxWindow = min(cwnd, AdvertisedWindow) LastByteAckedLastByteSent sequence number increases

12. 12 Slow Start Goal  Goal: discover congestion quickly -used to get rough initial estimate of cwnd  Slow Start used when -a new connection, or -after timeout, or -after connection has been idle for a while

13. laik@cs.berkeley.edu13 Slow Start Algorithm  Algorithm: -Set cwnd =1 -Each time a segment is acknowledged increment cwnd by one (cwnd++)  Slow Start increases cwnd exponentially -called “Slow” because it gradually increases sending rate according to the RTT -predecessor just increased to advWin immediately

14. laik@cs.berkeley.edu14 Slow Start Example  cwnd doubles every RTT 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 ACK for segments 4+5+6+7 cwnd = 8

15. laik@cs.berkeley.edu15 Slow Start Problem  Slow Start can cause serious loss -loss = bottleneck bandwidth * RTT  Example: -bottleneck link is 8 Mb/s -RTT is 100ms -at some point cwnd = 800,000 bits exactly right for bottleneck -100 ms late, cwnd = 1,600,000 bits twice the bottleneck, 800,000 bits lost (oops)  Need to switch to something else when throughput is close to bottleneck bandwidth

16. laik@cs.berkeley.edu16 Exiting Slow Start  cwnd>=advWin -limited by receiver’s advertised window  if cwnd allowed to increase, would grow unbounded  congestion -reached available bandwidth  switch to AI/MD  cwnd>=ssthresh -ssthresh: slow start threshold -ssthresh is a hint about when to slow down, calculated from previous congestion on same connection -“we experienced congestion beyond this point before, slow down”

17. 17 Additive Increase/ Multiplicative Decrease  Used Slow Start to get rough estimate of cwnd  Goal: maintain operating point at the left of the cliff -Additive increase: starting from the rough estimate, slowly increase cwnd to probe for additional available bandwidth -Multiplicative decrease: cut congestion window size aggressively if congestion occurs  Why not AI/AD, MI/MD, MI/AD: -mathematical models show A/M is only choice that converges to fairness and efficiency

18. laik@cs.berkeley.edu18 AI/MD Algorithm  ssthresh =   a segment is acknowledged -increment cwnd by 1/cwnd (cwnd += 1/cwnd) -as a result, cwnd is increased by one only if all segments in a cwnd have been acknowledged.  congestion detected -timeout: ssthresh = cwnd/2; cwnd = 1; begin slow start -duplicate acks (Fast Retransmit): later

19. laik@cs.berkeley.edu19 Slow Start/AI/MD Example  Assume that ssthresh = 8 Roundtrip times Cwnd (in segments) ssthresh

20. 20 The big picture Time cwnd Timeout Slow Start AI/MD ssthresh Timeout Slow Start AI/MD

21. 21 Slow Start/AI/MD Pseudocode Initially: cwnd = 1; ssthresh = infinite; New ack received: if (cwnd < ssthresh) /* Slow Start*/ cwnd = cwnd + 1; else /* Congestion Avoidance */ cwnd = cwnd + 1/cwnd; Timeout: /* Multiplicative decrease */ ssthresh = win/2; cwnd = 1;

22. laik@cs.berkeley.edu22 AI/MD Problem  If available bandwidth increases suddenly -e.g., other flows finish, route changes  then AI/MD will be slow to use it  Without help from network, there is a fundamental tradeoff between -being able to take available bandwidth and -causing loss

23. laik@cs.berkeley.edu23 Congestion Detection  Wait for Retransmission Time Out (RTO) -RTO kills throughput  In BSD TCP implementations, RTO is usually more than 500ms -the granularity of RTT estimate is 500 ms -retransmission timeout is RTT + 4 * mean_deviation  Solution: Don’t wait for RTO to expire

24. laik@cs.berkeley.edu24 Fast Retransmit  Resend a segment after 3 duplicate ACKs -a duplicate ACK means that an out-of sequence segment was received  Notes: -packet reordering can cause duplicate ACKs -window may be too small to get enough duplicate ACKs ACK 2 segment 1 cwnd = 1 cwnd = 2 segment 2 segment 3 ACK 4 cwnd = 4 segment 4 segment 5 segment 6 segment 7 ACK 3 3 duplicate ACKs ACK 4

25. laik@cs.berkeley.edu25 Fast Recovery: After a Fast Retransmit  ssthresh = cwnd / 2  cwnd = ssthresh -instead of setting cwnd to 1, cut cwnd in half (multiplicative decrease)  for each dup ack arrival -dupack++ -MaxWindow = min(cwnd + dupack, AdvWin) -indicates packet left network, so we may be able to send more  receive ack for new data (beyond initial dup ack) -dupack = 0 -exit fast recovery  But when RTO expires still do cwnd = 1

26. laik@cs.berkeley.edu26 Fast Recovery Problem  Can’t recover when more than half the window size is lost -cwnd is cut in half -MaxWindow is only increased when dup ack is received -if more than half the window is lost, less than cwnd/2 dup acks will be received by sender -sender will not be able to send anything, must wait for timeout  more than half the window lost indicates serious congestion anyway

27. 27 Fast Retransmit and Fast Recovery  Retransmit after 3 duplicated acks -Prevent expensive timeouts  Reduce slow starts  At steady state, cwnd oscillates around the optimal window size Time cwnd Slow Start AI/MD Fast retransmit

28. laik@cs.berkeley.edu28 Other TCP-related techniques  TCP SACK -instead of cumulative acknowledgements, receiver tells sender exactly what was lost -useful when more than one packet lost in a window  Router support -have higher utilization, more fairness with router support

29. laik@cs.berkeley.edu29 TCP Congestion Control Summary  Measure available bandwidth -slow start fast, hard on network -additive increase/multiplicative decrease slow, gentle on network  Detecting congestion -timeout based on RTT robust, causes low throughput -Fast Retransmit can be fooled, maintains high throughput  Recovering from loss -Fast recovery: avoid timeout when few packets lost