css432: congestion control 1 css432 congestion control textbook ch6.1 – 6.4 professor: munehiro...

CSS432: Congestion Control 1

CSS432 Congestion ControlTextbook Ch6.1 – 6.4

Professor: Munehiro Fukuda

(Augmented by Rob Nash)


Taxonomy Resource in network systems

Link bandwidth Buffer size in routers or switches

Two sides of the same coin Pre-allocate resources so as to avoid congestion Control congestion that leads to resource restrictions

Flow control versus congestion control Flow control: to keep a fast sender from overrunning a slow receiver Congestion control: to keep a set of senders from sending two much data into the

network. Two points of implementation

Router Centric QoS-based service Reservation-based Rate-based

Host Centric Best-effort service Feedback-based Window-based


Connectionless Flow Datagrams

Switched independently Flowing through a particular set of routers if transmitted from the same source/destination pair

Connectionless Flows Routers

No state if they follow purely connectionless service Hard state if they follow purely connection-oriented service Soft state used to make resource allocation decision for each flow – How?

Router

Source2

Source1

Source3

Router

Router

Destination2

Destination1


Congestion in Packet-Switched Network

Source cannot directly observe the traffic on the slow network

A congested link could be assigned a large edge weight by the route propagation protocol

All packets may have to flow through the same (bottleneck) router to the destination.

Destination1.5-Mbps T1 link

Router

Source2

Source1

100-Mbps FDDI

10-Mbps Ethernet

drops off overflowed packets.


TCP Congestion Control

Idea Assumes best-effort network (FIFO or FQ routers) Determines network capacity at each source host Uses implicit feedback Uses ACKs to pace packet transmission (self-clocking)

Challenge Determining the available capacity in the first place Adjusting # in-transit packets in response to dynamic

changes in the available capacity


Additive Increase/Multiplicative Decrease (AIMD)

New state variable per connection: CongestionWindow Limits how much data source can send: Previously:

EffectiveWindow= AdvertisedWindow – (LastbyteSent - LastByteAcked)

Now:EffectiveWindow= Min( CongestionWindow, AdvertisedWindow) – (LastByteSent – LastByteAcked)

Idea: Increase CongestionWindow when

congestion goes down Decrease CongestionWindow when

congestion goes up

Sending application

LastByteWritten

TCP

LastByteSentLastByteAcked

LastByteSent – LastByteAcked ≤ AdvertisedWindow

EffectiveWindow= AdvertisedWindow – (LastByteSent – LastByteAcked)

y


AIMD (cont)

Question: how does the source determine whether or not the network is congested?

Answer: a timeout occurs Timeout signals that a packet was lost Packets are seldom lost due to transmission error Lost packet implies congestion


AIMD (cont)

In practice: increment a little for each ACK

Increment = MSS * (MSS/CongestionWindow)CongestionWindow += Increment

Algorithm Increment CongestionWindow by one packet per CW (linear increase) Divide CongestionWindow by two whenever a timeout occurs

(multiplicative decrease)

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

AI in AIMD too Slow?

Connections just starting up ramp up too slowly and waste resourcesNot doing effective probing, either

We need something faster, that sounds faster:Quick Ramp Up?Fast Start?


Slow Start Overview (p481)

Avoids “out of the gate” bursts of windowSize Quicker than a linear increase Begin with CongestionWindow = 1 On timeout, set a threshold == CW/2

This is the multiplicative decrease Set CongestionWindow to 1 and slow start

Then switch to linear once CW >= threshold



Slow Start

Objective: reach the available capacity as fast as possible

Idea: Begin with CongestionWindow = 1 packet Double CongestionWindow each RTT

(increment by 1 packet for each ACK) When timeout occurs:

Set congestionThreashold to CongestionWindow / 2

Begin with CongestionWindow = 1 packet again Observe slow start with tcpdump in

assignment 3.

Source Destination

…


Slow Start (cont) Exponential growth, but slower than all at once Used…

when first starting connection When Nagle’s algorithm is used and packets are lost, (timeout occurs and

the congestion window is already 0) Final Algorithm:

CongestionThreshold = INF While (true) {

CongestionWindow = 1 While ( congestionWindow < congestionThreshold )

CongestionWindow *= 2 (based on slow start, exponential growth) While ( ACK returned )

CongestionWindow++ (based on additive lincrease, linear growth) If timeout occurs,

CongestionThreshold = CongestionWindow / 2 Continue

}


Slow Start (cont) Trace:

Problem: lose up to half a CongestionWindow’s worth of data

60

