Congestion Control.ppt

7/21/2019 Congestion Control.ppt

1/26

TransportLayer 3-1

congestion:! informally: too many sources sending too much

data too fast for networkto handle

! different from flow control!

!

manifestations:

"lost packets (buffer overflow at routers)

"long delays (queueing in router buffers)

! a top-10 problem!

Principles of congestion control


2/26

TransportLayer 3-2

Causes/costs of congestion: scenario 1

!

two senders, tworeceivers

!

one router, infinitebuffers

!

output link capacity: R

! no retransmission

! maximum per-connectionthroughput: R/2

unlimited sharedoutput link buffers

Host A

original data: !in

Host B

throughput:

!out

R/2

R/2

!ou

t

!in R/2

dela

y

!in

! large delays as arrival rate,!in, approaches capacity


3/26

TransportLayer 3-3

! one router, finitebuffers

!

sender retransmission of timed-out packet" application-layer input = application-layer output:!in =!out

"

transport-layer input includes retransmissions :!

in!

in

finite shared output

link buffers

Host A

!in: original data

Host B

!out!'in:original data,plusretransmitted data

Causes/costs of co

ngestion: scenario 2


4/26

TransportLayer 3-4

idealization: perfectknowledge

! sender sends only whenrouter buffers available


link buffers

!in: original data!out!'in:original data,plus

retransmitted data

copy

free buffer space!

R/2

R/2

!out

!in


Host B

A


5/26

TransportLayer 3-5


retransmitted data

copy

no buffer space!

Idealization: known losspackets can be lost,dropped at router dueto full buffers

! sender only resends if

packet knownto be lost


A

Host B


6/26

TransportLayer 3-6


retransmitted data

free buffer space!


Idealization: known losspackets can be lost,dropped at router dueto full buffers

! sender only resends if

packet knownto be lost

R/2

R/2!in

!out

when sending at R/2,some packets are

retransmissions but

asymptotic goodput

is still R/2 (why?)

A

Host B


7/26

TransportLayer 3-7

A

!in!out!'in

copy

free buffer space!

timeout

R/2

R/2!in

!out


retransmissions

including duplicated

that are delivered!

Host B

Realistic: duplicates! packets can be lost, dropped

at router due to full buffers

! sender times out prematurely,sending twocopies, both of

which are delivered



8/26

TransportLayer 3-8

R/2

!out


retransmissions

including duplicated

that are delivered!

costsof congestion:! more work (retrans) for given goodput

! unneeded retransmissions: link carries multiple copies of pkt"

decreasing goodput

R/2!in


Realistic: duplicates! packets can be lost, dropped

at router due to full buffers

! sender times out prematurely,sending twocopies, both of

which are delivered


9/26

TransportLayer 3-9

! four senders

! multihop paths

! timeout/retransmit

Q:what happens as !inand !in

increase?


link buffers

Host A !out


Host B

Host C

Host D

!in: original data

!'in:original data,plusretransmitted data

A:as red !inincreases, all arriving

blue pkts at upper queue aredropped, blue throughput !0


10/26

TransportLayer 3-10

another costof congestion:

! when packet dropped, any upstreamtransmission capacity used for that packet waswasted!


C/2

C/2

!out

!in


11/26

TransportLayer 3-11

Approaches towards congestion control

two broad approaches towards congestion control:

end-end congestion

control:! no explicit feedback

from network

! congestion inferredfrom end-system

observed loss, delay! approach taken by

TCP

network-assisted

congestion control:! routers provide

feedback to end systems

"single bit indicatingcongestion (SNA,

DECbit, TCP/IP ECN,ATM)

"explicit rate forsender to send at


12/26

TransportLayer 3-12

Case study: ATM ABR congestion control

ABR: available bit rate:! elastic service

! if senders pathunderloaded

:" sender should use

available bandwidth

! if senders pathcongested:

"

sender throttled tominimum guaranteedrate

RM (resource management)cells:

! sent by sender, interspersedwith data cells

! bits in RM cell set by switches(network-assisted)

" NI bit:no increase in rate(mild congestion)

" CI bit:congestionindication

! RM cells returned to senderby receiver, with bits intact


13/26

TransportLayer 3-13

Case study: ATM ABR congestion control

! two-byte ER (explicit rate) field in RM cell" congested switch may lower ER value in cell

"

senderssend rate thus max supportable rate on path

! EFCI bit in data cells: set to 1 in congested switch" if data cell preceding RM cell has EFCI set, receiver sets

CI bit in returned RM cell

RM cell data cell


14/26

TransportLayer 3-14

Chapter 3 outline

3.1 transport-layerservices

3.2 multiplexing and

demultiplexing3.3 connectionless

transport: UDP

3.4 principles of reliabledata transfer

3.5 connection-orientedtransport: TCP" segment structure

"reliable data transfer

" flow control

" connection management

3.6 principles of congestioncontrol

3.7 TCP congestion control


15/26

TransportLayer 3-15

TCP congestion control: additive increasemultiplicative decrease

! approach:senderincreases transmission rate (windowsize), probing for usable bandwidth, until loss occurs

"additive increase:increase cwndby 1 MSS everyRTT until loss detected

"

multiplicative decrease:cut cwnd in half after loss

