Chapter_3 Transport Layer readfaecve.pdf

Computer Networking: A
Top-Down Approach
8th edition
Jim Kurose, Keith Ross
Pearson, 2020
Chapter 3
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.
For a revision history, see the slide note for this page.
Thanks and enjoy! JFK/KWR
All material copyright 1996-2023
J.F Kurose and K.W. Ross, All Rights Reserved
Transport Layer: 3-1

Transport services and protocols
 provide logical communication
between application processes
running on different hosts
mobile network
home network
enterprise
network
national or global ISP
local or
regional ISP
datacenter
network
content
provider
network
application
transport
network
data link
physical
application
transport
network
data link
physical
 transport protocols actions in end
systems:
• sender: breaks application messages
into segments, passes to network layer
• receiver: reassembles segments into
messages, passes to application layer
 two transport protocols available to
Internet applications
• 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
network layer:
communication between
hosts
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:
communication between
processes
• relies on, enhances, network
layer services

physical
link
network (IP)
application
physical
link
network (IP)
application
transport
Transport Layer Actions
Sender:
app. msg
 is passed an application-
layer message
 determines segment
header fields values
 creates segment
 passes segment to IP
transport
Th
Th app. msg

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

Two principal Internet transport protocols
mobile network
home network
enterprise
network
national or global ISP
local or
regional ISP
datacenter
network
content
provider
network
application
transport
network
data link
physical
application
transport
network
data link
physical
TCP: Transmission Control Protocol
• reliable, in-order delivery
• congestion control
• flow control
• connection setup
UDP: User Datagram Protocol
• unreliable, unordered delivery
• no-frills extension of “best-effort” IP
services not available:
• delay guarantees
• bandwidth guarantees

UDP: User Datagram Protocol
 “no frills,” “bare bones”
Internet transport protocol
 “best effort” service, UDP
segments may be:
• lost
• delivered out-of-order to app
 no connection
establishment (which can
add RTT delay)
 simple: no connection state
at sender, receiver
 small header size
 no congestion control
 UDP can blast away as fast as
desired!
 can function in the face of
congestion
Why is there a UDP?
 connectionless:
• no handshaking between UDP
sender, receiver
• each UDP segment handled
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]

SNMP server
SNMP client
transport
(UDP)
physical
link
network (IP)
application
transport
(UDP)
physical
link
network (IP)
application
UDP: Transport Layer Actions
UDP receiver actions:
SNMP msg
 extracts application-layer
message
 checks UDP checksum
header value
 receives segment from IP
UDPh SNMP msg
 demultiplexes message up
to application via socket

UDP segment header
source port # dest port #
32 bits
application
data
(payload)
UDP segment format
length checksum
length, in bytes of
UDP segment,
including header
data to/from
application layer

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

TCP: overview RFCs: 793,1122, 2018, 5681, 7323
 cumulative ACKs
 pipelining:
• TCP congestion and flow control
set window size
 connection-oriented:
• handshaking (exchange of control
messages) initializes sender,
receiver state before data exchange
 flow controlled:
• sender will not overwhelm receiver
 point-to-point:
• one sender, one receiver
 reliable, in-order byte
steam:
• no “message boundaries"
 full duplex data:
• bi-directional data flow in
same connection
• MSS: maximum segment size

TCP segment structure
source port # dest port #
32 bits
not
used receive window flow control: # bytes
receiver willing to accept
sequence number
segment seq #: counting
bytes of data into bytestream
(not segments!)
application
data
(variable length)
data sent by
application into
TCP socket
A
acknowledgement number
ACK: seq # of next expected
byte; A bit: this is an ACK
options (variable length)
TCP options
head
len
length (of TCP header)
checksum
Internet checksum
RST, SYN, FIN: connection
management
F
S
R
Urg data pointer
P
U
C E
C, E: congestion notification

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!
Principles of congestion control
congestion control:
too many senders,
sending too fast
flow control: one sender
too fast for one receiver
 a top-10 problem!

Causes/costs of congestion: scenario 1
Simplest scenario:
maximum per-connection
throughput: R/2
Host A
Host B
throughput: lout
large delays as arrival rate
line approaches capacity
Q: What happens as
arrival rate lin
approaches R/2?
original data: lin
R
 two flows
 one router, infinite buffers
 input, output link capacity: R infinite shared
output link buffers
R
 no retransmissions needed
R/2
delay
lin
R/2
R/2
l
out
lin
throughput:

 one router, finite buffers
Host A
Host B
lin : original data
l'in: original data, plus
retransmitted data
finite shared output
link buffers
 sender retransmits lost, timed-out packet
• application-layer input = application-layer output: lin = lout
• transport-layer input includes retransmissions : l’in lin
lout
R
R

Host A
Host B
lin : original data
retransmitted data
link buffers
copy
free buffer space!
Idealization: perfect knowledge
 sender sends only when router buffers available
lout
R
R
R/2
lin
R/2
l
out
throughput:

Host A
Host B
lin : original data
retransmitted data
link buffers
R
R
copy
no buffer space!
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
Host B
lin : original data
retransmitted data
link buffers
R
R
free buffer space!
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
when sending at
R/2, some packets
are needed
retransmissions
lin
R/2
l
out
throughput:
R/2
“wasted” capacity due
to retransmissions

Host A
Host B
lin : original data
retransmitted data
link buffers
R
R
copy
timeout
Realistic scenario: un-needed duplicates
 packets can be lost, dropped at router due to
full buffers – requiring retransmissions
 but sender times can time out prematurely,
sending two copies, both of which are delivered
free buffer space!
when sending at
R/2, some packets
are retransmissions,
including needed
and un-needed
duplicates, that are
delivered!
to un-needed
retransmissions
lin
R/2
l
out
throughput:
R/2

“costs” of congestion:
 more work (retransmission) for given receiver throughput
 unneeded retransmissions: link carries multiple copies of a packet
• decreasing maximum achievable throughput
Realistic scenario: un-needed duplicates
 packets can be lost, dropped at router due to
full buffers – requiring 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
duplicates, that are
delivered!
to un-needed
retransmissions
lin
R/2
l
out
throughput:
R/2

 four senders
 multi-hop paths
 timeout/retransmit
Q: what happens as lin and lin
’ increase ?
A: as red lin
’ increases, all arriving blue pkts at upper
queue are dropped, blue throughput g 0
finite shared
output link buffers
Host A
lout
Host B
Host C
Host D
lin : original data
retransmitted data

another “cost” of congestion:
 when packet dropped, any upstream transmission capacity and
buffering used for that packet was wasted!
R/2
R/2
l
out
lin
’

Causes/costs of congestion: insights
 upstream transmission capacity / buffering
wasted for packets lost downstream
R/2
R/2
l
out
lin
’
 delay increases as capacity approached
R/2
delay
lin
 un-needed duplicates further decreases
effective throughput
lin
R/2
l
out
throughput:
R/2
 loss/retransmission decreases effective
throughput
lin
R/2
l
out
throughput:
R/2
 throughput can never exceed capacity
R/2
lin
R/2
l
out
throughput:

End-end congestion control:
 no explicit feedback from
network
 congestion inferred from
observed loss, delay
Approaches towards congestion control
data
data
ACKs
ACKs
 approach taken by TCP

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

Chapter_3 Transport Layer readfaecve.pdf

More Related Content

Similar to Chapter_3 Transport Layer readfaecve.pdf (20)

Recently uploaded (20)

Chapter_3 Transport Layer readfaecve.pdf