Transport Layer 3-1

Chapter 3
Transport Layer
Computer Networking:
A Top Down Approach
5
th
edition.
Jim Kurose, Keith Ross
Addison-Wesley, April
2009.

A note on the use of these ppt slides:
Were making these slides freely available to all (faculty, students, readers).
Theyre in PowerPoint form so you 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) in substantially unaltered form, that
you mention their source (after all, wed like people to use our book!)
! If you post any slides in substantially unaltered form 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.
Thanks and enjoy! JFK/KWR

All material copyright 1996-2010
J.F Kurose and K.W. Ross, All Rights Reserved
Transport Layer 3-2
Chapter 3 outline
3.1 Transport-layer
services
3.2 Multiplexing and
demultiplexing
3.3 Connectionless
transport: UDP
3.4 Principles of reliable
data transfer
3.5 Connection-oriented
transport: TCP
" segment structure
" reliable data transfer
" flow control
" connection management
3.6 Principles of
congestion control
3.7 TCP congestion control
Transport Layer 3-3
Principles of Congestion Control
Congestion:
! informally: too many sources sending too much
data too fast for network to handle
! different from flow control!
! manifestations:
" lost packets (buffer overflow at routers)
" long delays (queueing in router buffers)
! a top-10 problem!
Transport Layer 3-4
Causes/costs of congestion: scenario 1
! two senders, two
receivers
! one router,
infinite buffers
! no retransmission
! large delays
when congested
! maximum
achievable
throughput
unlimited shared
output link buffers
Host A
!
in
: original data
Host B
!
out

Transport Layer 3-5
Causes/costs of congestion: scenario 2
! one router, finite buffers
! 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, plus
retransmitted data

Transport Layer 3-6
Congestion scenario 2a: ideal case
! sender sends
only when router
buffers available
finite shared output
link buffers
Host A
!
in
: original data
Host B
!
out

!'
in
: original data, plus
retransmitted data
copy
R/2
R/2
!
in
!
o
u
t

free buffer space!
Transport Layer 3-7
Host A
!
in
: original data
Host B
!
out

!'
in
: original data, plus
retransmitted data
copy
no buffer space!
! packets may get
dropped at router due
to full buffers
" sometimes lost
! sender only resends if
packet known to be lost
(admittedly idealized)
Congestion scenario 2b: known loss
Transport Layer 3-8
Congestion scenario 2b: known loss
Host A
!
in
: original data
Host B
!
out

!'
in
: original data, plus
retransmitted data
free buffer space!
! packets may get
dropped at router due
to full buffers
" sometimes not lost
! sender only resends if
packet known to be lost
(admittedly idealized)
R/2
R/2
!
in
!
o
u
t

when sending at R/
2, some packets are
retransmissions but
asymptotic goodput
is still R/2 (why?)
Transport Layer 3-9
! packets may get
dropped at router due
to full buffers
! sender times out
prematurely, sending
two copies, both of
which are delivered
Host A
!
in

Host B
!
out

!'
in

copy
free buffer space!
Congestion scenario 2c: duplicates
timeout
R/2
R/2
!
in
!
o
u
t

when sending at R/
2, some packets are
retransmissions
including duplicated
that are delivered!
Transport Layer 3-10
! packets may get
dropped at router due
to full buffers
! sender times out
prematurely, sending
two copies, both of
which are delivered
Congestion scenario 2c: duplicates
R/2
!
o
u
t

when sending at R/
2, some packets are
retransmissions
including duplicated
that are delivered!
costs of congestion:
! more work (retrans) for given goodput
! unneeded retransmissions: link carries multiple copies of pkt
" decreasing goodput
R/2
!
in
Transport Layer 3-11
Causes/costs of congestion: scenario 3
! four senders
! multihop paths
! timeout/retransmit
!
in
Q: what happens as
and increase ? !
in
finite shared output
link buffers
Host A
!
in
: original data
Host B
!
out

!'
in
: original data, plus
retransmitted data
Transport Layer 3-12
Causes/costs of congestion: scenario 3
another cost of congestion:
! when packet dropped, any upstream transmission
capacity used for that packet was wasted!
H
o
st
A
H
o
st
B
!
o
u
t

