Professional Documents
Culture Documents
Chapter 3 v8.0
Chapter 3 v8.0
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
All material copyright 1996-2020
Jim Kurose, Keith Ross
J.F Kurose and K.W. Ross, All Rights Reserved 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
lo g
ica
l en
§ transport protocols actions in end
d-e
systems:
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 datacenter
applicationnetwork
transport
network
Sender:
application § is passed an application- application
app. msg
layer message
transport § determines segment TThhtransport
app. msg
header fields values
network (IP) § creates segment network (IP)
link
§ passes segment to IP link
physical physical
Receiver:
application § receives segment from IP application
§ checks header values
app. msg
transport § extracts application-layer transport
message
network (IP) network (IP)
§ demultiplexes message up
link to application via socket link
physical physical
Th app. msg
lo g
• congestion control
ica
• flow control
l en
d-e
• connection setup
nd
local or
§ UDP: User Datagram Protocol
tra
regional ISP
nsp
• unreliable, unordered delivery
ort
home network content
provider
• no-frills extension of “best-effort” IP network datacenter
applicationnetwork
Hnnetwork
Ht HTTP msg transport
transport
network link network
link physical link
physical physical
transport
Hn Ht HTTP msg
transport
application
application application
transport transport
(UDP) (UDP)
link link
physical physical
link
§ passes segment to IP link
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: http://gaia.cs.umass.edu/kurose_ross/interactive/
Transport Layer: 3-33
Internet checksum: weak protection!
example: add two 16-bit integers
0 1
1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 0
1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 Even though
numbers have
sum 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 changed (bit
flips), no change
checksum 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 in checksum!
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
Sender, receiver do not know reliable data
transfer protocol
of reliable data
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 arrives on receiver side of
Bi-directional communication over
unreliable channel to receiver unreliable channel channel
Transport Layer: 3-41
Reliable data transfer: getting started
We will:
§ incrementally develop 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
event causing state transition
actions taken on state transition
state: when in this “state”
next state uniquely state state
determined by next 1 event
event 2
actions
extract(rcvpkt,data)
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
L/R L/R
Usender=
RTT + L / R
.008 RTT
=
30.008
= 0.00027
U 3L / R .0024
sender = = = 0.00081
RTT + L / R 30.008
rcv_base
Not received
Transport Layer: 3-68
Go-Back-N in action
sender window (N=4) sender receiver
012345678 send pkt0
012345678 send pkt1
send pkt2 receive pkt0, send ack0
012345678
012345678 send pkt3 Xloss receive pkt1, send ack1
(wait)
receive pkt3, discard,
012345678 rcv ack0, send pkt4 (re)send ack1
012345678 rcv ack1, send pkt5 receive pkt4, discard,
(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
a dilemma!
0123012 pkt0
0123012 pkt1 0123012
0123012 pkt2 0123012
example:
0123012
0123012 pkt3
X
0123012
§ seq #s: 0, 1, 2, 3 (base 4 counting) pkt0 will accept packet
with seq number 0
§ window size=3 (a) no problem
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-74
Selective repeat:
sender window receiver window
(after receipt) (after receipt)
a dilemma!
0123012 pkt0
0123012 pkt1 0123012
0123012 pkt2 0123012
example:
0123012
0123012 pkt3
X
§ seq #s: 0, 1, 2, 3 (base 4 counting) § receiver can’t
0123012
pkt0 will accept packet
see sender side with seq number 0
§ window size=3 (a) no problem
§ receiver
behavior
identical in both
cases!
§0something’s
123012 pkt0
Q: what relationship is needed 0(very)
1 2 3 0 1wrong!
2 pkt1 0123012
window size
Acknowledgements: N
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
of echoed ‘C’
Seq=43, ACK=80
(milliseconds)
300
250
RTT (milliseconds)
RTT
200
sampleRTT
150
EstimatedRTT
100
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)
time (seconds)
SampleRTT Estimated RTT
Transport Layer: 3-82
TCP round trip time, timeout
§ timeout interval: EstimatedRTT plus “safety margin”
• large variation in EstimatedRTT: want a larger safety margin
TimeoutInterval = EstimatedRTT + 4*DevRTT
* Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/
Transport Layer: 3-83
TCP Sender (simplified)
event: data received from event: timeout
application § retransmit segment that
caused timeout
§ create segment with seq #
§ restart timer
§ seq # is byte-stream number
of first data byte in segment
event: ACK received
§ start timer if not already
running § if ACK acknowledges
previously unACKed segments
• think of timer as for oldest
unACKed segment • update what is known to be
ACKed
• expiration interval:
TimeOutInterval • start timer if there are still
unACKed segments
Transport Layer: 3-84
TCP Receiver: ACK generation [RFC 5681]
Event at receiver TCP receiver action
arrival of in-order segment with delayed ACK. Wait up to 500ms
expected seq #. All data up to for next segment. If no next segment,
expected seq # already ACKed send ACK
SendBase=92
Seq=92, 8 bytes of data Seq=92, 8 bytes of data
timeout
ACK=100
X
ACK=100
ACK=120
SendBase=120
=100
timeout
A CK
=100
A CK
=100
Receipt of three duplicate ACKs A CK
TCP
code
Network layer
delivering IP datagram
payload into TCP
IP
socket buffers
code
from sender
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
network network
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!
choose x
req_conn(x)
ESTAB
retransmit acc_conn(x)
req_conn(x)
ESTAB
req_conn(x)
connection
client x completes server
terminates forgets x
ESTAB
acc_conn(x)
Problem: half open
connection! (no client)
Transport Layer: 3-99
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
terminates forgets x
req_conn(x)
ESTAB
data(x+1) accept
data(x+1)
Problem: dup data
accepted!
TCP 3-way handshake
Server state
Client state
serverSocket = socket(AF_INET,SOCK_STREAM)
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.
§ two flows
R R
§ no retransmissions needed
Host B
R/2
Q: What happens as
arrival rate lin lout
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-106
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
throughput: lout
Host A lin : original data lin
copy l'in: original data, plus lout R/2
retransmitted data
R R
no buffer space!
R R
throughput: lout
full buffers
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
throughput: lout
full buffers – requiring retransmissions to un-needed
retransmissions
§ but sender times can time out prematurely,
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
duplicates, that are
R/2
timeout
copy l'in: original data, plus delivered!
retransmitted data
R R
throughput: lout
full buffers – requiring retransmissions to un-needed
retransmissions
§ but sender times can time out prematurely,
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
throughput: lout
lin R/2
delay
R/2
lin R/2
loutthroughput:
throughput
lin R/2 R/2
throughput: lout
effective throughput
R/2
lin
§ upstream transmission capacity / buffering
R/2
lout
wasted for packets lost downstream
lin’ R/2
router
§ may indicate congestion level or
explicitly set sending rate
§ TCP ECN, ATM, DECbit protocols
Transport Layer: 3-117
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-118
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
ents
• 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: http://gaia.cs.umass.edu/kurose_ross/interactive/
Transport Layer: 3-123
Summary: TCP congestion control
New
New ACK!
ACK! 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 New
ACK!
ssthresh = cwnd/2
cwnd = 1 New ACK
dupACKcount = 0
dupACKcount == 3 cwnd = ssthresh 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
t0 t1 t2 t3 t4
Transport Layer: 3-126
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)
ECN=10 ECN=11
IP datagram
Transport Layer: 3-131
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-133
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
congestion control parallel connections between two
hosts
§ instead use UDP:
• send audio/video at constant rate, § web browsers do this , e.g., link of
tolerate packet loss rate R with 9 existing connections:
§ there is no “Internet police” • new app asks for 1 TCP, gets rate R/10
policing use of congestion • new app asks for 11 TCPs, gets R/2
control
Network IP IP
TCP handshake
(transport layer) QUIC handshake
data
TLS handshake
(security)
data
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
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