Anda di halaman 1dari 35

Unit 20

Congestion Control

Acknowledgments: These slides were originally developed by Prof. Jean Walrand for EE122.
The past and current EE122 instructors including Profs. Kevin Fall, Abhay Parekh, Shyam Parekh,
and Adam Wolisz have contributed to their evolution.

Congestion Control







The Problem
Questions
Approaches
TCP: Algorithm
TCP Refinements
Summary

TOC Congestion Control

The Problem


Flows share links:

How to share the links bandwidth?


TOC Congestion Control - The Problem

Questions


What should be the ideal sharing?






Does it matter?
Discovering available bandwidth
What is fair?

TOC Congestion Control - Questions

Does it matter?


Congestion occurs


Access link


Access network


Slow link (56k, DSL, T1, wireless, )


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

TOC Congestion Control - Questions 1

Questions: Available bandwidth?




Example:
x
A

10

10
C
y

10
E z

= router
3

10
D

= host

= link with bandwidth of 3Mbps


(same for 6 and 10)

x, y, z = throughput of flows
TOC Congestion Control - Questions 2

10
F

10

Questions: Available bandwidth?




Example:
x
A

10

10
C
y

10
E z

10
D

10
F

10

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
TOC Congestion Control - Questions 2

Questions: Available bandwidth?


x
A

10

10
C
y

10
E z

10
D

10
F

10

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
TOC Congestion Control - Questions 3

Available bandwidth: Reservation


x
A

10

10
C
y

10
E z

1.
2.
3.
4.

10
D

10
F

10

Routers (or manager) keep track of reserved rates


A requests a rate R to B from the network
The network figures out if R is available
If R is available, routers (or manager) update
reservations and confirm to A
5. Note: Complex, Slow, Requires enforcement,
Renegotiations, Pricing
TOC Congestion Control - Questions 3.1 Reserve

Available bandwidth: Adapt


x
A

10

10
C
y

10
E z

10
D

10
F

10

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
TOC Congestion Control - Questions 3.2 Adapt

Available bandwidth: Test


x
A

10

10
C
y

10
E z

10
D

10
F

10

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
TOC Congestion Control - Questions 3.3 Test

Available bandwidth: Pricing


x
A

10

10
C
y

10
E z

10
D

10
F

10

When they get saturated, routers mark packets


If a flow with rate R uses a saturated link, it gets marks with
rate R (multiple saturated links result in multiple marks)
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
TOC Congestion Control - Questions 3.4 Pricing

Questions: What is Fair?




Example:
x
A

10

10
C
y

10
E z

10
D

10
F

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)
TOC Congestion Control - Questions 3.5 Fair?

10

Congestion Control: Approaches





Telephone Network: Reservation


Transmission Control Protocol (TCP)



User Datagram Protocol (UDP)




Adapt rate to congestion


Algorithm for adaptation attempts to be fair
Transmit and hope for the best

Various proposals for Internet:







Reservation
Pricing
Test
Note: Either by hosts or between domains

TOC Congestion Control - Approaches

Congestion Control: TCP Algorithm

Principles
Example
Multiple Sources
A Bad Algorithm: AIAD
AIMD: Additive Increase Multiplicative Decrease

Why AIAD Fails






TOC Congestion Control - TCP Algorithm

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

TOC Congestion Control - TCP Algorithm Principles

TCP Algorithm: Example


x

A



C = 50 pkts/RTT

No congestion  x increases by one packet/RTT every RTT


Congestion  decrease x by factor 2
Rate (pkts/RTT)

60
50
40
30

Backlog in router (pkts)


Congested if > 20

20
10

TOC Congestion Control - TCP Algorithm Example

487

460

433

406

379

352

325

298

271

244

217

190

163

136

109

82

55

28

TCP Algorithm: Multiple


Sources
C = 50 pkts/RTT
x
y

D



No congestion  rate increases by one packet/RTT every RTT


Congestion  decrease rate by factor 2
60

Rates equalize  fair share

50
40
30
20
10

TOC Congestion Control - TCP Algorithm Multiple Sources

487

460

433

406

379

352

325

298

271

244

217

190

163

136

109

82

55

28

TCP Algorithm: Bad Algorithm


x

D


C = 50 pkts/RTT

No congestion  x increases by one packet/RTT every RTT


Congestion  decrease x by 1
60
50
40
30
20
10

TOC Congestion Control - TCP Algorithm Bad

487

460

433

406

379

352

325

298

271

244

217

190

163

136

109

82

55

28

TCP Algorithm: AIMD


A
D
C

Limit rates:
x=y

x
TOC Congestion Control - TCP Algorithm AIMD

TCP Algorithm: Why AIAD Fails


A
D

y
C
Limit rates:
x and y depend
on initial
values

x
TOC Congestion Control - TCP Algorithm Why AIAD Fails

Congestion Control: TCP


Refinements