Transport Layer 3-13
Transport Layer 3-14
Approaches towards congestion control
end-end congestion
control:
! no explicit feedback from
network
! congestion inferred from
end-system observed loss,
delay
! approach taken by TCP
network-assisted
congestion control:
! routers provide feedback
to end systems
" single bit indicating
congestion (SNA,
DECbit, TCP/IP ECN,
ATM)
" explicit rate sender
should send at
Two broad approaches towards congestion control:
Transport Layer 3-15
Case study: ATM ABR congestion control
ABR: available bit rate:
! elastic service
! if senders path
underloaded:
" sender should use
available bandwidth
! if senders path
congested:
" sender throttled to
minimum guaranteed
rate
RM (resource management)
cells:
! sent by sender, interspersed
with data cells
! bits in RM cell set by switches
(network-assisted)
" NI bit: no increase in rate
(mild congestion)
" CI bit: congestion
indication
! RM cells returned to sender by
receiver, with bits intact

Transport Layer 3-16
Case study: ATM ABR congestion control
! two-byte ER (explicit rate) field in RM cell
" congested switch may lower ER value in cell
" sender send rate thus maximum supportable rate on path
! EFCI bit in data cells: set to 1 in congested switch
" if data cell preceding RM cell has EFCI set, sender sets CI
bit in returned RM cell
Transport Layer 3-17
Chapter 3 outline
3.1 Transport-layer
services
3.2 Multiplexing and
demultiplexing
3.3 Connectionless
transport: UDP
3.4 Principles of reliable
data transfer
3.5 Connection-oriented
transport: TCP
" segment structure
" reliable data transfer
" flow control
" connection management
3.6 Principles of
congestion control
3.7 TCP congestion control
Transport Layer
3-18
TCP congestion control: bandwidth probing
! probing for bandwidth: increase transmission rate
on receipt of ACK, until eventually loss occurs, then
decrease transmission rate
" continue to increase on ACK, decrease on loss (since available
bandwidth is changing, depending on other connections in
network)

ACKs being received,
so increase rate
X
X
X
X
X loss, so decrease rate
s
e
n
d
i
n
g

r
a
t
e

time
! Q: how fast to increase/decrease?
" details to follow
TCPs
sawtooth
behavior
Transport Layer 3-19
TCP Congestion Control: details
! sender limits transmission:
LastByteSent-LastByteAcked
# cwnd
! roughly,

! cwnd is dynamic, function of
perceived network congestion
How does sender
perceive congestion?
! loss event = timeout or
3 duplicate acks
! TCP sender reduces
rate (cwnd) after loss
event
three mechanisms:
" AIMD
" slow start
" conservative after
timeout events
rate =
cwnd
RTT
Bytes/sec
Transport Layer 3-20
TCP Slow Start
! when connection
begins, increase rate
exponentially until
first loss event:
" initially cwnd = 1 MSS
" double cwnd every RTT
" done by incrementing
cwnd for every ACK
received
! summary: initial rate is
slow but ramps up
exponentially fast
Host A
one segm
ent
R
T
T

Host B
time
two segm
ents
four segm
ents
Transport Layer 3-21
Refinement: inferring loss
! after 3 dup ACKs:
" cwnd is cut in half
" window then grows
linearly
! but after timeout event:
" cwnd instead set to 1
MSS;
" window then grows
exponentially
" to a threshold, then
grows linearly
! 3 dup ACKs indicates
network capable of
delivering some segments
! timeout indicates a
more alarming
congestion scenario
Philosophy:
Transport Layer 3-22
Refinement
Q: when should the
exponential
increase switch to
linear?
A: when cwnd gets to
1/2 of its value
before timeout.


Implementation:
! variable ssthresh
! on loss event, ssthresh is
set to 1/2 of cwnd just
before loss event
Transport Layer 3-23
Summary: TCP Congestion Control
timeout
ssthresh = cwnd/2
cwnd = 1 MSS
dupACKcount = 0
retransmit missing segment
$
cwnd > ssthresh
congestion
avoidance