20

1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0

KB

70

304050

10

The actual congestion threshold Congestion windowPackets lost

Timeout

Slow Start Notes Only used at the beginning of a connection or

whenever a timeout occurs Slow Start augments the AI in AIMD

Less time to use more bandwidth after a course-grained timeout

So, our ramp up is steeper Fast Retransmit deals with cumulative ACKS

Avoid waiting for long timeouts

Fast Recovery skips Slow Start avoids “resetting to 1” (the slow start approach) and

just uses CW/2CSS432: Congestion Control 14


Fast Retransmit Problem: coarse-grain TCP timeouts

lead to idle periods

Fast retransmit: use duplicate ACKs to trigger retransmission The receiver sends back the same

ACK as the last packet received in the correct sequential order.

The sender retransmits the packet whose ID is one larger than this duplicate ACK, upon receiving three ACKs.

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

Duplicate ACK 1

Duplicate ACK 2

Duplicate ACK 3


Results

60

20

1.0 2.0 3.0 4.0 5.0 6.0 7.0

KB

70

304050

10

A packet lost

Duplicate Acks allowing to keep transmitting more packet

CongestionWindow is divided in a half upon retransmits rather than timeouts

Too many packets sent

A half of them dropped off

No ACKs returned

CongestionWindow stays in flat

Coarse-grained timeouts

Implications

Congestion Threshold is divided in a half upon retransmits and timeoutsCW = 1We use ACKS and DUP ACKS as our timers

Since these move faster than our internal clocks

A retransmission indicates congestion and we don’t need to wait forever (course timeout) to notice this



Fast Recovery

Fast recovery skip the slow start phasego directly to half the last successful CongestionWindow (ssthresh)

Below lacks the initial slow start & cg timeouts60

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

Chapter 6, Problem 27

Consider the TCP traces…



Congestion Avoidance TCP’s strategy is Congestion Control, not Avoidance

control congestion once it happens repeatedly increase load in an effort to find the point at which

congestion occurs, and then back off TCP needs to observe losses to find the sweet spot in the bandwidth

Alternative strategy predict when congestion is about to happen reduce rate before packets start being discarded call this congestion avoidance, instead of congestion control

Two possibilities router-centric: RED Gateways

Explanation in the following slides host-centric: TCP Vegas (guess who?)

Compare measured and expected throughput rate, and shrink congestion window if the measured rate is smaller.


Summary of TCP VersionsRFC 1122 TCP Tahoe TCP Reno TCP Vegas

RTT Estimation X X X X

Karn’s Algorithm X X X X

Slow Start X X X X

AIMD X X X X

Fast Retransmit X X X

Fast Recovery X X

Throughput-rate congestion control

X


Random Early Detection (RED)

Notification is implicit just drop the packet (TCP will timeout)could make explicit by marking the packet

Early random droprather than wait for queue to become full, drop

each arriving packet with some drop probability whenever the queue length exceeds some drop level

Congestion avoidance Global synchronization avoidance


RED Details Compute average queue length

AvgLen = (1 - Weight) * AvgLen + Weight * SampleLen

0 < Weight < 1 (usually 0.002)SampleLen is queue length each time a packet arrives

MaxThreshold MinThreshold

AvgLen


RED Details (cont) Two queue length thresholds

if AvgLen <= MinThreshold then

enqueue the packet

if MinThreshold < AvgLen < MaxThreshold then

calculate probability P

drop arriving packet with probability P

if MaxThreshold <= AvgLen then

drop arriving packet


RED Details (cont) Computing probability P

TempP = MaxP * (AvgLen - MinThreshold)/ (MaxThreshold - MinThreshold)

P = TempP/(1 - count * TempP)

Drop Probability CurveP(drop)

1.0

MaxP

MinThresh MaxThresh

AvgLen

Keep track of how many newly arrivingpackets have been queued while AveLenhas been between the two thresholds

Typically 0.02

Chapter 6, Problem 33

DECbit V.S. RED

Explicit Congestion Avoidance V.S. Implicit Congestion Avoidance



Reviews Queuing disciplines: FIFO FQ TCP congestion control: AIMD, cold/slow start, and fast

retransmit/fast recovery Congestion avoidance: RED and TCP vegas

Exercises in Chapter 6 Ex. 2 (Avoidance) Ex. 6 (Router congestions) Ex. 25(Slow start) Ex. 27 (AIMD, slow start) Ex. 34 (RED)

css432: congestion control 1 css432 congestion control textbook ch6.1 – 6.4 professor: munehiro...

Documents