05 Chapter - 3 - 1

Chapter 3
Transport Layer
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

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 services and protocols
application
transport
▪ provide logical communication mobile network

network
data link
physical
between application processes national or global ISP
running on different hosts

▪ transport protocols actions in end
systems: local or
• sender: breaks application messages regional ISP
into segments, passes to network layer home network content

• receiver: reassembles segments into provider
network datacenter
messages, passes to application layer application
transport
network
network
▪ two transport protocols available to data link

physical
Internet applications enterprise

network
• TCP, UDP
Transport vs. network layer services and protocols
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 vs. network layer services and protocols
household analogy:
▪network layer: logical
communication between 12 kids in Ann’s house sending
letters to 12 kids in Bill’s
hosts house:
▪transport layer: logical ▪ hosts = houses
communication between ▪ processes = kids
▪ app messages = letters in
processes envelopes
• relies on, enhances, network ▪ transport protocol = Ann and Bill
layer services who demux to in-house siblings
▪ network-layer protocol = postal
service

Transport Layer Actions
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

Transport Layer Actions
Receiver:
application ▪ receives segment from IP application
▪ checks header values
transport
app. msg ▪ extracts application-layer transport
message
network (IP) network (IP)
▪ demultiplexes message up
link to application via socket link
physical physical
Th app. msg

Two principal Internet transport protocols
application
transport
▪ TCP: Transmission Control Protocol mobile network

network
data link
physical
• reliable, in-order delivery national or global ISP
• congestion control
• flow control
• connection setup
local or
▪ UDP: User Datagram Protocol regional ISP
• unreliable, unordered delivery home network content

• no-frills extension of “best-effort” IP provider
network datacenter
application
network
▪ services not available: transport
network
data link
• delay guarantees physical
• bandwidth guarantees enterprise

network

Chapter 3: roadmap
functionality
HTTP server
client
application application
HTTP msg
transport
transport network transport

network link network
link physical link
physical physical

HTTP server
client
HTTP msg
transport
Ht HTTP msg

link physical link
physical physical

HTTP server
client
HTTP msg
transport
Ht HTTP msg
Hnnetwork
Ht HTTP msg transport
transport
link physical link
physical physical

HTTP server
client
transport

link physical link
physical physical
Hn Ht HTTP msg

HTTP server
client1 client2
application P-client1 P-client2 application
transport

link physical link
physical physical

Multiplexing/demultiplexing
multiplexing at sender: demultiplexing at receiver:
handle data from multiple use header info to deliver
sockets, add transport header received segments to correct
(later used for demultiplexing) socket
application
application P1 P2 application socket

P3 transport P4
process
link physical link
physical physical

How demultiplexing works
▪ host receives IP datagrams 32 bits
(IP packets) source port # dest port #
• each datagram has source IP
address, destination IP address other header fields
• each datagram carries one
transport-layer segment
application
• each segment has source, data
destination port number (payload)
▪ host uses IP addresses & port
numbers to direct segment to TCP/UDP segment format
appropriate socket
Connectionless demultiplexing
Recall: when receiving host receives
▪ when creating socket, must UDP segment:
• checks destination port # in
specify host-local port #: segment
DatagramSocket mySocket1 • directs UDP segment to
= new DatagramSocket(12534);
socket with that port #
▪ when creating datagram to
send into UDP socket, must
specify IP/UDP datagrams with same dest.
port #, but different source IP
• destination IP address addresses and/or source port
• destination port # numbers will be directed to same
socket at receiving host
UDP: User Datagram Protocol
Why is there a UDP?
▪ “no frills,” “bare bones”
Internet transport protocol ▪ no connection
establishment (which can
▪ “best effort” service, UDP add RTT delay)
segments may be: ▪ simple: no connection state
• lost at sender, receiver
• delivered out-of-order to app ▪ small header size
▪ connectionless: ▪ no congestion control
• no handshaking between UDP ▪ UDP can blast away as fast as
desired!
sender, receiver
▪ can function in the face of
• each UDP segment handled congestion
independently of others
UDP: User Datagram Protocol
▪ UDP use:
▪ streaming multimedia apps (loss tolerant, rate sensitive)
▪ DNS
▪ SNMP
▪ HTTP/3
▪ if reliable transfer needed over UDP (e.g., HTTP/3):
▪ add needed reliability at application layer
▪ add congestion control at application layer

