Internet Protocols Fall Lecture 20 Congestion Control Review Andreas Terzis

Transcription

1 Internet Protocols Fall 2005 Lecture 20 Congestion Control Review Andreas Terzis

2 Outline TCP congestion control Router-based support RED ECN CS 349/Fall05 2

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

4 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 349/Fall05 4

5 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 349/Fall05 5

6 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 349/Fall05 6

7 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 349/Fall05 7

8 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 349/Fall05 8

9 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 349/Fall05 9

10 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 349/Fall05 10

11 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 349/Fall05 11

12 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 349/Fall05 12

13 AIMD C y Limit rates: x = y CS 349/Fall05 13 x

14 AIAD C y Limit rates: x and y depend on initial values x CS 349/Fall05 14

15 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 349/Fall05 15

16 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 349/Fall05 16

17 The big picture (with timeouts) cwnd Timeout AIMD Timeout AIMD ssthresh Slow Start Slow Start Slow Start Time CS 349/Fall05 17

18 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 349/Fall05 18

19 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 ACK 2 ACK 3 ACK 4 ACK 4 ACK 4 ACK 4 segment 1 segment 2 segment 3 segment 4 segment 5 segment 6 segment 7 CS 349/Fall05 19

20 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 349/Fall05 20

21 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 349/Fall05 21

22 Random Early Detection (RED) Basic premise: router should signal congestion when the queue first starts building up (by dropping a packet) but router should give flows time to reduce their sending rates before dropping more packets Therefore, packet drops should be: early: don t wait for queue to overflow random: don t drop all packets in burst, but space drops out CS 349/Fall05 22

23 RED FIFO scheduling Buffer management: Probabilistically discard packets Probability is computed as a function of average queue length (why average?) Discard Probability 1 0 min_th max_th queue_len Average Queue Length CS 349/Fall05 23

24 RED (cont d) min_th minimum threshold max_th maximum threshold avg_len average queue length avg_len = (1-w)*avg_len + w*sample_len Discard Probability 1 0 min_th max_th queue_len Average Queue Length CS 349/Fall05 24

25 RED (cont d) If (avg_len < min_th) enqueue packet If (avg_len > max_th) drop packet If (avg_len >= min_th and avg_len < max_th) enqueue packet with probability P Discard Probability (P) 1 0 min_th max_th queue_len Average Queue Length CS 349/Fall05 25

26 RED (cont d) P = max_p*(avg_len min_th)/(max_th min_th) Discard Probability max_p P 1 0 min_th max_th queue_len Average Queue Length avg_len CS 349/Fall05 26

27 Average vs. Instantaneous Queue CS 349/Fall05 27

28 RED Advantages High network utilization with low delays Average queue length small, but capable of absorbing large bursts Many refinements to basic algorithm make it more adaptive (requires less tuning) CS 349/Fall05 28

29 Explicit Congestion Notification Rather than drop packets to signal congestion, router can send an explicit signal Explicit congestion notification (ECN): instead of optionally dropping packet, router sets a bit in the packet header If data packet has bit set, then ACK has ECN bit set Backward compatibility: bit in header indicates if host implements ECN note that not all routers need to implement ECN CS 349/Fall05 29

30 ECN Advantages No need for retransmitting optionally dropped packets No confusion between congestion losses and corruption losses CS 349/Fall05 30