EE 122 :TCP Congestion Control

1. EE 122:TCP Congestion Control Ion Stoica TAs: Junda Liu, DK Moon, David Zats http://inst.eecs.berkeley.edu/~ee122/ (Materials with thanks to Vern Paxson, Jennifer Rexford,and colleagues at UC Berkeley)

2. Goals of Today’s Lecture • Principles of congestion control • Learning that congestion is occurring • Adapting to alleviate the congestion • TCP congestion control • Additive-increase, multiplicative-decrease (AIMD) • How to begin transmitting: Slow Start

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

4. It’s Not Just The Sender & Receiver • Flow control keeps one fast sender from overwhelming a slow receiver • Congestion control keeps a set of senders from overloading the network • Three congestion control problems: • Adjusting to bottleneck bandwidth • Without any a priori knowledge • Could be a Gbps link; could be a modem • Adjusting to variations in bandwidth • Sharing bandwidth between flows

5. Congestion is Unavoidable • Two packets arrive at the same time • The node can only transmit one • … and either buffers or drops the other • If many packets arrive in a short period of time • The node cannot keep up with the arriving traffic • … and the buffer may eventually overflow

6. Congestion Collapse • Definition: Increase in network load results in a decrease of useful work done • Due to: • Undelivered packets • Packets consume resources and are dropped later in network • Spurious retransmissions of packets still in flight • Unnecessary retransmissions lead to more load! • Pouring gasoline on a fire • Mid-1980s: Internet grinds to a halt • Until Jacobson/Karels (Berkeley!) devise TCP congestion control

7. View from a Single Flow packet loss knee cliff • Knee – point after which • Throughput increases very slowly • Delay increases quickly • Cliff – point after which • Throughput starts to decrease very fast to zero (congestion collapse) • Delay approaches infinity Throughput congestion collapse Load Delay Load

8. General Approaches • Send without care • Many packet drops (1) Reservations • Pre-arrange bandwidth allocations • Requires negotiation before sending packets • Low utilization (2) Pricing • Don’t drop packets for the high-bidders • Requires payment model

9. General Approaches (cont’d) (3) 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

10. TCP Congestion Control • TCP connection has window • Controls number of unacknowledged packets • Sending rate: ~Window/RTT • Vary window size to control sending rate

11. Sizing the Windows • cwnd (Congestion Windows) • How many bytes can be sent without overflowing routers • Computed by congestion control algorithm • AdvertisedWindow • How many bytes can be sent without overflowing the sender • Determined by the receiver

12. EffectiveWindow • Limits how much data can be in transit • Implemented as # of bytes • Described as # packets (segments) in this lecture MaxWindow = min(cwnd, AdvertisedWindow) EffectiveWindow = MaxWindow – (LastByteSent – LastByteAcked) MaxWindow LastByteAcked EffectiveWindow LastByteSent sequence number increases

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

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

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

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

17. 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 = 3 cwnd = 4 segment 4 segment 5 segment 6 segment 7 cwnd = 8

18. 5 Minute Break Questions Before We Proceed?

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

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

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

22. A B Buffer and Window Dynamics x • No congestion  x increases by one packet/RTT every RTT • Congestion  decrease x by factor 2 C = 50 pkts/RTT

23. AIMD Sharing Dynamics x1 A B x2 D E • No congestion  rate increases by one packet/RTT every RTT • Congestion  decrease rate by factor 2 Rates equalize  fair share

24. AIAD Sharing Dynamics x1 A B x2 D E • No congestion  x increases by one packet/RTT every RTT • Congestion  decrease x by 1

25. Efficient Allocation: Challenges of Congestion Control • 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: • xi=Xgoal • Efficiency = 1 - distance from efficiency line 2 user example overload User 2: x2 Efficiency line underload User 1: x1

26. Efficient: x1+x2=1 Fair Congested: x1+x2=1.2 (0.7, 0.5) (0.2, 0.5) (0.5, 0.5) Inefficient: x1+x2=0.7 (0.7, 0.3) Efficient: x1+x2=1 Not fair Example 1 fairness line • Total bandwidth 1 User 2: x2 efficiency line 1 User 1: x1

27. (bI(x1h-aD), bI(x2h-aD)) (x1h-aD,x2h-aD) MIAD fairness line • Increase: x*bI • Decrease: x - aD • Does not converge to fairness • Does not converges to efficiency (x1h,x2h) User 2: x2 efficiency line User 1: x1

28. (x1h-aD+aI),x2h-aD+aI)) (x1h-aD,x2h-aD) AIAD fairness line • Increase: x + aI • Decrease: x - aD • Does not converge to fairness • Does not converge to efficiency (x1h,x2h) User 2: x2 efficiency line User 1: x1

29. (bIbDx1h,bIbDx2h) (bdx1h,bdx2h) MIMD fairness line • Increase: x*bI • Decrease: x*bD • Does not converge to fairness • Converges to efficiency iff (x1h,x2h) User 2: x2 efficiency line User 1: x1

30. (bDx1h+aI,bDx2h+aI) (bDx1h,bDx2h) AIMD fairness line (x1h,x2h) • Increase: x+aD • Decrease: x*bD • Converges to fairness • Converges to efficiency • Increments smaller as fairness increases User 2: x2 efficiency line User 1: x1

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

32. 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;

33. The big picture (with timeouts) cwnd Timeout Timeout AIMD AIMD ssthresh SlowStart SlowStart SlowStart Time

34. Summary • Congestion is inevitable • Internet does not reserve resources in advance • TCP actively tries to grab capacity • Congestion control critical for avoiding collapse • AIMD: Additive Increase, Multiplicative Decrease • Congestion detected via packet loss (fail-safe) • Slow start to find initial sending rate & to restart after timeout • Next class • Advanced congestion control