Advanced Congestion Control (Hosts) 14-740: Fundamentals of - PowerPoint PPT Presentation

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

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?

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

Slow Start • When connection begins, o n e s e g m e n t increase rate exponentially: RTT • double CongWin every RTT t w • done by incrementing o s e g m e n t s CongWin for every ACK received f o u r s e g m e n t s • Summary: initial rate is slow but ramps up exponentially fast

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 24 Kbytes Sawtooth Congestion Window Size behavior: Probing 16 Kbytes for bandwidth 8 Kbytes time 5

TCP CC States CongWin ≥ ssthresh Slow Cong timeout start Avoid t i m e o ACK u t 3dupACK 3dupACK Fast Recovery

States Through Time

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

TCP Variations • TCP New Reno • TCP Vegas • TCP Hybla • BIC / CUBIC • Compound TCP • many others exist (SACK, Veno, Westwood, XCP , YeAH-TCP , . . .) 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 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 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 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 o ff before congestion, while Reno backs o ff only after congestion Source: Brakmo94 and La99. Available on course website 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 2.6.13 Source: Caini2004. Available on course website 14

The LFN Problem • Long Fat Networks: High-speed and high-latency • Many, many segments will be in-flight • How many? 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 16 Example from RFC3649 written in Dec 2003

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 17

Binary Increase Congestion • TCP-BIC uses a binary search to probe for additional bandwidth • Default for Linux 2.6.8-2.6.18 • Replaced with Cubic, a fairer alternative 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

CUBIC States Exponential Increase: More aggressive than Reno's Additive Increase

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 21

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 22

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 23

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 24 *Actually, a small adjustment as TotalCongWind should grow by 1MSS per RTT

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 25 *Yes, there’s a complicated way of predicting what the queue lengths might be. Let’s skip it...

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 26

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

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

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

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?

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 31

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