http://www.cs.clemson.edu/~mweigle/courses/cpsc360

CPSC 360 - Network Programming

TCP Congestion Control

Michele Weigle

Department of Computer Science

Clemson University

mweigle@cs.clemson.edu

April 8, 2005

Congestion ControlCongestion control vs. Flow control

! In flow control the sender adjusts its transmission rate soas not to overwhelm the receiver"One source is sending data too fast for a receiver to handle

! In congestion control the sender(s) adjust their trans-mission rate so as not to overwhelm routers in thenetwork"Many sources independently work to avoid sending too

much data too fast for the network to handle

! Symptoms of congestion:"Lost packets (buffer overflow at routers)

"Long delays (queuing in router buffers)

Congestion ControlFairness

! When a connection slows down, by how muchshould it slow down?

! If nk connections share a congested link k withcapacity Rk, each connection should receive r =Rk/nk bandwidth

! But what if a connection can’t consume R/nbandwidth?

... ...

k k+1k–1

Rk–1 Rk

Congestion ControlFairness

! A connection can’t consume more bandwidth onlink k than it consumes on any previous link

! If a connection traverses L links then its end-to-endbandwidth is r ! MIN(R1/n1, …, RL/nL) ! Rk/n

! Fairness implies that if there exists a connectionsuch that r ! Rk/n, then the connection’s unusedshare of the bandwidth on link k, Rk/n – r, is evenlyshared with all other connections that are capableof consuming more bandwidth

... ...

k k+1k–1

Rk–1 Rk

Congestion ControlMAX-MIN Fairness

! Consider a set of n connections that consume

r1 ! r2 ! …! rn bits per second of bandwidth

! “Fairness” implies that…

"No connection receives more bandwidth than it requires

" If a connection receives less bandwidth than it requires thenit receives the same amount of bandwidth as all otherunsatisfied connection

Initially each connection gets R/n of a link’s capacity.

R/n +

such

that flows 2 through n receive

of the link’s capacity.

R/n – r1

n – 1

If r1 < R/n then the unused R/n – r1 is reallocated

Congestion ControlMAX-MIN Fairness

! Consider a set of n connections that consume

r1 ! r2 ! …! rn bits per second of bandwidth

! “Fairness” implies that…

"No connection receives more bandwidth than it requires

" If a connection receives less bandwidth than it requires thenit receives the same amount of bandwidth as all otherunsatisfied connection

Initially each connection gets R/n of a link’s capacity.

If r1 < R/n and r2 < R/n + (R/n – r1)/(n–1) then the unused

bandwidth is reallocated such that flows 3 through n

receive

of the link’s capacity.

R/n + + R/n – r1

n – 1

R/n + (R/n – r1)/(n–1) – r2

n – 2

B1B2T3B3 CPU

Router

!in

!in !out

R

2 x !in R

The Causes and Effects of CongestionScenario 1: Two equal-rate senders share a single link

! Two sources send at an average rate of !in to tworeceivers across a shared link with capacity R"Data is delivered to the application at the receiver at rate !out

! Packets queue at the router

"Assume the router has infinite storage capacity(Thus no packets are lost and there are no retransmissions)

R/2

R/2

!in

!o

ut

R/2 !in

Tim

e

Throughput Delay

The Causes and Effects of CongestionScenario 1: Two equal-rate senders share a single link

! The maximum achievable per connection throughput isconstrained by 1/2 the capacity of the shared link

! Exponentially large delays are experienced when therouter becomes congested

"The queue grows without bound

Router

!´in

!´in !out

B1B2T3B3 CPU

R

2 x !´in R

The Causes and Effects of CongestionScenario 2: Finite capacity router queue

! Assume packets can now be lost

"Sender retransmits upon detection of loss

! Define offered load as the original transmissions plusretransmissions" !´in = !in + !retransmit

R/2

R/2

!o

ut

Throughput

R/4

R/3

!´in

Ideal throughput (!in = !´in)

Perfect retransmissions (!out < !´in)(But an extreme loss rate!)

Premature retransmissions (!´in = 2!in)(Each segment transmitted twice)

Premature retransmissions plus loss

The Causes and Effects of CongestionScenario 2: Throughput analysis

! By definition !out = !in

! Retransmission scenarios:

"“Perfect” — Retransmissions occur only when there is loss

"Premature — Delayed packets are retransmitted

!in !inA

C

B

1

3

2

D

!in

!in

4

!What happens as !in and !´in increase?

The Causes and Effects of CongestionScenario 3: Four equal-rate senders share multiple hops

! Each source’straffic transitstwo routers

! Routers havefinite storage

! All links have thesame capacity

! Sendersretransmit lostpackets

!in

!in

A

C

BD

!in

!in

R

If !´in >> Rthen A’s traffic

dominates link 1

1

Eventually!out = 0!

23

4

The Causes and Effects of CongestionScenario 3: Four equal-rate senders share multiple hops

! Throughputincreases linearlyas the networkremainsunderloaded

! At the saturationpoint loss occurs

! Once loss occursthe offered loadincreases

! Loss ratesincrease…

R/2

!o

ut

Throughput

!´inR/2

The Causes and Effects of CongestionScenario 3: Throughput analysis

! Congestion collapse

"All the links are fully utilized but no data is delivered to

applications!

!in

!in

A

C

BD

!in

!in

R

1

23

4

The Causes and Effects of CongestionSummary

! Uncontrolled,congestion can leadto dropped packets

