Lecture 8 Congestion Control EECS 122 University of California - - PowerPoint PPT Presentation

Lecture 8 Congestion Control

EECS 122 University 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 10 10 10 10 10 10 3 3 6 x z y

= 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 10 10 10 10 10 10 3 3 6 x z y

• Assume CD with rate y and EF with rate z
• How does A “discover” the available bandwidth to B?
• Some approaches:
• 1. Reservation
• 2. Adapt to congestion
• 3. Test for sufficient bandwidth
• 4. Pricing congestion

EECS 122 Walrand 8

Questions: Available bandwidth?

Example:

A B C E D F 10 10 10 10 10 10 3 3 6 x z y

• Assume CD with rate y and EF with rate z
• How does A “discover” the available bandwidth to B?
• Some approaches:
• 1. Reservation
• 2. Adapt to congestion
• 3. Test for sufficient bandwidth
• 4. Pricing congestion

EECS 122 Walrand 9

Available bandwidth: Reservation

A B C E D F 10 10 10 10 10 10 3 3 6 x z y

• 1. Routers (or manager) keep track of reserved rates
• 2. A requests a rate R to B from the network
• 3. The network figures out if R is available
• 4. If R is available, routers (or manager) update

reservations and confirm to A

• 5. Note: Complex, Slow, Requires enforcement,

Renegotiations, Pricing

EECS 122 Walrand 10

Available bandwidth: Adapt

A B C E D F 10 10 10 10 10 10 3 3 6 x z y

• 1. Transmit and slow down if congestion occur
• 2. 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 rates
• 3. 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 10 10 10 10 10 10 3 3 6 x z y

• 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 B
• 4. If routers do not mark test packets, then A can start its new

flow; otherwise, A does not start it

• 5. Advantages:
• 1. relatively simple
• 2. guarantee

EECS 122 Walrand 12

Available bandwidth: Pricing

Example:

A B C E D F 10 10 10 10 10 10 3 3 6 x z y

• 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 10 10 10 10 10 10 3 3 6 x z y

• 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: Reservation Transmission 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

Principles Example Multiple Sources A Bad Algorithm: AIAD AIMD: 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 RTT Congestion decrease x by factor 2

A B

x

C = 50 pkts/RTT

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 B

x

C = 50 pkts/RTT

D E

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 RTT Congestion decrease rate by factor 2

Rates equalize fair share y

EECS 122 Walrand 19

TCP Algorithm: Bad Algorithm

A B

x

C = 50 pkts/RTT

D E

No congestion x increases by one packet/RTT every RTT Congestion decrease x by 1

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 B

x

C

D E

y Limit rates: x = y

EECS 122 Walrand 21

TCP Algorithm: Why AIAD Fails

C x y

A B

x

C

D E

y Limit rates: x and y depend

• n initial

values

EECS 122 Walrand 22

Congestion Control: TCP Refinements

Fast Retransmit Fast Recovery: 1st Look Fast Recovery: 2nd Look Slow Start Window Updates Flow Control Summary

EECS 122 Walrand 23

Refinements: Fast Retransmit

n n+1 n+1 n+2 Cumulative ACKs: ACK # = next expected # n+1 n+3 n+1 3rd duplicated ACK: likely packet loss retransmit n+1 timeout

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 1

Moderate 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/2 W = ssthresh + 3 W = W + 1 at each Dup Ack n - 3 W = n + W/2 W/2 outstanding packets: n+1, …, n+W/2 W/2 outstanding packets: n+1, …, n+W/2 W W = ssthresh

EECS 122 Walrand 26

Refinements: Slow Start

Objective: Discover available bdw fast Solution: Exponential increase of window W Timeout 1 n n/2 Threshold 65KB exp exp Additive Slope = 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 = 9 W ? 9 + 9/9 = 10

EECS 122 Walrand 28

Refinements: Flow Control

Objective: Avoid saturating destination Algorithm: 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 bandwidth Congestion Avoidance: AIMD Tries to be fair Refinements:

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 ACK

Flow Control:

Window = min{RAW – OUT, W}