EE 122: Congestion Control and Avoidance

Transcription

1 Problem EE 122: Congestion Control and Avoidance Kevin Lai October 23, 2002 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 laik@cs.berkeley.edu 2 Solutions Non-decreasing Efficiency under Load 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 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? Efficiency knee Load ok? good cliff laik@cs.berkeley.edu 3 laik@cs.berkeley.edu 4 1

2 Congestion Collapse Transport Layer Congestion Collapse 1 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 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) laik@cs.berkeley.edu 5 laik@cs.berkeley.edu 6 Transport Layer Congestion Collapse 2 Congestion Collapse and Efficiency Penalized ignores loss bw wasted 90% loss 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 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 Delay Throughput knee cliff under saturation utilization over utilization Load congestion collapse laik@cs.berkeley.edu 7 Load laik@cs.berkeley.edu 8 2

3 TCP Congestion Control TCP Congestion Control Components 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 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 laik@cs.berkeley.edu 9 laik@cs.berkeley.edu 10 Congestion Window (cwnd) Slow Start Goal Limits how much data can be in transit Integrate with flow control implemented as # of bytes, describe as # packets MaxWindow = min(cwnd, AdvertisedWindow) EffectiveWindow = MaxWindow (LastByteSent LastByteAcked) 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 LastByteAcked LastByteSent sequence number increases laik@cs.berkeley.edu

4 Slow Start Algorithm Slow Start Example 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 cwnd doubles every RTT cwnd = 1 cwnd = 2 cwnd = 4 cwnd = 8 segment 1 ACK for segment 1 segment 2 segment 3 ACK for segments segment 4 segment 5 segment 6 segment 7 ACK for segments laik@cs.berkeley.edu 13 laik@cs.berkeley.edu 14 Slow Start Problem Exiting Slow Start 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 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 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 laik@cs.berkeley.edu 15 laik@cs.berkeley.edu 16 4

5 Additive Increase/ Multiplicative Decrease AI/MD Algorithm 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 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 17 laik@cs.berkeley.edu 18 Slow Start/AI/MD Example The big picture Assume that ssthresh = 8 cwnd = 1 cwnd = 2 cwnd cwnd = 4 Timeout Cwnd (in segments) 10 8 ssthresh t=0 t=2 t=4 t=6 cwnd = 8 cwnd = 9 Slow Start Slow Start AI/MD ssthresh Timeout Slow Start AI/MD Time Roundtrip times cwnd = 10 laik@cs.berkeley.edu

6 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; 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 21 laik@cs.berkeley.edu 22 Congestion Detection Fast Retransmit 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 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 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 laik@cs.berkeley.edu 23 laik@cs.berkeley.edu 24 6

7 Fast Recovery: After a Fast Retransmit Fast Recovery Problem 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 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 laik@cs.berkeley.edu 25 laik@cs.berkeley.edu 26 Fast Retransmit and Fast Recovery Other TCP-related techniques cwnd Slow Start Fast retransmit AI/MD Retransmit after 3 duplicated acks - Prevent expensive timeouts Reduce slow starts At steady state, cwnd oscillates around the optimal window size Time 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 27 laik@cs.berkeley.edu 28 7

8 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 laik@cs.berkeley.edu 29 8