cwnd = cwnd + MSS (MSS/cwnd)
dupACKcount = 0
transmit new segment(s), as allowed

new ACK
.
dupACKcount++

duplicate ACK


fast
recovery

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

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

dupACKcount == 3
timeout
ssthresh = cwnd/2
cwnd = 1
dupACKcount = 0
retransmit missing segment
ssthresh= cwnd/2
cwnd = ssthresh + 3
retransmit missing segment

dupACKcount == 3
cwnd = ssthresh
dupACKcount = 0


New ACK
slow
start
timeout
ssthresh = cwnd/2
cwnd = 1 MSS
dupACKcount = 0
retransmit missing segment
cwnd = cwnd+MSS
dupACKcount = 0
transmit new segment(s), as allowed

new ACK
dupACKcount++

duplicate ACK
$
cwnd = 1 MSS
ssthresh = 64 KB
dupACKcount = 0
New
ACK!
New
ACK!
New
ACK!
Transport Layer 3-24
TCP throughput
! whats the average throughout of TCP as a
function of window size and RTT?
" ignore slow start
! let W be the window size when loss occurs.
" when window is W, throughput is W/RTT
" just after loss, window drops to W/2,
throughput to W/2RTT.
" average throughout: .75 W/RTT
Transport Layer 3-25
TCP Futures: TCP over long, fat pipes
! example: 1500 byte segments, 100ms RTT, want 10
Gbps throughput
! requires window size W = 83,333 in-flight
segments
! throughput in terms of loss rate:



! L = 210
-10
Wow a very small loss rate!
! new versions of TCP for high-speed

L RTT
MSS ! 22 . 1
Transport Layer 3-26
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
router
capacity R
TCP
connection 2
TCP Fairness
Transport Layer 3-27
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
C
o
n
n
e
c
t
i
o
n

2

t
h
r
o
u
g
h
p
u
t

congestion avoidance: additive increase
loss: decrease window by factor of 2
congestion avoidance: additive increase
loss: decrease window by factor of 2
Transport Layer 3-28
Fairness (more)
Fairness and UDP
! multimedia apps often
do not use TCP
" do not want rate
throttled by congestion
control
! instead use UDP:
" pump audio/video at
constant rate, tolerate
packet loss
Fairness and parallel TCP
connections
! nothing prevents app from
opening parallel
connections between 2
hosts.
! web browsers do this
! example: link of rate R
supporting 9 connections;
" new app asks for 1 TCP, gets
rate R/10
" new app asks for 11 TCPs,
gets R/2 !
Transport Layer 3-29
Chapter 3 outline
3.1 Transport-layer
services
3.2 Multiplexing and
demultiplexing
3.3 Connectionless
transport: UDP
3.4 Principles of reliable
data transfer
3.5 Connection-oriented
transport: TCP
" segment structure
" reliable data transfer
" flow control
" connection management
3.6 Principles of
congestion control
3.7 TCP congestion control
+ Bonus on fairness/
resource sharing
Fairness & Computing
! Pascal (died 350 years ago)
" computer pioneer
" Pascals formula
" Pascaline 1
st
mech. calculator
" Also wrote Penses (Thought)
! Et ainsi ne pouvant faire que ce qui est
juste ft fort, on fit que ce qui est fort
ft juste. (fg 135, Raison des effets)
As they could not fortify justice they have justified force.
Transport Layer 3-30
Transport Layer 3-31
TCP connection 1
TCP
connection 2
What is fair?
TCP connection 3
TCP connection 4
Capacity C Capacity C
Capacity C
Resource sharing
! Link l has capacity c
l
! A flow f
i
is traversing a set of link
" We denote by S
l
the set of flows traversing l
" We denote the rate of f
i
by r
i
! Clearly we operate under some constraints
! The main question is how to set r
i
for all f
i
Transport Layer 3-32
Transport Layer 3-33
TCP connection 1
TCP
connection 2
What is fair?
TCP connection 3
TCP connection 4
Capacity C Capacity C
Capacity C
Different feasible allocations
! (r1,r2,r3,r4) = (C/4,C/4,C/4,C/4)
! (r1,r2,r3,r4) = (C/3,C/3,C/3,C/3)
! (r1,r2,r3,r4) = (C/4,C/4,C/2,C/2)
! (r1,r2,r3,r4) = (C/8,C/8 ,C*7/8,C*7/8)
! (r1,r2,r3,r4) = (C/2,C/2,0,0)
! (r1,r2,r3,r4) = (0,0,C,C)
Transport Layer 3-34
Very egalitarian
Equally egalitarian
And intuitively better
Start from egalitarian
Give extra capacity to only some
A variants of
the precedent one
All routers used 100%
Maximum sum of rate = max volume
Some lessons learned
! There are multiple solutions, its not simple.
! Sometimes (like here) flow can be treated
equally, but maybe not always
! Avoiding to leave any capacity unused is a
bad objective (flows 3,4 are starved)
! Maximizing the sum of rates is a bad
objective as well (flows 1,2 are starved)
Transport Layer 3-35
Transport Layer 3-36
In that case, an allocation that seems good is
(r1,r2,r3,r4,r5) = (C/4,C/4,C/2,C/4,C/4)