"This means thatbandwidth useddelivering packetsto the point ofcongestion waswasted

! In the limit it canlead to networkcollapse"The network is fully

busy but no workgets done

Approaches to Congestion ControlEnd-to-end v. Hop-by-hop

X

ACK x … ACK x … ACK x“1”

RATE r

! End-to-end congestion control

"End-systems receive no feedback from network

"Congestion inferred by observing loss and/or delay

! Hop-by-hop congestion control"Routers provide feedback to end systems

! Network determines an explicit rate that a sender shouldtransmit at

! Network signals congestion by setting a bit in a packet’s header(SNA, DECbit, TCP/IP ECN, ATM)

throughput = w x MSS

RTTbytes/sec

LastByteSent - LastByteACKed ! MIN(congWin,RcvWindow)

Bytesequence

Sender’s Congestion Window

Sent andACKed

Eligible tobe sent

Sent and notACKed

Ineligible

sendBase (= LastByteACKed + 1)

nextSeqNum (= LastByteSent + 1)

1st

Byte

Last

Byte

!Maximum rate is w MSS byte segmentssent every RTT

End-to-End Congestion ControlTCP Congestion Control

! Transmission rate is limited by the congestion

window size, congWin, or cwnd

w x MSS

RTTbytes/sec

Host A Host B

Time

ACK

datadatadatadata

wMSSbytes

RTTsecs

datadatadatadata

ACK

TCP Congestion ControlCongestion window and transmission rate

! If w " MSS/R < RTT,

then the maximum rate

at which a TCP

connection can transmit

data is

! w is the minimum of the

number of segments in

the receiver’s window or

the congestion window

Bytesequence

Sender’s Congestion Window

1st

Byte

Last

Byte

TCP Congestion ControlCongestion window control

! TCP connections probe for available bandwidth

" Increase the congestion window until loss occurs

" When loss is detected decrease window, then begin probing(increasing) again

! The congestion window grows in two phases:

" Slow start — Ramp up transmission rate until loss occurs

" Congestion avoidance — Keep connection close to sustainablebandwidth

! A window size threshold (bytes transmitted) distinguishesbetween slow start and congestion avoidance phases

TCP Congestion ControlSlowstart

! Exponential increase inwindow size each RTTuntil:"Loss occurs"congWin = threshold

(Not so slow!)

congWin = 1 MSS

for (each original ACK received) congWin++

until (loss event OR congWin > threshold)

Host A

one segment

Host B

Time

two segments

four segments

RT

T

/* slowstart is over;

congWin > threshold

*/

until (loss event) {

whenever congWin segments

ACKed:

congWin++

}

/* loss event timeout */

threshold = congWin/2

congWin = 1 MSS

perform slowstart

Window transmissions

Co

ng

esti

on

win

do

w s

ize

(seg

men

ts)

0 2 4 6 8 10 12 140

2

4

6

8

10

12

1 3 5 7 9 11 13

1

3

5

7

9

11

Threshold

ThresholdLossevent

TCP Congestion ControlCongestion avoidance

! Increase congestion window by 1 segment each RTT,

decrease by a factor of 2 when packet loss is detected

" “Additive Increase, Multiplicative Decrease” (AIMD)

Assume RTT > w x MSS

R

Window transmissionsC

on

ges

tio

n w

ind

ow

siz

e (s

egm

ents

)0 2 4 6 8 10 12 14 16 18 20

0

2

4

6

8

10

12

14

16

18

20

22

24

Initial Threshold is1 MB ! 700 segments

CongestionAvoidance

SlowStart

TCP Congestion ControlSlow-start v. Congestion avoidance

! The threshold is an estimateof a “safe” level of throughputthat is sustainable in thenetwork

" The threshold specifies athroughput that wassustainable in the recentpast

! Slow-start quicklyincreases throughput tothis threshold

! Congestion avoidanceslows probes foradditional availablebandwidth beyond thethreshold

TCP Congestion ControlSlow-start v. Congestion avoidance

! Loss (at any time)reduces the “safe”throughput estimate to1/2 of the currentthroughput" This is the throughput

that resulted in loss

! Slow-start begins anewwhenever there is loss

! Throughput at initialthreshold = 1 MB/RTT" At 1st threshold:

16MSS/RTT

" At 2nd threshold:10MSS/RTT

Window transmissions

Co

ng

esti

on

win

do

w s

ize

(seg

men

ts)

0 2 4 6 8 10 12 14 16 18 200

2

4

6

8

10

12

14

16

18

20

22

24

Initial Threshold is1 MB ! 700 segments

CongestionAvoidance

SlowStart

Assume RTT > w x MSS

R

TCP Congestion ControlMajor TCP variants

! TCP Tahoe:" Loss signaled by timeout

" threshold = congWin/2

" congWin = 1 MSS

" “Fast retransmit”

! receipt of 3 duplicateACKs also signals apacket loss

! TCP Reno:" “Fast recovery”

! skips slowstart andcontinues in congestionavoidance

! new slowstart threshold

! Others: TCP NewReno,SACK, … Assume RTT >

w x MSS

R

Window transmissionsC

on

ges

tio

n w

ind

ow

siz

e (s

egm

ents

)0 2 4 6 8 10 12 14 16 18 20

0

2

4

6

8

10

12

14

16

18

20

22

24

Initial Threshold is1 MB ! 700 segments

CongestionAvoidance

SlowStart