TCP Phases
Slow Start and Congestion Avoidance
Fast Retransmit
Fast Recovery: 1st Look
Fast Recovery: 2nd Look
Window Updates
Flow Control
Summary

TOC Congestion Control - TCP Refinements

TCP Phases


Slow Start


While (W Slow Start Threshold)





W = W + 1 for each new ack


Recovery Mechanism: Timeout

Congestion Avoidance


While (W > Slow Start Threshold)





W = W + 1/W for each new ack


Recovery Mechanism: Fast Transmit/Recovery and
Timeout

We next examine the details of the above phases

Refinements:




Slow Start & Congestion Avoidance

Objective: Discover available BW quickly


Solution: Exponential increase of window (Slow Start)
Probing for more BW: Additive increase (Congestion Avoidance)

64KB
W

Threshold
n

Slow Start

Congestion
Avoidance

n/2
exp

Additive
Slope = 1/RTT

exp

1
Timeout
TOC Congestion Control - TCP Refinements Slow Start

Refinements: Fast Retransmit

timeout

n
n+1
n+2
n+3
n+4
n+1
n+1
n+1
n+1
n+1

Cumulative ACKs:
ACK # = next expected #

3rd duplicated ACK:


 likely packet loss
 retransmit

TOC Congestion Control - TCP Refinements Fast Retransmit

Refinements: Fast Recovery (1)





Timeout  Reset Window = 1 unit (MSS)


3rd Dup ACK  Window/2

Window

3rd Dup ACK

Slope =
1 MSS/RTT

Timeout

n/2
1
Moderate congestion
Severe congestion
(subsequent pkts arrived)
TOC Congestion Control - TCP Refinements Fast Recovery 1

Refinements: Fast Recovery (2)




Window adjustment is tricky:


Want W  W/2

W
W == W
W first
first 22 DA
DA (Dup
(Dup Ack)
Ack)
rd
At
3
At 3rd DA:
DA:
ssthresh
ssthresh == W/2
W/2
W
W == ssthresh
ssthresh ++ 33
rd
W
W == W
W ++ 11 at
at each
each DA
DA after
after 33rd DA
DA

W/2 + 3
W

n+1
n+W

W/2 1 outstanding
packets:
n+W+1, , n+3W/21

W
W=
= ssthresh
ssthresh
n+W+1

W
W 44 acks
acks
(W/2
(W/2 ++ 3)
3) ++ (W
(W 4)
4)
== W
W ++ W/2
W/2 11

3rd DA
n+1
TOC Congestion Control - TCP Refinements Fast Recovery 2

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

TOC Congestion Control - TCP Refinements Window Updates

Congestion Example
(Source: TCP/IP Illustrated - I, W.
Stevens)

Congestion Example (Contd)


(Source: TCP/IP Illustrated - I, W.
Stevens)

Refinements: Flow Control





Objective: Avoid saturating destination


Algorithm: Receiver advertises window RAW

actual window = min {RAW, W}


actual window open = actual window - OUT
where
OUT = Outstanding = Last sent last ACKed
W = Cong. Window from AIMD + refinements
RAW
[ACK | RAW | ]
TOC Congestion Control - TCP Refinements Flow Control

Refinements: Summary
Actual window = min {RAW, W}

64KB
W
3DA
0.5

3DA
0.5

0.5

TO

TO

0.5

1
SS

CA

TOC Congestion Control - TCP Refinements Summary

SS

CA

Congestion Control: Summary






Slow Start: Discover available bandwidth


Congestion Avoidance: AIMD  Tries to be fair
Refinements:



Timers:



Fast Retransmit: 3rd DA


Fast Recovery: Reset W to W/2 (instead of W = 1)
[More precisely: ssthresh = W/2, W = ssthresh + 3,
W = W + 1 per DA after 3rd DA,
W = ssthresh when get new ACK]
TO: set ssthresh = W/2, W = 1, SS until W = ssthresh,
then CA
Timeout = Average + 4 Deviations
If time out  Timeout x 2 (up to a maximum)
Reset after new ACK

Flow Control:


Actual window = min {RAW, W}

TOC Congestion Control - Summary

TCP Timers


Retransmission Timer: We have discussed


this earlier
Persist Timer: Uses window probes to avoid
deadlock after the receiver closes its receive
window size
Keepalive Timer: Server sends a probe
packet after the connection has been idle for
a while (Its controversial and is not part of
TCP specification)
2MSL Timer: We have discussed this earlier

Special TCP Considerations




Silly Window Syndrome (SWS): Occurs when small


amounts of data are exchanged instead of full-sized
segments


To avoid SWS

Receiver should not advertise small windows


Sender should avoid sending small segments (see the textbook
and Stevens for details)
Nagles algorithm allows a sender to have only one outstanding
small segment

Karns algorithm: Do not update the RTT estimators


when the acknowledgement for the retransmitted
data arrives

Anda mungkin juga menyukai