Advanced Congestion Control (Hosts)

Transcription

1 Advanced Congestion Control (Hosts) : Fundamentals of Computer Networks Bill Nace Material from Computer Networking: A Top Down Approach, 5 th edition. J.F. Kurose and K.W. Ross

2 Congestion Control (2) Apply some control theory Region 1: Low throughput Region 2: High delay Throughput increases slowly Delay increases quickly Region 3: Collapse Throughput 0, Delay At what load would we like to operate?

3 Feedback Mechanism End-to-end: Messages from receiver Network Assisted: Signals from routers 3

4 Slow Start When connection begins, increase rate exponentially: double CongWin every RTT done by incrementing CongWin for every ACK received Summary: initial rate is slow but ramps up exponentially fast RTT one segment two segments four segments

5 Congestion Avoidance Additive Increase: Increase CongWin by 1 MSS every RTT until loss is detected Multiplicative Decrease: cut CongWin in half after a loss event Congestion Window Size 24 Kbytes 16 Kbytes 8 Kbytes Sawtooth behavior: Probing for bandwidth time 5

6 TCP CC States Slow start CongWin ssthresh timeout Cong Avoid 3dupACK timeout ACK 3dupACK Fast Recovery

7 traceroute Advanced TCP Congestion Control Lots of algorithmic variants Long Fat Networks problem TCP-BIC Compound TCP Prisoner s Dilemma 7

8 TCP Variations TCP New Reno TCP Vegas TCP Hybla BIC / CUBIC Compound TCP many others exist (SACK, Veno, Westwood, XCP, YeAH-TCP,...) 8

9 TCP New Reno Improves fast recovery retransmissions RFC 2582 & 3782 Good at filling multiple holes, but still probing for higher throughput Substantially outperforms Reno at high error rates 9

10 New Reno: Improve Fast Recovery In Fast Recovery: Record highest unacked# already sent Return to cong-avoid when this segment is ACKed For each Dup ACK, new segment sent keeps transmit window full For each good ACK -- hole assumed retransmit segment just past the ACK seqnum 10

11 TCP Vegas First delay-based TCP variant Look for variations in RTT as indication of queue length at routers (i.e. oncoming congestion) If lower than expected RTT, send more If higher, send less (by lowering CongWin) Congestion prevention strategy 11

12 TCP Vegas (2) Goal: keep a certain amount of data in the queues of the network Much smoother flow than Reno Achieves higher average throughput But, when competing with Reno, only gets ~2/3 of Reno's bandwidth Backs off before congestion, while Reno backs off only after congestion Source: Brakmo94 and La99. Available on course website 12

13 TCP Hybla Goal: improve high-latency / high-error rate links (i.e. satellite) Much longer RTT Segments dropped due to bit-error look like congestion Analytically evaluates CongWin dynamics Rather than measuring RTT Included in Linux from Source: Caini2004. Available on course website 13

14 The LFN Problem Long Fat Networks: High-speed and high-latency Many, many segments will be in-flight How many? 14

15 The LFN Problem How many? Ex: 10Gbps, 100ms RTT, MSS 1500B CongWin = 83,333 segments Needs loss event < every 1hr 40 min Else never gets out of Slow Start i.e. 1 event per 5 billion segments Bit Error Rate of 2x10-14 unrealistic Example from RFC3649 written in Dec

16 LFN Approaches Get lots of segments in flight: Start really quickly Can we do better than Slow Start? Be more aggressive in CongAvoid AIMD approach of adding 1 won t cut it 16

17 Binary Increase Congestion TCP-BIC uses a binary search to probe for additional bandwidth Default for Linux Replaced with Cubic, a fairer alternative 17

18 Binary Search Target CongWin is halfway between max and min, 2 control variables If CongWin grows to target, set min to current, recalculate target If loss happens, set max to current, min to recovery point, recalculate target

19 BIC: Fairness An overly aggressive algorithm will rob bandwidth from normal TCP algorithms BIC incorporates fairness idea Binary search means less aggressive when near bandwidth maximums Also includes a plateau period to allow TCP flows to get out of slow start 19

20 What is Congestion? Loss-based: Look for 3 dup ACK, timeout Used in Reno, HSTCP, STCP, TCP-BIC Delay-based: Look for variations in RTT, estimate queue lengths at routers Used in TCP Vegas, FAST TCP 20

21 Compound TCP A hybrid of loss-based and delay-based algorithms More aggressively seeks for additional bandwidth when no evidence of congestion Attempts to be especially fair to other protocols Used since Microsoft Vista 21

22 CTCP Mechanisms Key idea is to use a normal congestion window, combined with a delay-based congestion window TotalCongWind = cwind + dwind cwind updated normally (AIMD) in CongAvoid No loss cwind = cwind + 1MSS per RTT* Loss (timeout, 3 dup ACK) cwind = cwind / 2 *Actually, a small adjustment as TotalCongWind should grow by 1MSS per RTT 22

23 Delay Window If network bandwidth is underutilized (based on RTT observations) dwind(t+1) = dwind(t) + α dwind(t) k If some queueing happening dwind(t+1) = dwind(t)-queue length* If there is a loss dwind(t+1) = (1 - β) dwind(t) α, β, k are tuning parameters for scalability, smoothness and responsiveness *Yes, there s a complicated way of predicting what the queue lengths might be. Let s skip it... 23

24 Fairness TCP flows compete for additional bandwidth If one flow is too aggressive, it will cause segment loss in other flows (and perhaps itself) Segment loss will cause other flows to retreat Which may provide additional bandwidth to the aggressor Especially problematic with delay-based Sense congestion earlier than a loss 24

25 CTCP Fairness When no congestion sensed, full-speed ahead! When congestion first sensed (via delay measurements) stop seeking more BW When loss occurs, back off normally 25

26 traceroute Advanced TCP Congestion Control Lots of algorithmic variants Long Fat Networks problem TCP-BIC Compound TCP Prisoner s Dilemma 26

27 Prisoner s Dilemma Game-theory problem with interesting implications for networks Classic Form 2 conspirators arrested Separately offered a deal Each must choose to betray or remain silent B stays silent B betrays A silent A betrays 6 months each A: 10 years A: Goes free B: 10 years B: Goes free 5 years each

28 Why Discuss? TCP restrictions are self-imposed Nothing in the network checks that sender is actually following the algorithms Bad behavior can have short-term advantages Examples?

29 Lesson Objectives Now, you should be able to: describe features of the following TCP congestion control variations: New Reno, Vegas, Hybla, BIC and Compound TCP describe the advantages and disadvantages of delay-based variants 29

30 You should be able to: describe the challenges of congestion control for LFNs describe the problems and attractions of a non-cooperative TCP implementation