Chapter 3 J v8.0 V04
Chapter 3 J v8.0 V04
Transport
Layer
These slides are not a
substitute for reading the
text.
Computer Networking: A
Top-Down Approach
8th edition
Jim Kurose, Keith Ross
Pearson, 2020
Transport Layer: 3-1
Transport layer: overview
Our goal:
understand principles learn about Internet transport
behind transport layer layer protocols:
services: • UDP: connectionless transport
• multiplexing, • TCP: connection-oriented reliable
demultiplexing transport
• reliable data transfer • TCP congestion control
• flow control
• congestion control
log
ica
transport protocols actions in end
le
n d-
systems:
e nd
local or
tra
• sender: breaks application messages regional ISP
nsp
into segments, passes to network layer
ort
home network content
• receiver: reassembles segments into provider
network
messages, passes to application layer application
transport
datacenter
network
network
two transport protocols available to data link
physical
household analogy:
12 kids in Ann’s house sending
letters to 12 kids in Bill’s house:
hosts = houses
processes = kids
app messages = letters in
envelopes
transport protocol = Ann and Bill
who demux to in-house siblings
network-layer protocol = postal
service
Transport Layer: 3-5
Transport vs. network layer services and protocols
Sender:
application
is passed an application- app. msg
application
layer message
determines segment TThtransport
app. msg
transport h
Receiver:
application receives segment from IP application
checks header values
app. msg
transport extracts application-layer transport
message
network (IP) demultiplexes message up network
to application via socket (IP)
link
link
physical physical
Th app. msg
log
• congestion control
ica
le
• flow control
n d-
e nd
• connection setup local or
tra
regional ISP
UDP: User Datagram Protocol
nsp
ort
home network
• unreliable, unordered delivery content
provider
network
• no-frills extension of “best-effort” IP application
transport
datacenter
network
network
services not available: data link
physical
transport
Hn Ht HTTP msg
transport
application
application application
transport transport
(UDP) (UDP)
physical physical
data to/from
UDP segment format application layer
Transmitted: 5 6 11
Received: 4 6 11
receiver-computed
checksum
= sender-computed
checksum (as received)
sum 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
checksum 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
Note: when adding numbers, a carryout from the most significant bit needs to be
added to the result
* Check out the online interactive exercises for more examples: h ttp://gaia.cs.umass.edu/kurose_ross/interactive/
Transport Layer: 3-32
Internet checksum: weak protection!
sending receiving
process process
application data data
transport
reliable channel
transport
network
unreliable channel
sending receiving
process process
application data data
transport
sender-side of receiver-side
Complexity of reliable data reliable data
transfer protocol
of reliable data
transfer protocol
transfer protocol will depend
(strongly) on characteristics of transport
network
unreliable channel (lose, unreliable channel
corrupt, reorder data?)
reliable service implementation
sending receiving
process process
application data data
transport
sender-side of receiver-side
reliable data of reliable data
Sender, receiver do not know transfer protocol transfer protocol
the “state” of each other, e.g.,
was a message received? transport
network
unless communicated via a unreliable channel
message
reliable service implementation
unreliable channel
udt_send(): called by rdt rdt_rcv(): called when packet
to transfer packet over Bi-directional communication over arrives on receiver side of
unreliable channel to receiver unreliable channel channel
Transport Layer: 3-40
Reliable data transfer: getting started
We will:
incrementally develop a series of attempts to solve the sender & receiver
sides of reliable data transfer protocol (rdt)
consider only unidirectional data transfer
• but control info will flow in both directions!
use finite state machines (FSM) to specify sender, receiver
p. 203
Transport Layer: 3-42
rdt2.0: channel with bit errors
underlying channel may flip bits in packet
• checksum (e.g., Internet checksum) to detect bit errors
the question: how to recover from errors?
p. 205 deliver_data(data)
udt_send(ACK)
extract(rcvpkt,data)
p. 208
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_send(data)
sndpkt = make_pkt(1, data, checksum)
udt_send(sndpkt)
start_timer
p. 212
(b) packet loss
Transport Layer: 3-60
rdt3.0 in action
sender receiver
sender receiver send pkt0
pkt0
rcv pkt0
send pkt0 pkt0 send ack0
ack0
rcv pkt0 rcv ack0
ack0 send ack0 send pkt1 pkt1
rcv ack0 rcv pkt1
send pkt1 pkt1 send ack1
rcv pkt1 ack1
ack1 send ack1
X timeout
loss resend pkt1
pkt1 rcv pkt1
timeout
resend pkt1 pkt1
rcv pkt1 rcv ack1 (detect duplicate)
send pkt0 pkt0 send ack1
(detect duplicate)
ack1 send ack1 ack1 rcv pkt0
rcv ack1 rcv ack1 send ack0
send pkt0 pkt0 (ignore) ack0
rcv pkt0
ack0 send ack0 pkt1
L/R L/R
Usender =
RTT + L / R
.008 RTT
=
30.008
= 0.00027
p. 213
Transport Layer: 3-65
Pipelining: increased utilization
sender receiver
first packet bit transmitted, t = 0
last bit transmitted, t = L / R
U 3L / R .0024
sender = = = 0.00081
RTT + L / R 30.008
p. 215
cumulative ACK: ACK(n): ACKs all packets up to, including seq # n
• on receiving ACK(n): move window forward to begin at n+1
timer for oldest in-flight packet
timeout(n): retransmit packet n and all higher seq # packets in window
Transport Layer: 3-67
Go-Back-N: sender
Questions
k-bit seq # in pkt header
rcv_base
Not received
Transport Layer: 3-70
Go-Back-N in action
sender window (N=4) sender receiver
012345678 send pkt0
012345678 send pkt1
send pkt2 receive pkt0, send ack0
012345678
send pkt3 Xloss receive pkt1, send ack1
012345678
(wait)
receive pkt3, discard,
012345678 rcv ack0, send (re)send ack1
012345678 pkt4
rcv ack1, send receive pkt4, discard,
pkt5 (re)send ack1
ignore duplicate ACK receive pkt5, discard,
(re)send ack1
pkt 2 timeout
012345678 send pkt2
012345678 send pkt3
012345678 send pkt4 rcv pkt2, deliver, send ack2
012345678 send pkt5 rcv pkt3, deliver, send ack3
rcv pkt4, deliver, send ack4
rcv pkt5, deliver, send ack5
0123012 pkt0
pkt1
a dilemma!
0123012 0123012
0123012 pkt2 0123012
0123012
example: 0123012 pkt3
X
seq #s: 0, 1, 2, 3 (base 4 counting) 0123012
pkt0 will accept packet
0123012 pkt0
0123012 pkt1 0123012
0123012 pkt2 X 0123012
X 0123012
X
timeout
retransmit pkt0
0123012 pkt0
will accept packet
with seq number 0
(b) oops!
Transport Layer: 3-76
Selective repeat: sender window
(after receipt)
receiver window
(after receipt)
0123012 pkt0
pkt1
a dilemma!
0123012 0123012
0123012 pkt2 0123012
0123012
example: 0123012 pkt3
X
seq #s: 0, 1, 2, 3 (base 4 counting) receiver can’t
0123012
pkt0 will accept packet
see sender side
window size=3 (a) no problem
receiver
with seq number 0
behavior
identical in both
Q: what relationship is needed cases!
between sequence # size and 0something’s
123012 pkt0
window size to avoid problem 0(very)
1 2 3 0 1wrong!
2 pkt1 0123012
options (variable
C, E: congestion notification length)
TCP options
application data sent by
RST, SYN, FIN: connection data application into
management (variable length) TCP socket
p. 231
Transport Layer: 3-81
message M
source
Encapsulation
application
segment Ht M transport
datagram Hn Ht M network
frame Hl Hn Ht M link
physical
link
A: Hn physical
Chapter 1
destination Hn Ht M network
M application
Hl Hn Ht M link Hn Ht M
Ht M transport physical
Hn Ht M network
Hl Hn Ht M link router
physical A TCP
header is Ht
-82
TCP sequence numbers, ACKs
outgoing segment from sender
Sequence numbers: source port # dest port #
sequence number
• byte stream “number” of first acknowledgement number
window size
Acknowledgements: N
p. 232
sequence number
acknowledgement number
A rwnd
checksum urg pointer
User types‘C’
Seq=42, ACK=79, data = ‘C’
host ACKs receipt of‘C’,
echoes back ‘C’
Seq=79, ACK=43, data = ‘C’
host ACKs receipt Here,
of echoed ‘C’
Seq=43, ACK=80 1 Char = 1 Byte
p. 234
simple telnet scenario
Transport Layer: 3-85
TCP round trip time, timeout
Q: how to set TCP timeout Q: how to estimate RTT?
value? SampleRTT:measured time
longer than RTT, but RTT varies! from segment transmission until
ACK receipt
too short: premature timeout,
• ignore retransmissions
unnecessary retransmissions
SampleRTT will vary, want
too long: slow reaction to estimated RTT “smoother”
segment loss • average several recent
measurements, not just current
SampleRTT
SendBase=92
Seq=92, 8 bytes of data Seq=92, 8 bytes of data
timeout
timeout
Seq=100, 20 bytes of data
ACK=100
X
ACK=100
ACK=120
SendBase=120
cumulative ACK
covers for earlier
lost ACK
Transport Layer: 3-92
TCP fast retransmit Q: Faster than what?
Host A Host B
TCP fast retransmit
if sender receives 3 additional
ACKs for same data (“triple Se q= 9
2, 8 by
Seq= data tes of
duplicate ACKs”), resend unACKed 100, 2
data
0 b yt e
s of
segment with smallest seq # X
likely that unACKed segment lost,
=100
so don’t wait for timeout ACK
timeout
=100
ACK
CK =100
A
= 10 0
Receipt of three duplicate ACKs ACK
TCP
code
Network layer
delivering IP datagram
payload into TCP
IP
socket buffers code
from sender
p. 246
receiver protocol stack
TCP
code
Network layer
delivering IP datagram
payload into TCP
IP
socket buffers code
from sender
TCP
code
receive window
flow control: # bytes
receiver willing to accept IP
code
from sender
TCP
flow control code
application application
p. 249
Socket clientSocket = Socket connectionSocket =
newSocket("hostname","port number"); welcomeSocket.accept();
Transport Layer: 3-101
Agreeing to establish a connection
2-way handshake:
ESTAB
data(x+1) accept
data(x+1
ACK(x+1)
)
connection
x completes
No problem!
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-104
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!
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
1. On belay?
2. Belay on.
3. Climbing.
p. 251
Host B
R/2
Q: What happens as
lout
delay
arrival rate lin
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-111
Causes/costs of congestion: scenario 2 a
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
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
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
and un-needed
Host A lin : original data lin
copy R/2 duplicates, that are
timeo
ut 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
p. 262
Network-assisted congestion
control: explicit congestion info
routers provide direct feedback
to sending/receiving hosts with data data
ACKs
flows passing through congested ACKs
router
may indicate congestion level or
explicitly set sending rate
TCP ECN, ATM, DECbit protocols
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/
ECN=10 ECN=11
IP datagram
Transport Layer: 3-132
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-134
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
if (y > SendBase) {
SendBase = y
/* SendBase–1: last cumulatively ACKed byte */
if (there are currently not-yet-acked segments)
start timer
else stop timer
}
Transport Layer: 3-141
TCP 3-way handshake FSM
closed
Socket connectionSocket =
welcomeSocket.accept();
L Socket clientSocket =
newSocket("hostname","port number");
SYN(x)
SYNACK(seq=y,ACKnum=x+1) SYN(seq=x)
create new socket for
communication back to client
listen
SYN
SYN sent
rcvd
SYNACK(seq=y,ACKnum=x+1)
ESTAB
ACK(ACKnum=y+1) ACK(ACKnum=y+1)
L
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
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
Network IP IP
TCP handshake
(transport layer) QUIC handshake
data
TLS handshake
(security)
data
HTTP HTTP
GET GET HTTP
application
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