Professional Documents
Culture Documents
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-2023
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:
n
dt
local or
• sender: breaks application messages
ran
regional ISP
spo
into segments, passes to network layer home network
rt
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
application
transport Hnnetwork
Ht HTTP msg transport
Hn Hnetwork
t HTTP msg
link network
link physical link
physical physical
Hn Ht HTTP msg
client
application application
HTTP msg
HTTP msg transport
Ht HTTP msg
de-multiplexing
application
? transport
de-multiplexing
Demultiplexing
multiplexing
application
transport
multiplexing
Multiplexing
How demultiplexing works
§ host receives IP datagrams 32 bits
• each datagram has source IP source port # dest port #
address, destination IP address
• each datagram carries one other header fields
transport-layer segment
• each segment has source, application
destination port number data
§ host uses IP addresses & port (payload)
B D
source port: 6428 source port: ?
dest port: 9157 dest port: ?
A C
source port: 9157 source port: ?
dest port: 6428 dest port: ?
Connection-oriented demultiplexing
§ TCP socket identified by § server may support many
4-tuple: simultaneous TCP sockets:
• source IP address • each socket identified by its
• source port number own 4-tuple
• dest IP address • each socket associated with
• dest port number a different connecting client
§ demux: receiver uses all
four values (4-tuple) to
direct segment to
appropriate socket
Transport Layer: 3-22
Connection-oriented demultiplexing: example
application
application P4 P5 P6 application
P1 P2 P3
transport
transport network transport
network link network
link physical link
physical server: IP physical
address B
application application
transport transport
(UDP) (UDP)
link link
physical physical
link
§ passes segment to IP link
physical physical
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-35
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
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
U 3L / R .0024
sender = = = 0.00081
RTT + L / R 30.008
rcv_base
Not received
Transport Layer: 3-55
Go-Back-N in action
sender window (N=4) sender receiver
012345678 send pkt0
012345678 send pkt1
012345678 send pkt2 receive pkt0, send ack0
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
§ seq #s: 0, 1, 2, 3 (base 4 counting) 0123012
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-61
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) § 0receiver
1 2 3 0 1 2 can’t
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 (very)
0123012
wrong!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
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-69
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-70
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-71
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
socket buffers IP
code
from sender
TCP
code
Network layer
delivering IP datagram
payload into TCP
socket buffers IP
code
from sender
TCP
code
receive window
flow control: # bytes
receiver willing to accept IP
code
from sender
TCP
flow control code
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