UDP: User Datagram Protocol [RFC 768]

UDP segment header
32 bits
source port # dest port #
length checksum
application length, in bytes of

data UDP segment,
(payload) including header
data to/from
UDP segment format application layer

UDP checksum
Goal: detect errors (i.e., flipped bits) in transmitted segment
1st number 2nd number sum
Transmitted: 5 6 11
Received: 4 6 11
receiver-computed sender-computed
checksum
= checksum (as received)

Internet checksum
Goal: detect errors (i.e., flipped bits) in transmitted segment
sender: receiver:
▪ treat contents of UDP ▪ compute checksum of received
segment (including UDP header segment
fields and IP addresses) as
sequence of 16-bit integers ▪ check if computed checksum equals
▪ checksum: addition (one’s checksum field value:
complement sum) of segment • not equal - error detected
content • equal - no error detected. But maybe
▪ checksum value put into errors nonetheless? More later ….
UDP checksum field
Internet checksum: an example
example: add two 16-bit integers
1 1 1 0 0 1 1 0 0 1 1 0 0 1 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
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/
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!

Summary: UDP
▪ “no frills” protocol:
• segments may be lost, delivered out of order
• best effort service: “send and hope for the best”
▪ UDP has its plusses:
• no setup/handshaking needed (no RTT incurred)
• can function when network service is compromised
• helps with reliability (checksum)
▪ build additional functionality on top of UDP in application layer
(e.g., HTTP/3)
Chapter 3: roadmap
functionality
Principles of reliable data transfer
sending receiving
process process
application data data
transport
reliable channel
reliable service abstraction

sending receiving sending receiving

process process process process
application data data application data data
transport transport
reliable channel
sender-side of receiver-side
reliable service abstraction reliable data of reliable data
transfer protocol transfer protocol
transport
network
unreliable channel
reliable service implementation

sending receiving
process process
transport
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?)

sending receiving
process process
transport
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 data transfer protocol (rdt): interfaces
rdt_send(): called from above, deliver_data(): called by rdt
(e.g., by app.). Passed data to to deliver data to upper layer
deliver to receiver upper layer
sending receiving
process process
rdt_send() data data
deliver_data()
sender-side data receiver-side

implementation of implementation of
rdt reliable data packet rdt reliable data
transfer protocol transfer protocol
udt_send() Header data Header data rdt_rcv()
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
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

rdt1.0: reliable transfer over a reliable channel
▪ underlying channel perfectly reliable
• no bit errors
• no loss of packets
▪ separate FSMs for sender, receiver:

• sender sends data into underlying channel
• receiver reads data from underlying channel
Wait for rdt_send(data) Wait for rdt_rcv(packet)

sender call from packet = make_pkt(data) receiver call from extract (packet,data)
above udt_send(packet) below deliver_data(data)

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?
How do humans recover from “errors” during conversation?

rdt2.0: channel with bit errors
▪ underlying channel may flip bits in packet
• checksum to detect bit errors
▪ the question: how to recover from errors?
• acknowledgements (ACKs): receiver explicitly tells sender that pkt
received OK
• negative acknowledgements (NAKs): receiver explicitly tells sender
that pkt had errors
• sender retransmits pkt on receipt of NAK
stop and wait

sender sends one packet, then waits for receiver response
rdt2.0: FSM specifications
rdt_send(data)
sndpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
Wait for Wait for isNAK(rcvpkt)
sender call from ACK or udt_send(sndpkt) rdt_rcv(rcvpkt) && corrupt(rcvpkt)
above NAK
udt_send(NAK)
rdt_rcv(rcvpkt) && isACK(rcvpkt)

Wait for
L call from receiver
below
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)

rdt2.0: FSM specification
rdt_send(data)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
above NAK
udt_send(NAK)

Wait for
below
Note: “state” of receiver (did the receiver get my

message correctly?) isn’t known to sender unless rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
somehow communicated from receiver to sender deliver_data(data)
▪ that’s why we need a protocol! udt_send(ACK)