cwnd:

TCP

sender

congestionwin

dows

ize

AIMD saw tooth

behavior: probing

for bandwidth

additively increase window size . until loss occurs (then cut window in half)

time


16/26

TransportLayer 3-16

TCP Congestion Control: details

! sender limits transmission:

! cwndis dynamic, functionof perceived networkcongestion

TCP sending rate:

! roughly:send cwndbytes, wait RTT forACKS, then sendmore bytes

last byteACKed sent, not-

yet ACKed(in-flight)

last bytesent

cwnd

LastByteSent-

LastByteAcked

< cwnd

sender sequence number space

rate ~~cwnd

RTTbytes/sec


17/26

TransportLayer 3-17

TCP Slow Start

! when connection begins,increase rateexponentially until firstloss event:

"

initially cwnd= 1 MSS" double cwndevery RTT

" done by incrementingcwndfor every ACKreceived

! summary: initial rate isslow but ramps upexponentially fast

Host A

onesegment

RTT

Host B

time

twosegments

foursegments


18/26

TransportLayer 3-18

TCP: detecting, reacting to loss

! loss indicated by timeout:"cwndset to 1 MSS;

"window then grows exponentially (as in slow start)

to threshold, then grows linearly! loss indicated by 3 duplicate ACKs: TCP RENO"dup ACKs indicate network capable of delivering

some segments

"

cwndis cut in half window then grows linearly! TCP Tahoe always sets cwndto 1 (timeout or 3

duplicate acks)


19/26

TransportLayer 3-19

Q:when should theexponentialincrease switch tolinear?

A:when cwndgets

to 1/2 of its valuebefore timeout.

Implementation:! variable ssthresh

! on loss event, ssthreshis set to 1/2 of cwndjustbefore loss event

TCP: switching from slow start to CA


20/26

TransportLayer 3-20

Summary: TCP Congestion Control

timeout

ssthresh = cwnd/2cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

"

cwnd > ssthresh

congestionavoidance

cwnd = cwnd + MSS (MSS/cwnd)dupACKcount = 0

transmit new segment(s), as allowed

new ACK.

dupACKcount++

duplicate ACK

fastrecovery

cwnd = cwnd + MSStransmit new segment(s), as allowed

duplicate ACK

ssthresh= cwnd/2cwnd = ssthresh + 3

retransmit missing segment

dupACKcount == 3

timeout

ssthresh = cwnd/2cwnd = 1dupACKcount = 0retransmit missing segment

ssthresh= cwnd/2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3cwnd = ssthreshdupACKcount = 0

New ACK

slowstart

timeout

ssthresh = cwnd/2cwnd = 1 MSS

dupACKcount = 0retransmit missing segment

cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s), as allowed

new ACKdupACKcount++

duplicate ACK

"

cwnd = 1 MSSssthresh = 64 KBdupACKcount = 0

NewACK!

NewACK!

NewACK!


21/26

TransportLayer 3-21

TCP throughput

!

avg. TCP thruput as function of window size, RTT?" ignore slow start, assume always data to send

! W: window size (measured in bytes)where loss occurs" avg. window size (# in-flight bytes) is !W

"

avg. thruput is 3/4W per RTT

W

W/2

avg TCP thruput =34

WRTT

bytes/sec


22/26

TransportLayer 3-22

TCP Futures: TCP over long, fat pipes

! example: 1500 byte segments, 100ms RTT, want10 Gbps throughput

! requires W = 83,333 in-flight segments

! throughput in terms of segment loss probability, L[Mathis 1997]:

to achieve 10 Gbps throughput, need a loss rate of L= 210-10 a very small loss rate!

! new versions of TCP for high-speed

TCP throughput =1.22 . MSS

RTT L


23/26

TransportLayer 3-23

fairness goal:if K TCP sessions share samebottleneck link of bandwidth R, each should haveaverage rate of R/K

TCP connection 1

bottleneck

routercapacity R

TCP Fairness

TCP connection 2


24/26

TransportLayer 3-24

Why is TCP fair?

two competing sessions:! additive increase gives slope of 1, as throughout increases

! multiplicative decrease decreases throughput proportionally

R

R

equal bandwidth share

Connection 1 throughput

Conne

ctio

n2throughput

congestion avoidance: additive increase

loss: decrease window by factor of 2

congestion avoidance: additive increaseloss: decrease window by factor of 2


25/26

TransportLayer 3-25

Fairness (more)

Fairness and UDP! multimedia apps often

do not use TCP" do not want rate

throttled by congestioncontrol

!

instead use UDP:" send audio/video at

constant rate, tolerate

packet loss

Fairness, parallel TCPconnections

! application can openmultiple parallel

connections between twohosts

!

web browsers do this

! e.g., link of rate R with 9

existing connections:" new app asks for 1 TCP, gets rate

R/10

" new app asks for 11 TCPs, gets R/2


26/26

TransportLayer 3-26

Chapter 3: summary

! principles behindtransport layer services:

"multiplexing,demultiplexing

"

reliable data transfer"flow control

"congestion control

! instantiation,

implementation in theInternet" UDP

" TCP

next:

! leaving thenetworkedge(application, transport layers)

! into the network

core

Documents

Congestion Control.ppt