TCP connection 1
Capacity C
TCP
connection 2
What is fair?
TCP connection 3
TCP connection 4
TCP connection 5
Capacity C
Capacity C
Max-min fairness
! An allocation is max-min fair if an increase
within the domain of feasible allocation
always implies a decrease for a flow with
smaller rate
" (i.e., a poor will have to suffer for a rich)

! r is max-min fair if, for any x feasible
" If we have x
i
>r
i
for a given i
" Then, we necessarily have a flow j such that
x
j
< r
j
! r
i
Transport Layer 3-37
Properties of max-min fairness
! Is a max-min allocation unique?
" Not hard (can you see why?)
! Does a max-min fair solution always exist?
! Let a link l be called a bottleneck for f
i
if
" Link l is saturated and f
i
has maximum rate
among all sources using link l
" Prop: if each flow has a bottleneck, then the
allocation is max-min fair
Transport Layer 3-38
Water-filling algorithms
! A link is said saturated if
" A flow is saturated if it goes through a sat. link
" Let T
l
be the subset of S
l
that are not sat.
1. Choose unsaturated link l that minimizes
2. Increase ALL unsaturated flows by y
l
3. Go back to step 1 until all links are sat.
Transport Layer 3-39
Key idea of the proof
! A flow always increases
" But it is stopped as soon as one of its link is
saturated.
" At this time, no other flow on this link will
increase, and hence this link is a bottleneck
Transport Layer 3-40
Proportional fairness
! An allocation r is proportionally fair if for
any other allocation x we have:
! Roughly speaking You cant increase
someone without someone else losing a
larger fraction of its rate.
" Except that this is the sum of fraction
Transport Layer 3-41
Transport Layer 3-42
TCP connection 1
TCP
connection 2
Example of Prop. Fair
TCP connection 3
TCP connection 4
Capacity C Capacity C
Capacity C
Properties of Prop. Fair
! Is that unique? Does it always exist
! THM: The unique proportional fair
allocation is the value of r that maximizes
! J is a concave function, the constraint
domain is convex, an easy optimization
" Can be obtained through gradient descent
Transport Layer 3-43
More Utilitarian fairness
! Let us define
! Let r be the solution of
subject to capacity
" r is the "-fair allocation
! "=1 : prop. fair, "=2: pot. delay,
" very large: approaches maxmin
Transport Layer 3-44
Does TCP follows any fairness?
! Yes, under some assumptions
" No limit on receiver window
" No slow start (pure AIMD), No time-out
" No delay in ACK transmission and response
" Independent packet losses

We can then justify a fluid approximation proving
that TCP maximizes under capacity constraints


Transport Layer 3-45
Transport Layer 3-46
Chapter 3: Summary
! principles behind transport
layer services:
" multiplexing,
demultiplexing
" reliable data transfer
" flow control
" congestion control
! instantiation and
implementation in the
Internet
" UDP
" TCP
Next:
! leaving the network
edge (application,
transport layers)
! into the network
core