Computer Network Fundamentals Spring Week 10 Congestion Control Andreas Terzis

Transcription

1 Computer Network Fundamentals Spring 2008 Week 10 Congestion Control Andreas Terzis

2 Outline Congestion Control TCP Congestion Control CS 344/Spring08 2

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 CS 344/Spring08 3

4 What s at Stake? 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) CS 344/Spring08 4

5 Abstract View A B Sending Host Buffer in Router Receiving Host We ignore internal structure of router and model it as having a single queue for a particular input-output pair CS 344/Spring08 5

6 Three Congestion Control Problems Adjusting to bottleneck bandwidth Adjusting to variations in bandwidth Sharing bandwidth between flows CS 344/Spring08 6

7 Single Flow, Fixed Bandwidth A 100 Mbps B Adjust rate to match bottleneck bandwidth without any a priori knowledge could be gigabit link, could be a modem CS 344/Spring08 7

8 Single Flow, Varying Bandwidth A BW(t) B Adjust rate to match instantaneous bandwidth assuming you have rough idea of bandwidth CS 344/Spring08 8

9 Multiple Flows Two Issues: Adjust total sending rate to match bandwidth Allocation of bandwidth between flows A1 A2 100 Mbps B1 B2 A3 B3 CS 344/Spring08 9

10 Reality Congestion control is a resource allocation problem involving many flows, many links, and complicated global dynamics CS 344/Spring08 10

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 CS 344/Spring08 11

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 CS 344/Spring08 12

13 TCP Congestion Control TCP connection has window controls number of unacknowledged packets Sending rate: ~Window/RTT Vary window size to control sending rate CS 344/Spring08 13

14 Congestion Window (cwnd) Limits how much data can be in transit Implemented as # of bytes Described as # packets in this lecture MaxWindow = min(cwnd, AdvertisedWindow) EffectiveWindow = MaxWindow (LastByteSent LastByteAcked) MaxWindow LastByteAcked LastByteSent EffectiveWindow sequence number increases CS 344/Spring08 14

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 CS 344/Spring08 15

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) CS 344/Spring08 16

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 CS 344/Spring08 17

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 CS 344/Spring08 18

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 cwnd = 1 cwnd = 2 cwnd = 3 cwnd = 4 cwnd = 8 segment 1 segment 2 segment 3 segment 4 segment 5 segment 6 segment 7 CS 344/Spring08 19

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! Therefore, need a more gentle adjustment algorithm once have rough estimate of bandwidth CS 344/Spring08 20

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 CS 344/Spring08 21

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 Look at later explanation AIMD is the only remaining solution! CS 344/Spring08 22

23 Buffer and Window Dynamics A x C = 50 pkts/rtt No congestion x increases by one packet/rtt every RTT Congestion decrease x by factor 2 B CS 344/Spring08 23

24 AIMD Sharing Dynamics A D x y No congestion rate increases by one packet/rtt every RTT Congestion decrease rate by factor 2 B E Rates equalize fair share CS 344/Spring08 24

25 AIAD Sharing Dynamics A D x y B E No congestion x increases by one packet/rtt every RTT Congestion decrease x by 1 CS 344/Spring08 25

26 AIMD Limit rates: x = y CS 344/Spring08 26

27 AIAD Limit rates: x and y depend on initial values CS 344/Spring08 27

28 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 CS 344/Spring08 28

29 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; CS 344/Spring08 29

30 The big picture (with timeouts) cwnd Timeout AIMD Timeout AIMD ssthresh Slow Start Slow Start Slow Start Time CS 344/Spring08 30

31 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 CS 344/Spring08 31

32 Fast Retransmits Resend a segment after 3 duplicate ACKs a 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 cwnd = 1 cwnd = 2 cwnd = 4 3 duplicate ACKs segment 1 segment 2 segment 3 segment 4 segment 5 segment 6 segment 7 CS 344/Spring08 32

33 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 CS 344/Spring08 33

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

35 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 CS 344/Spring08 35

36 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? CS 344/Spring08 36