1. Katz, Stoica F04 EECS 122: Introduction to Computer Networks Congestion Control Computer Science Division Department of Electrical Engineering and Computer Sciences University of California, Berkeley Berkeley, CA 94720-1776

2. Katz, Stoica F04 2 What We Know We know:  How to process packets in a switch  How to route packets in the network  How to send packets reliably We don’t know:  How fast to send "As we know, there are known knowns. There are things we know we know. We also know there are known unknowns. That is to say, we know there are some things we do not know. But there are also unknown unknowns, the ones we don't know we don't know." The Zen of Donald Rumsfeld.

3. Katz, Stoica F04 3 Implications  Send too slow: link is not fully utilized -Wastes time  Send too fast: link is fully utilized but.... -Queue builds up in router buffer (delay) -Overflow buffers in routers -Overflow buffers in receiving host (ignore)  Why are buffer overflows a problem? -Packet drops (mine and others) -Interesting history....(Van Jacobson rides to the rescue)

4. Katz, Stoica F04 4 Abstract View  Ignore internal structure of router and model it as having a single queue for a particular input- output pair Sending HostBuffer in Router Receiving Host AB

5. Katz, Stoica F04 5 Three Congestion Control Problems  Adjusting to bottleneck bandwidth  Adjusting to variations in bandwidth  Sharing bandwidth between flows

6. Katz, Stoica F04 6 Single Flow, Fixed Bandwidth  Adjust rate to match bottleneck bandwidth -Without any a priori knowledge -Could be gigabit link, could be a modem AB 100 Mbps

7. Katz, Stoica F04 7 Single Flow, Varying Bandwidth  Adjust rate to match instantaneous bandwidth -Assuming you have rough idea of bandwidth AB BW(t)

8. Katz, Stoica F04 8 Multiple Flows Two Issues:  Adjust total sending rate to match bandwidth  Allocation of bandwidth between flows A2B2 100 Mbps A1 A3 B3 B1

9. Katz, Stoica F04 9 Reality Congestion control is a resource allocation problem involving many flows, many links, and complicated global dynamics

10. Katz, Stoica F04 10 What’s Really Happening? View from a Single Flow  Knee – point after which -Throughput increases very slow -Delay increases fast  Cliff – point after which -Throughput starts to decrease very fast to zero (congestion collapse) -Delay approaches infinity  Note (in an M/M/1 queue) -Delay = 1/(1 – utilization) Load Throughput Delay kneecliff congestion collapse packet loss

11. Katz, Stoica F04 11 General Approaches  Send without care -Many packet drops -Not as stupid as it seems  Reservations -Pre-arrange bandwidth allocations -Requires negotiation before sending packets -Low utilization  Pricing -Don’t drop packets for the high-bidders -Requires payment model

12. Katz, Stoica F04 12 General Approaches (cont’d)  Dynamic Adjustment -Probe network to test level of congestion -Speed up when no congestion -Slow down when congestion -Suboptimal, messy dynamics, simple to implement  All three techniques have their place -But for generic Internet usage, dynamic adjustment is the most appropriate -Due to pricing structure, traffic characteristics, and good citizenship

13. Katz, Stoica F04 13 TCP Congestion Control  TCP connection has window -Controls number of unacknowledged packets  Sending rate: ~Window/RTT  Vary window size to control sending rate

14. Katz, Stoica F04 14 Congestion Window (cwnd)  Limits how much data can be in transit  Implemented as # of bytes  Described as # packets in this lecture EffectiveWindow = MaxWindow – (LastByteSent – LastByteAcked) MaxWindow = min(cwnd, AdvertisedWindow) LastByteAcked LastByteSent sequence number increases MaxWindow EffectiveWindow

15. Katz, Stoica F04 15 Two Basic Components  Detecting congestion  Rate adjustment algorithm -Depends on congestion or not -Three subproblems within adjustment problem Finding fixed bandwidth Adjusting to bandwidth variations Sharing bandwidth

16. Katz, Stoica F04 16 Detecting Congestion  Packet dropping is best sign of congestion -Delay-based methods are hard and risky  How do you detect packet drops? ACKs -TCP uses ACKs to signal receipt of data -ACK denotes last contiguous byte received Actually, ACKs indicate next segment expected  Two signs of packet drops -No ACK after certain time interval: time-out -Several duplicate ACKs (ignore for now)

17. Katz, Stoica F04 17 Rate Adjustment  Basic structure: -Upon receipt of ACK (of new data): increase rate -Upon detection of loss: decrease rate  But what increase/decrease functions should we use? -Depends on what problem we are solving

18. Katz, Stoica F04 18 Problem #1: Single Flow, Fixed BW  Want to get a first-order estimate of the available bandwidth -Assume bandwidth is fixed -Ignore presence of other flows  Want to start slow, but rapidly increase rate until packet drop occurs (“slow-start”)  Adjustment: -cwnd initially set to 1 -cwnd++ upon receipt of ACK

19. Katz, Stoica F04 19 Slow-Start  cwnd increases exponentially: cwnd doubles every time a full cwnd of packets has been sent -Each ACK releases two packets -Slow-start is called “slow” because of starting point segment 1 cwnd = 1 cwnd = 2 segment 2 segment 3 cwnd = 4 segment 4 segment 5 segment 6 segment 7 cwnd = 8 cwnd = 3