rdt2.0: operation with no errors
rdt_send(data)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
above NAK
udt_send(NAK)

Wait for
below

deliver_data(data)
udt_send(ACK)

rdt2.0: corrupted packet scenario
rdt_send(data)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
above NAK
udt_send(NAK)

Wait for
below

deliver_data(data)
udt_send(ACK)

rdt2.0 has a fatal flaw!
what happens if ACK/NAK handling duplicates:
corrupted? ▪ sender retransmits current pkt
▪ sender doesn’t know what if ACK/NAK corrupted
happened at receiver! ▪ sender adds sequence number
▪ can’t just retransmit: possible to each pkt
duplicate ▪ receiver discards (doesn’t
deliver up) duplicate pkt
stop and wait

sender sends one packet, then
waits for receiver response
rdt2.1: sender, handling garbled ACK/NAKs
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt) rdt_rcv(rcvpkt) &&
(corrupt(rcvpkt) ||
Wait for Wait for isNAK(rcvpkt) )
call 0 from ACK or
NAK 0 udt_send(sndpkt)
above
rdt_rcv(rcvpkt)
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) &&
&& notcorrupt(rcvpkt)
isACK(rcvpkt)
&& isACK(rcvpkt)
L
L
Wait for Wait for
ACK or call 1 from
rdt_rcv(rcvpkt) NAK 1 above
&& (corrupt(rcvpkt) ||
isNAK(rcvpkt) ) rdt_send(data)
udt_send(sndpkt) sndpkt = make_pkt(1, data, checksum)

udt_send(sndpkt)

rdt2.1: receiver, handling garbled ACK/NAKs
&& has_seq0(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt)) rdt_rcv(rcvpkt) && (corrupt(rcvpkt))
sndpkt = make_pkt(NAK, chksum) sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
Wait for Wait for
rdt_rcv(rcvpkt) && 0 from 1 from rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) && below below not corrupt(rcvpkt) &&
has_seq1(rcvpkt) has_seq0(rcvpkt)
sndpkt = make_pkt(ACK, chksum) sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
&& has_seq1(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)

rdt2.1: discussion
sender: receiver:
▪ seq # added to pkt ▪ must check if received packet
▪ two seq. #s (0,1) will suffice. is duplicate
Why? • state indicates whether 0 or 1 is
expected pkt seq #
▪ must check if received ACK/NAK
corrupted ▪ note: receiver can not know if
its last ACK/NAK received OK
▪ twice as many states at sender
• state must “remember” whether
“expected” pkt should have seq #
of 0 or 1

rdt2.2: a NAK-free protocol
▪ same functionality as rdt2.1, using ACKs only
▪ instead of NAK, receiver sends ACK for last pkt received OK
• receiver must explicitly include seq # of pkt being ACKed
▪ duplicate ACK at sender results in same action as NAK:
retransmit current pkt
As we will see, TCP uses this approach to be NAK-free

rdt2.2: sender, receiver fragments
rdt_send(data)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
Wait for Wait for
ACK isACK(rcvpkt,1) )
call 0 from
above 0 udt_send(sndpkt)
sender FSM
fragment rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && && isACK(rcvpkt,0)
(corrupt(rcvpkt) || L
has_seq1(rcvpkt)) Wait for receiver FSM
0 from
udt_send(sndpkt) below fragment
&& has_seq1(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK1, chksum)
udt_send(sndpkt) Transport Layer: 3-55
rdt3.0: channels with errors and loss
New channel assumption: underlying channel can also lose
packets (data, ACKs)
• checksum, sequence #s, ACKs, retransmissions will be of help …
but not quite enough
Q: How do humans handle lost sender-to-

receiver words in conversation?

rdt3.0: channels with errors and loss
Approach: sender waits “reasonable” amount of time for ACK
▪ retransmits if no ACK received in this time
▪ if pkt (or ACK) just delayed (not lost):
• retransmission will be duplicate, but seq #s already handles this!
• receiver must specify seq # of packet being ACKed
▪ use countdown timer to interrupt after “reasonable” amount
of time
timeout

rdt3.0 sender
rdt_send(data)
udt_send(sndpkt)
start_timer
Wait for Wait

