Chapter 3

Transport
Layer
Computer
Networking: A Top-
Down Approach
8th edition
Jim Kurose, Keith Ross
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
• segment structure
• reliable data transfer
• flow control
• connection management
 Principles of congestion control
 TCP congestion control

Transport Layer: 3-2

TCP connection management
before exchanging data, sender/receiver “handshake”:
 agree to establish connection (each knowing the other willing to establish
connection)
 agree on connection parameters (e.g., starting seq #s)

application application

connection state: connection state:

ESTAB ESTAB
connection variables: connection Variables:
seq # client-to- seq # client-to-
server server
server-to-client server-to-client
rcvBuffer size rcvBuffer size
network
at server,client at network
server,client

Socket clientSocket = Socket connectionSocket =

newSocket("hostname","port number"); welcomeSocket.accept();
Transport Layer: 3-3
Agreeing to establish a connection
2-way handshake:
Q: will 2-way handshake always work in
network?
Let’s talk  variable delays
ESTAB  retransmitted messages (e.g.
OK
ESTAB req_conn(x)) due to message loss
 message reordering
 can’t “see” other side

choose x
req_conn(x)
ESTAB
acc_conn(x)
ESTAB

Transport Layer: 3-4

 2-way handshake scenarios
choose x
req_conn(x)
ESTAB
acc_conn(x)

ESTAB
data(x+1) accept
data(x+1
ACK(x+1)
)
connection
x completes

No problem!

Transport Layer: 3-5

2-way handshake scenarios

choose x
req_conn(x)
ESTAB
retransmit acc_conn(x)
req_conn(
x)
ESTAB
req_conn(x)

connection
client x completes server
terminat forgets x
es

ESTAB
acc_conn(x)
Problem: half open
connection! (no client)
Transport Layer: 3-6
2-way handshake scenarios
choose x
req_conn(x)
ESTAB
retransmit acc_conn(x)
req_conn(
x)
ESTAB
data(x+1) accept
data(x+1
retransmit )
data(x+1)
connection
x completes server
client
terminat forgets x
es req_conn(x)
ESTAB
data(x+1) accept
data(x+1
)
Problem: dup data
accepted!
A human 3-way handshake protocol

1. On belay?

2. Belay on.
3. Climbing.

Transport Layer: 3-8

 TCP 3-way handshake
Server state
serverSocket = socket(AF_INET,SOCK_STREAM)
Client state serverSocket.bind((‘’,serverPort))
serverSocket.listen(1)
clientSocket = socket(AF_INET, SOCK_STREAM) connectionSocket, addr = serverSocket.accept()
LISTEN
clientSocket.connect((serverName,serverPort)) LISTEN
choose init seq num, x
send TCP SYN msg
SYNSENT SYNbit=1, Seq=x
choose init seq num, y
send TCP SYNACK
msg, acking SYN SYN RCVD
SYNbit=1, Seq=y
ACKbit=1; ACKnum=x+1
received SYNACK(x)
ESTAB indicates server is live;
send ACK for SYNACK;
this segment may contain ACKbit=1, ACKnum=y+1
client-to-server data
received ACK(y)
indicates client is live
ESTAB

Transport Layer: 3-9

TCP 3-way handshake FSM
closed
Socket connectionSocket =
welcomeSocket.accept();
L Socket clientSocket =
newSocket("hostname","port number");
SYN(x)
SYN(seq=x)
SYNACK(seq=y,ACKnum=x+1)
create new socket for
communication back to client listen

SYN
SYN sent
rcvd

ESTAB SYNACK(seq=y,ACKnum=x+1)
ACK(ACKnum=y+1)
ACK(ACKnum=y+1)
L

Transport Layer: 3-10

Closing a TCP connection
 client, server each close their side of connection
• send TCP segment with FIN bit = 1
 respond to received FIN with ACK
• on receiving FIN, ACK can be combined with own FIN
 simultaneous FIN exchanges can be handled

Transport Layer: 3-11

Closing a TCP connection
client state server state
ESTAB ESTAB
clientSocket.close()
FIN_WAIT_1 can no longer FINbit=1, seq=x
send but can
receive data CLOSE_WAIT
ACKbit=1; ACKnum=x+1
can still
FIN_WAIT_2 wait for server send data
close

LAST_ACK
FINbit=1, seq=y
TIMED_WAIT can no longer
send data
ACKbit=1; ACKnum=y+1
timed wait
for 2*max CLOSED
segment lifetime

CLOSED

Transport Layer: 3-12

TCP throughput
 avg. TCP thruput as function of window size, RTT?
• ignore slow start, assume there is 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

3 W
avg TCP thruput = bytes/sec
4 RTT
W

W/2
TCP over “long, fat pipes”
 example: 1500 byte segments, 100ms RTT, want 10 Gbps throughput
 requires W = 83,333 in-flight segments
 throughput in terms of segment loss probability, L [Mathis 1997]:
1.22 . MSS
TCP throughput =
RTT L
➜ to achieve 10 Gbps throughput, need a loss rate of L = 2·10-10 – a very small
loss rate!
 versions of TCP for long, high-speed scenarios

Transport Layer: 3-14

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-15

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

flow control: one

sender too fast for one
receiver
Transport Layer: 3-16
Causes/costs of congestion: scenario 1
original data: lin throughput: lout
Simplest scenario:
Host A
 one router, infinite buffers
 input, output link capacity: R infinite shared
output link buffers
 two flows
 no retransmissions R R
needed
Host B

R/2
Q: What happens as
arrival rate lin lout large delays as

delay
throughput:
approaches R/2? arrival rate lin
approaches capacity

lin R/2 lin R/2

maximum per-connection
throughput: R/2
Transport Layer: 3-17
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

Host A lin : original data

l'in: original data, plus lout
retransmitted data

R R

Host B finite shared output

link buffers
Transport Layer: 3-18
Causes/costs of congestion: scenario 2
Idealization: perfect knowledge R/2
 sender sends only when router buffers available

lout
throughput:
Host A lin : original data lin
copy l'in: original data, plus lout R/2

retransmitted data

free buffer space!

R R

Host B finite shared output

link buffers
Transport Layer: 3-19
Causes/costs of congestion: scenario 2
Idealization: some perfect knowledge
 packets can be lost (dropped at router) due
to full buffers
 sender knows when packet has been
dropped: only resends if packet known to be
lost

Host A lin : original data

copy l'in: original data, plus
retransmitted data

no buffer space!

R R

Host B finite shared output

link buffers
Transport Layer: 3-20
Causes/costs of congestion: scenario 2
Idealization: some perfect knowledge R/2
“wasted”
 packets can be lost (dropped at router) due

lout
capacity due to
to full buffers retransmissions

throughput:
 sender knows when packet has been when sending
dropped: only resends if packet known to be at R/2, some
lost packets are
needed
retransmission
s
Host A lin : original data lin R/2
l'in: original data, plus
retransmitted data

free buffer space!

R R

Host B finite shared output

link buffers
Transport Layer: 3-21
Causes/costs of congestion: scenario 2
Realistic scenario: un-needed duplicates
R/2
 packets can be lost, dropped at router due

lout
“wasted”
to full buffers – requiring retransmissions capacity due to
 but sender times can time out un-needed

throughput:
retransmissions
prematurely, sending two copies, both of
when sending at
which are delivered R/2, some packets
are retransmissions,
including needed
and un-needed
Host A lin : original data lin
copy R/2 duplicates, that are
timeout
l'in: original data, plus delivered!
retransmitted data

free buffer space!

R R

Host B finite shared output

link buffers
Transport Layer: 3-22
Causes/costs of congestion: scenario 2
Realistic scenario: un-needed duplicates
 packets can be lost, dropped at router due to R/2

lout
full buffers – requiring retransmissions “wasted”
capacity due to
 but sender times can time out prematurely, un-needed

throughput:
sending two copies, both of which are retransmissions
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

Transport Layer: 3-23

Causes/costs of congestion: scenario 3
 four senders Q: what happens as lin and lin’ increase ?
 multi-hop paths
A: as red lin’ increases, all arriving blue pkts at upper
 timeout/retransmit queue are dropped, blue throughput g 0

Host A lin : original data

Host B
l'in: original data, plus
retransmitted data

finite shared
output link buffers

Host D
lout
Host C

Transport Layer: 3-24

Causes/costs of congestion: scenario 3
R/2
lout

lin’ R/2

another “cost” of congestion:

 when packet dropped, any upstream transmission capacity
and buffering used for that packet was wasted!

Transport Layer: 3-25

Causes/costs of congestion: insights
R/2

 throughput can never exceed capacity

throughput: lout
lin R/2
 delay increases as capacity approached

delay
R/2
lin R/2

throughput: lout
 loss/retransmission decreases effective
throughput
lin R/2 R/2

 un-needed duplicates further decreases

throughput: lout
effective throughput
R/2
lin R/2
 upstream transmission capacity / buffering
wasted for packets lost downstream

lout
lin’ R/2

Transport Layer: 3-26

Approaches towards congestion control

End-end congestion control:

 no explicit feedback from
network
 congestion inferred from
observed loss, delay ACKs
data data
ACKs

 approach taken by TCP

Transport Layer: 3-27

Approaches towards congestion control

Network-assisted congestion
control:
 routers provide direct feedback explicit congestion info
to sending/receiving hosts with
flows passing through congested
router data data
ACKs
ACKs
 may indicate congestion level or
explicitly set sending rate

 TCP ECN, ATM, DECbit protocols

Transport Layer: 3-28

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-29

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 each
maximum segment size every RTT loss event
until loss detected
TCP sender Sending rate

AIMD sawtooth
behavior: probing
for bandwidth

time Transport Layer: 3-30

TCP AIMD: more
Multiplicative decrease detail: sending rate is
 Cut in half on loss detected by triple duplicate ACK (TCP
Reno)
 Cut to 1 MSS (maximum segment size) when loss detected
by timeout (TCP Tahoe)

Why AIMD?
 AIMD – a distributed, asynchronous algorithm – has been
shown to:
• optimize congested flow rates network wide!
• have desirable stability properties

Transport Layer: 3-31

TCP congestion control: details
sender sequence number space
cwnd
TCP sending behavior:
 roughly: send cwnd bytes,
wait RTT for ACKS, then
send more bytes
last byte
ACKed sent, but available ~ cwndbytes/sec
TCP rate~
not-yet but not RTT
ACKed lastused
byte
(“in-flight”) sent

 TCP sender limits transmission: LastByteSent- LastByteAcked < cwnd

 cwnd is dynamically adjusted in response to observed network
congestion (implementing TCP congestion control)

Transport Layer: 3-32

TCP slow start
Host A Host B
 when connection begins,
increase rate exponentially
until first loss event: one segm
ent
• initially cwnd = 1 MSS

RTT
• double cwnd every RTT two segm
ents
• done by incrementing cwnd
for every ACK received
four segm
ents

 summary: initial rate is slow,

but ramps up exponentially
fast
time

Transport Layer: 3-33

TCP: from slow start to congestion avoidance

Q: when should the

exponential increase switch
to linear? X
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-34

Summary: TCP congestion control
New
New ACK!
new ACK
duplicate ACK
dupACKcount++
ACK!
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 New
timeout
ACK!
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

Transport Layer: 3-35

TCP CUBIC
 Is there a better way than AIMD to “probe” for usable bandwidth?
 Insight/intuition:
• Wmax: sending rate at which congestion loss was detected
• congestion state of bottleneck link probably (?) hasn’t changed much
• after cutting rate/window in half on loss, initially ramp to to W max faster,
but then approach Wmax more slowly

Wmax classic TCP

TCP CUBIC -
Wmax/2 higher
throughput in
this example

Transport Layer: 3-36

TCP CUBIC
 K: point in time when TCP window size will reach Wmax
• K itself is tuneable
 increase W as a function of the cube of the distance between current time
and K

• larger increases when further away from K

• smaller increases (cautious) when nearer K
 TCP CUBIC default
Wmax
in Linux, most
popular TCP for TCP Reno
popular Web TCP CUBIC
servers TCP
sending
rate

time
t0 t1 t2 t3 t4
Transport Layer: 3-37
TCP and the congested “bottleneck link”
 TCP (classic, CUBIC) increase TCP’s sending rate until packet loss occurs at
some router’s output: the bottleneck link

source destination
application application
TCP TCP
network network
link link
physical physical
packet queue almost
never empty,
sometimes
overflows packet
(loss)
bottleneck link (almost always busy)
Transport Layer: 3-38
TCP and the congested “bottleneck link”
 TCP (classic, CUBIC) increase TCP’s sending rate until packet loss occurs at
some router’s output: the bottleneck link

 understanding congestion: useful to focus on congested bottleneck link

Goal: “keep the end-end pipe just full, but not fuller”
insight: increasing TCP sending
source rate will not increase end- destination
end throughout with
application
congested bottleneck application
TCP TCP
network network
link link
physical physical

insight: increasing
TCP sending rate
will increase
measured RTT
RTT
Transport Layer: 3-39
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
measured in last RTT
RTTmeasured throughput= interval
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-40

Delay-based TCP congestion control

 congestion control without inducing/forcing loss

 maximizing throughout (“keeping the just pipe full… ”) while keeping delay
low (“…but not fuller”)

 a number of deployed TCPs take a delay-based approach

 deployed on Google’s (internal) backbone network

Transport Layer: 3-41

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-42
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

Transport Layer: 3-43

Q: is TCP Fair?
Example: two competing TCP sessions:
 additive increase gives slope of 1, as throughout increases
 multiplicative decrease decreases throughput proportionally

R equal bandwidth share

Is TCP fair?
Connection 2 throughput

A: Yes, under idealized

assumptions:
loss: decrease window by factor of 2
 same RTT
congestion avoidance: additive increase  fixed number of sessions
loss: decrease window by factor of 2 only in congestion
congestion avoidance: additive increase avoidance

Connection 1 throughput R
Transport Layer: 3-44
Fairness: must all network apps be “fair”?
Fairness and UDP Fairness, parallel TCP connections
 multimedia apps often do not  application can open multiple
use TCP parallel connections between two
• do not want rate throttled by hosts
congestion control  web browsers do this , e.g., link of
 instead use UDP: rate R with 9 existing connections:
• send audio/video at constant • new app asks for 1 TCP, gets rate
rate, tolerate packet loss R/10
 there is no “Internet police” • new app asks for 11 TCPs, gets
R/2
policing use of congestion
control

Transport Layer: 3-45

Transport layer: 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-46

Evolving transport-layer functionality
 TCP, UDP: principal transport protocols for 40 years
 different “flavors” of TCP developed, for specific scenarios:

Scenario Challenges
Long, fat pipes (large Many packets “in flight”; loss
data transfers) shuts down pipeline
Wireless networks Loss due to noisy wireless links,
mobility; TCP treat this as
congestion loss
Long-delay links Extremely long RTTs
Data center networks Latency sensitive
Background traffic flows Low priority, “background” TCP
 moving transport–layer functions to application layer, on top of UDP
flows
• HTTP/3: QUIC
Transport Layer: 3-47
QUIC: Quick UDP Internet Connections
 application-layer protocol, on top of UDP
• increase performance of HTTP
• deployed on many Google servers, apps (Chrome, mobile YouTube
app)

HTTP/2 HTTP/2 (slimmed)

Applicatio HTTP/3
n TLS QUIC

Transpor TCP UDP

t
Network IP IP

HTTP/2 over TCP HTTP/2 over QUIC over UDP

Transport Layer: 3-48

QUIC: Quick UDP Internet Connections
adopts approaches we’ve studied in this chapter for
connection establishment, error control, congestion control
• error and congestion control: “Readers familiar with TCP’s
loss detection and congestion control will find algorithms here
that parallel well-known TCP ones.” [from QUIC specification]
• connection establishment: reliability, congestion control,
authentication, encryption, state established in one RTT

 multiple application-level “streams” multiplexed over

single QUIC connection
• separate reliable data transfer, security
• common congestion control
Transport Layer: 3-49
QUIC: Connection establishment

TCP handshake
(transport layer) QUIC handshake

data
TLS handshake
(security)
data

TCP (reliability, congestion QUIC: reliability, congestion

control state) + TLS control, authentication, crypto
(authentication, crypto state) state
 2 serial handshakes  1 handshake
Transport Layer: 3-50
 QUIC: streams: parallelism, no HOL blocking

HTTP HTTP
HTTP
application

GET GET
GET
HTTP HTTP
GET GET
HTTP
GET QUIC QUIC QUIC QUIC QUIC QUIC
encrypt encrypt encrypt encrypt encrypt encrypt
QUIC QUIC QUIC QUIC QUIC QUIC
TLS encryption TLS encryption RDT RDT RDT RDT
error
RDT RDT
!
QUIC Cong. QUIC Cong.
transport

Cont. Cont.
TCP RDT TCP
error RDT
!
TCP Cong. TCP Cong.
UDP UDP
Contr. Contr.

(a) HTTP 1.1 (b) HTTP/2 with QUIC: no HOL blocking

Transport Layer: 3-51
Chapter 3: summary
 principles behind transport layer Up next:
services:  leaving the network “edge”
• multiplexing, demultiplexing (application, transport layers)
• reliable data transfer  into the network “core”
• flow control  two network-layer chapters:
• congestion control
• data plane
 instantiation, implementation in the • control plane
Internet
• UDP
• TCP

Transport Layer: 3-52