TCP Congestion Control

TCP TahoeTCP RenoTCP Vegas

Internet Congestion Collapse In the late 80s, the Internet suffered a

congestion collapse

Host

Host

Host

Congestion!Packet drops!!

Data+ Retransmissions

More Drops!!!

Collapse

Why is Today’s Topic Important?

The algorithm for TCP congestion control is the main reason we can

use the Internet successfully today despite largely unpredictable user

access patterns and despite resource bottlenecks and

limitations. Without TCP congestion control, the Internet could have become history a long time ago.

Resource Management Solutions

Handling congestion pre-allocate resources so as to avoid congestion control congestion if (and when) is occurs

Two points of implementation routers inside the network (queuing discipline) hosts at the edges of the network (transport protocol)

Destination1.5-Mbps T1 link

Router

Source2

Source1

100-Mbps FDDI

10-Mbps Ethernet

Detecting Congestion Packet drops indicate congestion

Is that really true? Why does it work?

Src Dst

Packet

Ack

Drop

Timeout! No Ack =

Congestion!

Controlling Congestion – The Effect of Window Size

Note that sender’s window is equal to the number of sender packets in flight (in the network). Why?

A Window’s worth of packets

X acks

Window

X more packets

Source Destination

Controlling Congestion Reduce window less packets in

the network Increase window more packets in

the network Idea: Concept of a congestion

window – window is smaller when congestion is larger and vice versa

Additive Increase, Multiplicative Decrease

Each time a packet drop occurs, slash window size in half (multiplicative decrease) Multiplicative decrease is necessary to

avoid congestion When no losses are observed,

gradually increase window size (additive increase)

AIMD (cont)

In practice: increment a little for each ACKIncrement = (MSS*MSS)/CongestionWindow

CongestionWindow += Increment

Source Destination

…

Algorithm increment CongestionWindow by

one packet per RTT (linear increase)

divide CongestionWindow by two whenever a timeout occurs (multiplicative decrease)

AIMD (cont) Trace: sawtooth behavior

60

20

1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0

KB

Time (seconds)

70

304050

10

10.0

Problems What should the window size be

Initially? Upon packet loss and timeout?

Pessimistic window size? (e.g., 1) Additive increase is too slow in ramping

up window size – short connections will not fully utilize available bandwidth

Optimistic window size? Large initial burst may cause router

queue overflow

Slow Start

Objective: determine the available capacity quickly

Idea: Use CongestionThreshold as an

optimistic CongestionWindow estimate begin with CongestionWindow = 1

packet double CongestionWindow each RTT

(increment by 1 packet for each ACK)

When CongestionThreshold is crossed, use additive increase

Source Destination

…

Fast Retransmit Problem: coarse-grain TCP

timeouts lead to idle periods Fast retransmit:

Send an ack on every packet reception

Send duplicate of last ack when a packet is received out of order

Use duplicate ACKs to trigger retransmission

Packet 1

Packet 2

Packet 3

Packet 4

Packet 5

Packet 6

Retransmitpacket 3

ACK 1

ACK 2

ACK 2

ACK 2

ACK 6

ACK 2

Sender Receiver

Self Clocking and Slow Start Each packet’s transmission is “clocked” by an ACK –

no bursts develop

W=1 W=2 W=4 W=5 W=6 W=7

Slow Start

…

Self Clocking in Operation Each packet’s transmission is “clocked” by an ACK –

no bursts develop

W=32

……

Self Clocking Interrupted During timeouts, ACKs are drained from the network.

Self clocking is interrupted. Next transmission causes a burst. Hence, slow start!

W=32

……Lost

Timeout

Retransmission

Ack32

16 packet burst

Cut window in 1/2

ACKsDrained!!

Self Clocking and Fast Retransmit / Fast Recovery

When fast retransmit is used, the packet is retransmitted before all ACKs are drained. Slow start is not needed

W=32

……Lost

FastRetransmission

Cut window in 1/2

TCP Vegas Uses congestion avoidance instead

of congestion control Vegas: Congestion avoidance: Predict

and avoid congestion before it occurs Tahoe, Reno: Congestion control:

React to congestion after it occurs Question: How to predict

congestion?

TCP Vegas

Idea: source watches for some sign that router’s queue is building up and congestion will happen too; e.g., RTT grows sending rate

flattens

60

20

0.5 1.0 1.5 4.0 4.5 6.5 8.0

KB

Time (seconds)

Time (seconds)

70

304050

10

2.0 2.5 3.0 3.5 5.0 5.5 6.0 7.0 7.5 8.5

900

300100

0.5 1.0 1.5 4.0 4.5 6.5 8.0

Sen

ding

KB

ps

1100

500700

2.0 2.5 3.0 3.5 5.0 5.5 6.0 7.0 7.5 8.5

Time (seconds)0.5 1.0 1.5 4.0 4.5 6.5 8.0Q

ueue

siz

e in

rou

ter

5

10

2.0 2.5 3.0 3.5 5.0 5.5 6.0 7.0 7.5 8.5

Observation Packet accumulation in the network can be

inferred by monitoring RTT and sending rate

Bottleneck LinkOverloadedRouter

Sending Rate

cwnd

Sending Rate = cwnd / RTT

Algorithm

Let BaseRTT be the minimum of all measured RTTs (commonly the RTT of the first packet)

If not overflowing the connection, thenExpectRate = CongestionWindow/BaseRTT

Source calculates ActualRate once per RTT Source compares ActualRate with ExpectRate

Diff = ExpectedRate - ActualRateif Diff <

increase CongestionWindow linearlyelse if Diff >

decrease CongestionWindow linearlyelse

leave CongestionWindow unchanged

Algorithm (cont)

Parameters = 1 packet = 3 packets

70605040302010

KB

Time (seconds)

0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 5.0 5.5 6.0 6.5 7.0 7.5 8.0

0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 5.0 5.5 6.0 6.5 7.0 7.5 8.0

CA

M K

Bps

240200160120

8040

Time (seconds)