Congestion Control.ppt
-
Upload
elliott-binder -
Category
Documents
-
view
222 -
download
0
Transcript of 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
-
7/21/2019 Congestion Control.ppt
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
-
7/21/2019 Congestion Control.ppt
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
-
7/21/2019 Congestion Control.ppt
4/26
TransportLayer 3-4
idealization: perfectknowledge
! sender sends only whenrouter buffers available
finite shared output
link buffers
!in: original data!out!'in:original data,plus
retransmitted data
copy
free buffer space!
R/2
R/2
!out
!in
Causes/costs of congestion: scenario 2
Host B
A
-
7/21/2019 Congestion Control.ppt
5/26
TransportLayer 3-5
!in: original data!out!'in:original data,plus
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
Causes/costs of congestion: scenario 2
A
Host B
-
7/21/2019 Congestion Control.ppt
6/26
TransportLayer 3-6
!in: original data!out!'in:original data,plus
retransmitted data
free buffer space!
Causes/costs of congestion: scenario 2
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/21/2019 Congestion Control.ppt
7/26
TransportLayer 3-7
A
!in!out!'in
copy
free buffer space!
timeout
R/2
R/2!in
!out
when sending at R/2,some packets are
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
Causes/costs of congestion: scenario 2
-
7/21/2019 Congestion Control.ppt
8/26
TransportLayer 3-8
R/2
!out
when sending at R/2,some packets are
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
Causes/costs of congestion: scenario 2
Realistic: duplicates! packets can be lost, dropped
at router due to full buffers
! sender times out prematurely,sending twocopies, both of
which are delivered
-
7/21/2019 Congestion Control.ppt
9/26
TransportLayer 3-9
! four senders
! multihop paths
! timeout/retransmit
Q:what happens as !inand !in
increase?
finite shared output
link buffers
Host A !out
Causes/costs of congestion: scenario 3
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
-
7/21/2019 Congestion Control.ppt
10/26
TransportLayer 3-10
another costof congestion:
! when packet dropped, any upstreamtransmission capacity used for that packet waswasted!
Causes/costs of congestion: scenario 3
C/2
C/2
!out
!in
-
7/21/2019 Congestion Control.ppt
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
-
7/21/2019 Congestion Control.ppt
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
-
7/21/2019 Congestion Control.ppt
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
-
7/21/2019 Congestion Control.ppt
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
-
7/21/2019 Congestion Control.ppt
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
-
7/21/2019 Congestion Control.ppt
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
-
7/21/2019 Congestion Control.ppt
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
-
7/21/2019 Congestion Control.ppt
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)
-
7/21/2019 Congestion Control.ppt
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
-
7/21/2019 Congestion Control.ppt
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!
-
7/21/2019 Congestion Control.ppt
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
-
7/21/2019 Congestion Control.ppt
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
-
7/21/2019 Congestion Control.ppt
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
-
7/21/2019 Congestion Control.ppt
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
-
7/21/2019 Congestion Control.ppt
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
-
7/21/2019 Congestion Control.ppt
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