call 0 from for
above ACK0
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt,1) && notcorrupt(rcvpkt)
stop_timer && isACK(rcvpkt,0)
stop_timer
Wait Wait for
for call 1 from
ACK1 above
rdt_send(data)
udt_send(sndpkt)
start_timer

rdt3.0 sender
rdt_send(data)
rdt_rcv(rcvpkt) &&
sndpkt = make_pkt(0, data, checksum) ( corrupt(rcvpkt) ||
udt_send(sndpkt) isACK(rcvpkt,1) )
rdt_rcv(rcvpkt) start_timer L
L Wait for Wait
for timeout
call 0 from
ACK0 udt_send(sndpkt)
above
start_timer
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt,1) && notcorrupt(rcvpkt)
stop_timer && isACK(rcvpkt,0)
stop_timer
Wait Wait for
timeout for call 1 from
udt_send(sndpkt) ACK1 above
start_timer rdt_rcv(rcvpkt)
rdt_send(data) L
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) || sndpkt = make_pkt(1, data, checksum)
isACK(rcvpkt,0) ) udt_send(sndpkt)
start_timer
L

rdt3.0 in action
sender receiver sender receiver
send pkt0 pkt0 send pkt0 pkt0
rcv pkt0 rcv pkt0
ack0 send ack0 ack0 send ack0
rcv ack0 rcv ack0
send pkt1 pkt1 send pkt1 pkt1
rcv pkt1 X
loss
ack1 send ack1
rcv ack1
send pkt0 pkt0
rcv pkt0 timeout
ack0 send ack0 resend pkt1 pkt1
rcv pkt1
ack1 send ack1
rcv ack1
send pkt0 pkt0
(a) no loss rcv pkt0
ack0 send ack0
(b) packet loss

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
rcv pkt1 ack1
ack1 send ack1
X timeout
loss resend pkt1
timeout
pkt1 rcv pkt1
resend pkt1 pkt1
rcv pkt1 rcv ack1 (detect duplicate)
(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
(c) ACK loss (d) premature timeout/ delayed ACK


05 Chapter - 3 - 1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

05 Chapter - 3 - 1

Uploaded by

Copyright:

Available Formats

Chapter 3

Transport Layer: 3-2

▪ provide logical communication mobile network

running on different hosts

into segments, passes to network layer home network content

▪ two transport protocols available to data link

Internet applications enterprise

Transport Layer: 3-5

Transport Layer: 3-6

link ▪ passes segment to IP link

Transport Layer: 3-7

Transport Layer: 3-8

▪ TCP: Transmission Control Protocol mobile network

• unreliable, unordered delivery home network content

• delay guarantees physical

• bandwidth guarantees enterprise

Transport Layer: 3-9

transport network transport

Transport Layer: 3-11

transport network transport

Transport Layer: 3-12

Transport Layer: 3-13

transport network transport

Transport Layer: 3-14

transport network transport

Transport Layer: 3-15

application P1 P2 application socket

Transport Layer: 3-16

Transport Layer: 3-25

Transport Layer: 3-26

application length, in bytes of

Transport Layer: 3-30

Transport Layer: 3-31

Transport Layer: 3-34

reliable service abstraction

Transport Layer: 3-37

sending receiving sending receiving

reliable service implementation

Transport Layer: 3-38

Transport Layer: 3-39

Transport Layer: 3-40

sender-side data receiver-side

Transport Layer: 3-42

▪ separate FSMs for sender, receiver:

Wait for rdt_send(data) Wait for rdt_rcv(packet)

Transport Layer: 3-43

How do humans recover from “errors” during conversation?

Transport Layer: 3-44

stop and wait

rdt_rcv(rcvpkt) && isACK(rcvpkt)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

Transport Layer: 3-46

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Note: “state” of receiver (did the receiver get my

Transport Layer: 3-47

rdt_rcv(rcvpkt) && isACK(rcvpkt)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

Transport Layer: 3-48

rdt_rcv(rcvpkt) && isACK(rcvpkt)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

Transport Layer: 3-49

stop and wait

udt_send(sndpkt) sndpkt = make_pkt(1, data, checksum)