Week 3-2
Week 3-2
Transport
Layer
A note on the use of these PowerPoint slides:
We’re making these slides freely available to all (faculty, students,
readers). They’re in PowerPoint form so you see the animations; and
can add, modify, and delete slides (including this one) and slide content
to suit your needs. They obviously represent a lot of work on our part.
In return for use, we only ask the following:
If you use these slides (e.g., in a class) that you mention their source
(after all, we’d like people to use our book!)
If you post any slides on a www site, that you note that they are
adapted from (or perhaps identical to) our slides, and note our
copyright of this material.
Computer Networking: A
For a revision history, see the slide note for this page.
Top-Down Approach
Thanks and enjoy! JFK/KWR 8th edition
Jim Kurose, Keith Ross
All material copyright 1996-2020
J.F Kurose and K.W. Ross, All Rights Reserved Pearson, 2020
Transport Layer: 3-1
Chapter 3: roadmap
Transport-layer services
Multiplexing and demultiplexing
Connectionless transport: UDP
Principles of reliable data transfer
Connection-oriented transport: TCP
Principles of congestion control
TCP congestion control
Evolution of transport-layer
functionality
Transport Layer: 3-2
Principles of congestion control
Congestion:
informally: “too many sources sending too much data too fast for
network to handle”
manifestations:
• long delays (queueing in router buffers)
• packet loss (buffer overflow at routers)
different from flow control! congestion control:
a top-10 problem! too many senders,
sending too fast
two flows
R R
no retransmissions needed
Host B
R/2
Q: What happens as
lout
arrival rate lin
delay
throughput:
approaches R/2?
lin R/2 lin R/2
maximum per-connection large delays as arrival rate
throughput: R/2 lin approaches capacity
Transport Layer: 3-4
Causes/costs of congestion: scenario 2
one router, finite buffers
sender retransmits lost, timed-out packet
• application-layer input = application-layer output: lin = lout
• transport-layer input includes retransmissions : l’in lin
R R
lout
sender sends only when router buffers available
throughput:
Host A lin : original data lin
copy l'in: original data, plus lout R/2
retransmitted data
R R
no buffer space!
R R
lout
packets can be lost (dropped at router) due to to retransmissions
full buffers
throughput:
when sending at
sender knows when packet has been dropped: R/2, some packets
only resends if packet known to be lost are needed
retransmissions
R R
lout
“wasted” capacity due
full buffers – requiring retransmissions to un-needed
retransmissions
but sender times can time out prematurely,
throughput:
sending two copies, both of which are delivered when sending at
R/2, some packets
are retransmissions,
including needed
Host A lin : original data lin
and un-needed
timeout R/2 duplicates, that are
copy l'in: original data, plus delivered!
retransmitted data
R R
lout
“wasted” capacity due
full buffers – requiring retransmissions to un-needed
retransmissions
but sender times can time out prematurely,
throughput:
sending two copies, both of which are delivered when sending at
R/2, some packets
are retransmissions,
including needed
and un-needed
lin R/2 duplicates, that are
delivered!
“costs” of congestion:
more work (retransmission) for given receiver throughput
unneeded retransmissions: link carries multiple copies of a packet
• decreasing maximum achievable throughput
Host D
lout
Host C
lin’ R/2
router
may indicate congestion level or
explicitly set sending rate
TCP ECN, ATM, DECbit protocols
Transport Layer: 3-15
Chapter 3: roadmap
Transport-layer services
Multiplexing and demultiplexing
Connectionless transport: UDP
Principles of reliable data transfer
Connection-oriented transport: TCP
Principles of congestion control
TCP congestion control
Evolution of transport-layer
functionality
Transport Layer: 3-16
TCP congestion control: AIMD
approach: senders can increase sending rate until packet loss
(congestion) occurs, then decrease sending rate on loss event
Additive Increase Multiplicative Decrease
increase sending rate by 1 cut sending rate in half at
maximum segment size every each loss event
RTT until loss detected
TCP sender Sending rate
AIMD sawtooth
behavior: probing
for bandwidth
Why AIMD?
AIMD – a distributed, asynchronous algorithm – has been
shown to:
• optimize congested flow rates network wide!
• have desirable stability properties
RTT
• initially cwnd = 1 MSS two segm
en ts
• double cwnd every RTT
• done by incrementing cwnd
for every ACK received four segm
ents
Implementation:
variable ssthresh
on loss event, ssthresh is set to
1/2 of cwnd just before loss event
* Check out the online interactive exercises for more examples: h ttp://gaia.cs.umass.edu/kurose_ross/interactive/
Transport Layer: 3-21
Summary: TCP congestion control
new ACK
duplicate ACK
dupACKcount++ new ACK .
cwnd = cwnd + MSS (MSS/cwnd)
dupACKcount = 0
cwnd = cwnd+MSS transmit new segment(s), as allowed
dupACKcount = 0
L transmit new segment(s), as allowed
cwnd = 1 MSS
ssthresh = 64 KB cwnd > ssthresh
dupACKcount = 0
slow L congestion
start timeout avoidance
ssthresh = cwnd/2
cwnd = 1 MSS duplicate ACK
timeout dupACKcount = 0 dupACKcount++
ssthresh = cwnd/2 retransmit missing segment
cwnd = 1 MSS
dupACKcount = 0
retransmit missing segment
timeout
ssthresh = cwnd/2
cwnd = 1 New ACK
dupACKcount = 0
cwnd = ssthresh dupACKcount == 3
dupACKcount == 3 retransmit missing segment dupACKcount = 0
ssthresh= cwnd/2 ssthresh= cwnd/2
cwnd = ssthresh + 3 cwnd = ssthresh + 3
retransmit missing segment
retransmit missing segment
fast
recovery
duplicate ACK
cwnd = cwnd + MSS
transmit new segment(s), as allowed
time
sudo sysctl -a | grep tcp_congestion_control
t0 t1 t2 t3 t4
Transport Layer: 3-24
Delay-based TCP congestion control
Keeping sender-to-receiver pipe “just full enough, but no fuller”: keep
bottleneck link busy transmitting, but avoid high delays/buffering
# bytes sent in
measured last RTT interval
RTTmeasured throughput =
RTTmeasured
Delay-based approach:
RTTmin - minimum observed RTT (uncongested path)
uncongested throughput with congestion window cwnd is cwnd/RTTmin
if measured throughput “very close” to uncongested throughput
increase cwnd linearly /* since path not congested */
else if measured throughput “far below” uncongested throughout
decrease cwnd linearly /* since path is congested */
Transport Layer: 3-25
Explicit congestion notification (ECN)
TCP deployments often implement network-assisted congestion control:
two bits in IP header (ToS field) marked by network router to indicate congestion
• policy to determine marking chosen by network operator
congestion indication carried to destination
destination sets ECE bit on ACK segment to notify sender of congestion
involves both IP (IP header ECN bit marking) and TCP (TCP header C,E bit marking)
source TCP ACK segment
destination
application application
ECE=1
TCP TCP
network network
link link
physical physical
ECN=10 ECN=11
IP datagram
Transport Layer: 3-26
TCP fairness
Fairness goal: if K TCP sessions share same bottleneck link of
bandwidth R, each should have average rate of R/K
TCP connection 1
bottleneck
TCP connection 2 router
capacity R
Connection 1 throughput R
Transport Layer: 3-28
Fairness: must all network apps be “fair”?
Fairness and UDP Fairness, parallel TCP
multimedia apps often do not connections
use TCP application can open multiple
• do not want rate throttled by parallel connections between two
congestion control hosts
instead use UDP: web browsers do this , e.g., link of
• send audio/video at constant rate, rate R with 9 existing connections:
tolerate packet loss • new app asks for 1 TCP, gets rate R/10
there is no “Internet police” • new app asks for 11 TCPs, gets R/2
policing use of congestion
control