20. Katz, Stoica F04 20 Problems with Slow-Start  Slow-start can result in many losses -Roughly the size of cwnd ~ BW*RTT  Example: -At some point, cwnd is enough to fill “pipe” -After another RTT, cwnd is double its previous value -All the excess packets are dropped!  Need a more gentle adjustment algorithm once have rough estimate of bandwidth

21. Katz, Stoica F04 21 Problem #2: Single Flow, Varying BW  Want to be able to track available bandwidth, oscillating around its current value  Possible variations: (in terms of RTTs) -Multiplicative increase or decrease: cwnd  a*cwnd -Additive increase or decrease: cwnd  cwnd + b  Four alternatives: -AIAD: gentle increase, gentle decrease -AIMD: gentle increase, drastic decrease -MIAD: drastic increase, gentle decrease (too many losses) -MIMD: drastic increase and decrease

22. Katz, Stoica F04 22 Problem #3: Multiple Flows  Want steady state to be “fair”  Many notions of fairness, but here all we require is that two identical flows end up with the same bandwidth  This eliminates MIMD and AIAD  AIMD is the only remaining solution!

23. Katz, Stoica F04 23 Buffer and Window Dynamics  No congestion  x increases by one packet/RTT every RTT  Congestion  decrease x by factor 2 AB C = 50 pkts/RTT x

24. Katz, Stoica F04 24 AIMD Sharing Dynamics AB x DE  No congestion  rate increases by one packet/RTT every RTT  Congestion  decrease rate by factor 2 Rates equalize  fair share y

25. Katz, Stoica F04 25 AIAD Sharing Dynamics AB x DE  No congestion  x increases by one packet/RTT every RTT  Congestion  decrease x by 1 y

26. Katz, Stoica F04 26 Efficient Allocation  Too slow -Fail to take advantage of available bandwidth  underload  Too fast -Overshoot knee  overload, high delay, loss  Everyone’s doing it -May all under/over shoot  large oscillations  Optimal: -  x i =X goal  Efficiency = 1 - distance from efficiency line User 1: x 1 User 2: x 2 Efficiency line 2 user example overload underload

27. Katz, Stoica F04 27 AIMD AB x C DE y Limit rates: x = y

28. Katz, Stoica F04 28 AIAD AB x C DE y Limit rates: x and y depend on initial values

29. Katz, Stoica F04 29 Multiplicative Increase, Additive Decrease User 1: x 1 User 2: x 2 fairness line efficiency line (x 1h,x 2h ) (x 1h +a D,x 2h +a D ) (b I (x 1h +a D ), b I (x 2h +a D ))  Does not converge to fairness -Not stable at all  Does not converges to efficiency -Stable iff

30. Katz, Stoica F04 30 Additive Increase, Additive Decrease User 1: x 1 User 2: x 2 fairness line efficiency line (x 1h,x 2h ) (x 1h +a D,x 2h +a D ) (x 1h +a D +a I ), x 2h +a D +a I ))  Does not converge to fairness -Stable  Does not converge to efficiency -Stable iff

31. Katz, Stoica F04 31 Multiplicative Increase, Multiplicative Decrease User 1: x 1 User 2: x 2 fairness line efficiency line (x 1h,x 2h ) (b d x 1h,b d x 2h ) (b I b D x 1h, b I b D x 2h )  Does not converge to fairness -Stable  Converges to efficiency iff

32. Katz, Stoica F04 32 (b D x 1h +a I, b D x 2h +a I ) Additive Increase, Multiplicative Decrease User 1: x 1 User 2: x 2 fairness line efficiency line (x 1h,x 2h ) (b D x 1h,b D x 2h )  Converges to fairness  Converges to efficiency  Increments smaller as fairness increases -effect on metrics?

33. Katz, Stoica F04 33 Implementing AIMD  After each ACK -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  But need to decide when to leave slow-start and enter AIMD  Use ssthresh variable

34. Katz, Stoica F04 34 Slow Start/AIMD 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 = cwnd/2; cwnd = 1;

35. Katz, Stoica F04 35 The big picture (with timeouts) Time cwnd Timeout Slow Start AIMD ssthresh Timeout Slow Start AIMD

36. Katz, Stoica F04 36 Congestion Detection Revisited  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

37. Katz, Stoica F04 37 Fast Retransmits  Resend a segment after 3 duplicate ACKs -Duplicate ACK means that an out-of sequence segment was received  Notes: -ACKs are for next expected packet -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

38. Katz, Stoica F04 38 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

39. Katz, Stoica F04 39 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

40. Katz, Stoica F04 40 TCP Congestion Control Summary  Measure available bandwidth -Slow start: fast, hard on network -AIMD: slow, gentle on network  Detecting congestion -Timeout based on RTT robust, causes low throughput -Fast Retransmit: avoids timeouts when few packets lost can be fooled, maintains high throughput  Recovering from loss -Fast recovery: don’t set cwnd=1 with fast retransmits

41. Katz, Stoica F04 41 Issues to Think About  What about short flows? (setting initial cwnd) -most flows are short -most bytes are in long flows  How does this work over wireless links? -packet reordering fools fast retransmit -loss not always congestion related  High speeds? -to reach 10gbps, packet losses occur every 90 minutes!  Why are losses bad? -Tornado codes: can reconstruct data proportional to packets that get through. Why not send at maximal rate?  Fairness: how do flows with different RTTs share link?

42. Katz, Stoica F04 42 Bonus Question  Why is TCP like Blanche Dubois?  Because it “relies on the kindness of strangers...”  What happens if not everyone cooperates?