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

Material from Computer Networking: A Top Down Approach, J.F. Kurose and K.W. Ross

Advanced Congestion Control (Hosts)

14-740: Fundamentals of Computer Networks Bill Nace

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
• perate?

Feedback Mechanism

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

3

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

• n

e s e g m e n t t w

• s

e g m e n t s f

• u

r s e g m e n t s

• Additive Increase: Increase CongWin by

1 MSS every RTT until loss is detected

• Multiplicative Decrease: cut CongWin in

half after a loss event

Congestion Avoidance

5

24 Kbytes 16 Kbytes 8 Kbytes time Congestion Window Size

Sawtooth behavior: Probing for bandwidth

TCP CC States

Slow start Cong Avoid

Fast Recovery CongWin ≥ ssthresh timeout t i m e

• u

t 3dupACK 3dupACK ACK

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
• f queue length at routers (i.e.
• ncoming 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 off before congestion, while

Reno backs off only after congestion

13

Source: Brakmo94 and La99. Available on course website

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

14

Source: Caini2004. Available on course website

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

*Actually, a small adjustment as TotalCongWind should grow by 1MSS per RTT 24

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 off 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 offered a “deal”
• Each must choose to betray or remain silent

B stays silent B betrays A silent 6 months each A: 10 years 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
• f a non-cooperative TCP

implementation