Lecture 8 Congestion Control EECS 122 University of California Berkeley.

Lecture 8Congestion Control

EECS 122University of California

Berkeley

EECS 122 Walrand 2

TOC: Congestion Control The Problem Questions Approaches TCP: Algorithm TCP Refinements Summary

EECS 122 Walrand 3

Congestion Control: The Problem

Flows share links:

How to share the links bandwidth?

EECS 122 Walrand 4

Congestion Control: Questions

What should be the ideal sharing? Does it matter? Discovering available bandwidth What is fair?

EECS 122 Walrand 5

Questions: Does it matter?

Congestion occurs Access link

Slow link (56k, DSL, T1, wireless, …) Access network

E.g., behind the DSLAM

Can improve treatment of flows E.g., one flow should not get a much

smaller fraction of bandwidth Some flows might need some

guaranteed bandwidth

EECS 122 Walrand 6

Questions: Available bandwidth?

Example:

A B

C E D F

1010 10 10 10

103 36

x

zy

= router = host

3 = link with bandwidth of 3Mbps(same for 6 and 10)

x, y, z = throughput of flows

EECS 122 Walrand 7

Questions: Available bandwidth?

Example:

A B

C E D F

1010 10 10 10

103 36

x

zy

• Assume CD with rate y and EF with rate z• How does A “discover” the available bandwidth to B?• Some approaches:

1. Reservation2. Adapt to congestion3. Test for sufficient bandwidth4. Pricing congestion

EECS 122 Walrand 8

Questions: Available bandwidth?

Example:

A B

C E D F

1010 10 10 10

103 36

x

zy

• Assume CD with rate y and EF with rate z• How does A “discover” the available bandwidth to B?• Some approaches:

1. Reservation2. Adapt to congestion3. Test for sufficient bandwidth4. Pricing congestion

EECS 122 Walrand 9

Available bandwidth: Reservation

A B

C E D F

1010 10 10 10

103 36

x

zy

1. Routers (or manager) keep track of reserved rates

2. A requests a rate R to B from the network3. The network figures out if R is available4. If R is available, routers (or manager) update

reservations and confirm to A5. Note: Complex, Slow, Requires enforcement,

Renegotiations, Pricing

EECS 122 Walrand 10

Available bandwidth: Adapt

A B

C E D F

1010 10 10 10

103 36

x

zy

1. Transmit and slow down if congestion occur2. Example:

• Initially: x= 0, y = 3, z = 3• Then A increases its rate; C and E notice

congestion and slow down

• Later, C stops: A and E increase rates3. Notes:

• No guarantees: throughput may drop• Key question: how to adapt rates

EECS 122 Walrand 11

Available bandwidth: Test

A B

C E D F

1010 10 10 10

103 36

x

zy

1. Assume flows require at most 1Mbps (e.g., video)2. Routers monitor their rates to see if they have at

least 1 Mbps of available bandwidth; they mark packets otherwise

3. If A wants a new flow to B, it sends test packets to B4. If routers do not mark test packets, then A can start

its new flow; otherwise, A does not start it5. Advantages:

1. relatively simple2. guarantee

EECS 122 Walrand 12

Available bandwidth: Pricing

Example:

A B

C E D F

1010 10 10 10

103 36

x

zy

• When they get saturated, routers mark packets

• If a flow with rate R uses saturated links, it gets marks with rate R

• Each mark costs one unit• Source slows down if price becomes

excessive• x= 1+, y = 2+, z = 2+

pA = 1 + 1; pC = pE = 2• x = 2+, y = 1+, z = 1+

pA = 2 + 2; pC = pE = 1

EECS 122 Walrand 13

Questions: What is Fair?

Example:

A B

C E D F

1010 10 10 10

103 36

x

zy

• x = y = z = 1.5: fair in max-min sense

• x = 0, y = z = 3: maximizes x + y + z

• 5x = 4y = 4z: equalizes resources flows use with x = 1.33, y = z = 1.67

• What if AB needs 2Mbps?(and is willing to pay for it)

EECS 122 Walrand 14

Congestion Control: Approaches

Telephone Network: ReservationTransmission Control Protocol (TCP) Adapt rate to congestion Algorithm for adaptation attempts to be fair …User Datagram Protocol (UDP) Transmit and hope for the best

Various proposals for Internet: Reservation Pricing Test Note: Either by hosts or between domains

EECS 122 Walrand 15

Congestion Control: TCP Algorithm

PrinciplesExampleMultiple SourcesA Bad Algorithm: AIADAIMD: Additive Increase – Multiplicative Decrease

Why AIAD Fails

EECS 122 Walrand 16

TCP Algorithm: Principles

We focus on the “standard” TCP (reno)Idea: Not congested => increase rate Congested => slow down

Questions: How to detect congestion?

Missing ACKs How to increase/slow down?

AIMD

EECS 122 Walrand 17

TCP Algorithm: Example

No congestion x increases by one packet/RTT every RTTCongestion decrease x by factor 2

A Bx

C = 50 pkts/RTT

0

10

20

30

40

50

60

1 28 55 82 109

136

163

190

217

244

271

298

325

352

379

406

433

460

487

Backlog in router (pkts)Congested if > 20

Rate (pkts/RTT)

EECS 122 Walrand 18

TCP Algorithm: Multiple Sources

A Bx

C = 50 pkts/RTT

D E

0

10

20

30

40

50

60

1 28 55 82 109

136

163

190

217

244

271

298

325

352

379

406

433

460

487

No congestion rate increases by one packet/RTT every RTTCongestion decrease rate by factor 2

Rates equalize fair share

y

EECS 122 Walrand 19

TCP Algorithm: Bad Algorithm

A Bx

C = 50 pkts/RTT

D ENo congestion x increases by one packet/RTT every RTTCongestion decrease x by 1

0

10

20

30

40

50

60

1 28 55 82 109

136

163

190

217

244

271

298

325

352

379

406

433

460

487

y

EECS 122 Walrand 20

TCP Algorithm: AIMD

C

x

y

A Bx

C

D Ey

Limit rates:x = y

EECS 122 Walrand 21

TCP Algorithm: Why AIAD Fails

C

x

y

A Bx

C

D Ey

Limit rates:x and y depend

on initial values

EECS 122 Walrand 22

Congestion Control: TCP Refinements

Fast RetransmitFast Recovery: 1st LookFast Recovery: 2nd LookSlow StartWindow UpdatesFlow ControlSummary

EECS 122 Walrand 23

Refinements: Fast Retransmit

n

n+1

n+1n+2

Cumulative ACKs: ACK # = next expected #

n+1

n+3

n+13rd duplicated ACK: likely packet loss retransmitn+1

timeou

t

EECS 122 Walrand 24

Refinements: Fast Recovery (1)

Timeout Reset Window = 1 unit (MSS)3rd Dup ACK Window/2

Window

Slope =1 MSS/RTT

3rd Dup ACK

n

n/2

Timeout

1Moderate congestion

(subsequent pkts arrived)Severe congestion

EECS 122 Walrand 25

Refinements: Fast Recovery (2)

Window adjustment is tricky: Want W W/2

1 n

ssthresh = W/2W = ssthresh + 3W = W + 1 at each Dup Ack

ssthresh = W/2W = ssthresh + 3W = W + 1 at each Dup Ack

n - 3

W = n + W/2W = n + W/2

W/2 outstandingpackets:

n+1, …, n+W/2

W/2 outstandingpackets:

n+1, …, n+W/2

W W = ssthreshW = ssthresh

EECS 122 Walrand 26

Refinements: Slow Start

Objective: Discover available bdw fastSolution: Exponential increase of window

W

Timeout

1

n

n/2

Threshold65KB

exp exp

AdditiveSlope = 1/RTT

EECS 122 Walrand 27

Refinements: Window Updates

Exponential: W = W + 1 at each ACK:W = 1 W = 2 W = 4 W = 8

Additive: W = W + 1/W at each ACK:

W = 8

W = 8 + 1/8

W = 8.125 + 1/8.125 8 + 2/8

W 8 + 8/8 = 9W 9 + 9/9 = 10

EECS 122 Walrand 28

Refinements: Flow Control

Objective: Avoid saturating destinationAlgorithm: Receiver avertizes window RAW

RAW

window = min{RAW – OUT, W}where OUT = Oustanding = Last sent – last ACKed W = Cong. Window from AIMD + refinements

[ACK | RAW | …]

EECS 122 Walrand 29

Refinements: Summary

W

1

65KB

Actual window = min{RAW - OUT, W}

X0.5

TO

3DA

X0.5

3DA TO

X0.5 X0.5

SS CA SS CA

3 3

EECS 122 Walrand 30

Congestion Control: Summary

Slow Start: Discover available bandwidthCongestion Avoidance: AIMD Tries to be fairRefinements: Fast Retransmit: 3DA Fast Recovery: Reset W to W/2 (instead of W = 1)

[More precisely: ssthresh = W/2, W = W + 1 per DA, W = ssthresh when get new ACK.]

TO: set ssthresh = W/2, W = 1, SS until W = ssthresh, then CA

Timers: Timeout = Average + 4 Deviations If time out Timeout x 2

Reset after new packet or new ACKFlow Control: Window = min{RAW – OUT, W}