Chapter_3_v8.1.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-2020
J.F Kurose and K.W. Ross, All Rights Reserved
Transport Layer: 3-1

Transport layer: overview
Our goal:
▪ understand principles
behind transport layer
services:
• multiplexing,
demultiplexing
• reliable data transfer
• flow control
• congestion control
▪ learn about Internet transport
layer protocols:
• UDP: connectionless transport
• TCP: connection-oriented reliable
transport
• TCP congestion control

Transport layer: roadmap
▪ Transport-layer services
▪ Multiplexing and demultiplexing
▪ Connectionless transport: UDP
▪ Connection-oriented transport: TCP
▪ TCP congestion control

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
thông điệp sẽ được phân nhỏ
thành các segment: phân đoạn
chuyển xuống tâng network
dựa vào port để xác định gừi cho ứng dụng nào
Mở các segments

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
đóng gói các messages thành các segments ở tầng application
chuyển xuống tầng transport gắn header rồi chuyển tiếp cho tầng network

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
Tầng transport sẽ nhận segment và dựa vào header để xác định từng loại ứng dụng

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
• 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
gửi theo thứ tự nhất định, tránh los data
kiểm soát nghẽn mạng
điều khiển luồng
thiết lập một kết nối trước, server sẽ mở port -> tiến hành bắt tay 3 bước
Máy gửi và máy nhận kh cần thiết lập đường truyền
Không có nhiều cơ chế kiểm soát -> nhanh

Chapter 3: roadmap
dồn kênh tách kênh

transport
physical
link
network transport
application
physical
link
network
transport
application
physical
link
network
HTTP server
client
HTTP msg
Ht
Hn

transport
physical
link
network transport
application
physical
link
network
transport
application
physical
link
network
HTTP server
client1 client2
P-client1 P-client2
dồn kênh: tại máy gửi đi, dữ liệu tại nhiều ứng dụng gộp lại gửi yêu cầu
tách kênh: tại máy nhận, sẽ có hoạt động tách dữ liệu cho process thích hợp.

Multiplexing/demultiplexing

Mỗi gói tin sẽ có header và có port máy nhận để gửi đi tới máy nhận

How demultiplexing works
▪ host receives IP datagrams
• each datagram has source IP
address, destination IP address
• each datagram carries one
transport-layer segment
• each segment has source,
destination port number
▪ host uses IP addresses & port
numbers to direct segment to
appropriate socket
source port # dest port #
32 bits
application
data
(payload)
other header fields
TCP/UDP segment format
Mỗi port: 16 bits
port máy gửi
port của máy nhận
tối đa 2^16 ứng dụng
chạy cùng lúc
Địa chỉ IP được đóng gói
ở tầng network

Connectionless demultiplexing
Recall:
▪ when creating socket, must
specify host-local port #:
DatagramSocket mySocket1
= new DatagramSocket(12534);
when receiving host receives
UDP segment:
• checks destination port # in
segment
• directs UDP segment to
socket with that port #
▪ when creating datagram to
send into UDP socket, must
specify
• destination IP address
• destination port #
IP/UDP datagrams with same dest.
port #, but different source IP
addresses and/or source port
numbers will be directed to same
socket at receiving host
Port: 12534
Muốn gửi đi cho máy nào phải biết IP và port
Chỉ cần xác định chung một port thì gửi
đi và server đều nhận, không cần biết
client 1 gửi hay client 2 gửi

Connectionless demultiplexing: an example
DatagramSocket
serverSocket = new
DatagramSocket
(6428);
transport
application
physical
link
network
P3
transport
application
physical
link
network
P1
transport
application
physical
link
network
P4
DatagramSocket mySocket1 =
new DatagramSocket (5775);
DatagramSocket mySocket2 =
new DatagramSocket
(9157);
source port: 9157
dest port: 6428
source port: 6428
dest port: 9157
source port: ?
dest port: ?
source port: ?
dest port: ?
5775
6428
6428
5775

Connection-oriented demultiplexing
▪ TCP socket identified by
4-tuple:
• source IP address
• source port number
• dest IP address
• dest port number
▪ server may support many
simultaneous TCP sockets:
• each socket identified by its
own 4-tuple
• each socket associated with
a different connecting client
▪ demux: receiver uses all
four values (4-tuple) to
direct segment to
appropriate socket

Connection-oriented demultiplexing: example
transport
application
physical
link
network
P1
transport
application
physical
link
P4
transport
application
physical
link
network
P2
host: IP
address A
host: IP
address C
network
P6
P5
P3
source IP,port: A,9157
dest IP, port: B,80
source IP,port: B,80
dest IP,port: A,9157 source IP,port: C,5775
dest IP,port: B,80
source IP,port: C,9157
dest IP,port: B,80
server: IP
address B
Three segments, all destined to IP address: B,
dest port: 80 are demultiplexed to different sockets

Summary
▪ Multiplexing, demultiplexing: based on segment, datagram
header field values
▪ UDP: demultiplexing using destination port number (only)
▪ TCP: demultiplexing using 4-tuple: source and destination IP
addresses, and port numbers
▪ Multiplexing/demultiplexing happen at all layers

Chapter 3: roadmap

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
UDP: Transport Layer Actions
transport
(UDP)
physical
link
network (IP)
application

SNMP server
SNMP client
transport
(UDP)
physical
link
network (IP)
application
transport
(UDP)
physical
link
network (IP)
application
UDP sender actions:
SNMP msg
▪ is passed an application-
layer message
▪ determines UDP segment
header fields values
▪ creates UDP segment
▪ passes segment to IP
UDPh
UDPh SNMP msg

SNMP server
SNMP client
transport
(UDP)
physical
link
network (IP)
application
transport
(UDP)
physical
link
network (IP)
application
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
32 bits
application
data
(payload)
UDP segment format
length checksum
length, in bytes of
UDP segment,
including header
data to/from
application layer

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
• segment structure
• flow control
• connection management

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
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

TCP sequence numbers, ACKs
Sequence numbers:
• byte stream “number” of
first byte in segment’s data
sequence number
checksum
rwnd
urg pointer
outgoing segment from receiver
A
sent
ACKed
sent, not-
yet ACKed
(“in-flight”)
usable
but not
yet sent
not
usable
window size
N
sender sequence number space
sequence number
checksum
rwnd
urg pointer
outgoing segment from sender
Acknowledgements:
• seq # of next byte expected
from other side
• cumulative ACK
Q: how receiver handles out-of-
order segments
• A: TCP spec doesn’t say, - up
to implementor

TCP sequence numbers, ACKs
host ACKs receipt
of echoed ‘C’
host ACKs receipt
of‘C’, echoes back ‘C’
simple telnet scenario
Host B
Host A
User types‘C’
Seq=42, ACK=79, data = ‘C’
Seq=79, ACK=43, data = ‘C’
Seq=43, ACK=80

TCP round trip time, timeout
Q: how to set TCP timeout
value?
▪ longer than RTT, but RTT varies!
▪ too short: premature timeout,
unnecessary retransmissions
▪ too long: slow reaction to
segment loss
Q: how to estimate RTT?
▪ SampleRTT:measured time
from segment transmission until
ACK receipt
• ignore retransmissions
▪ SampleRTT will vary, want
estimated RTT “smoother”
• average several recent
measurements, not just current
SampleRTT

TCP Sender (simplified)
event: data received from
application
▪ create segment with seq #
▪ seq # is byte-stream number
of first data byte in segment
▪ start timer if not already
running
• think of timer as for oldest
unACKed segment
• expiration interval:
TimeOutInterval
event: timeout
▪ retransmit segment that
caused timeout
▪ restart timer
event: ACK received
▪ if ACK acknowledges
previously unACKed segments
• update what is known to be
ACKed
• start timer if there are still
unACKed segments

TCP Receiver: ACK generation [RFC 5681]
Event at receiver
arrival of in-order segment with
expected seq #. All data up to
expected seq # already ACKed
arrival of in-order segment with
expected seq #. One other
segment has ACK pending
arrival of out-of-order segment
higher-than-expect seq. # .
Gap detected
arrival of segment that
partially or completely fills gap
TCP receiver action
delayed ACK. Wait up to 500ms
for next segment. If no next segment,
send ACK
immediately send single cumulative
ACK, ACKing both in-order segments
immediately send duplicate ACK,
indicating seq. # of next expected byte
immediate send ACK, provided that
segment starts at lower end of gap

TCP: retransmission scenarios
lost ACK scenario
Host B
Host A
Seq=92, 8 bytes of data
ACK=100
X
ACK=100
timeout
premature timeout
Host B
Host A
Seq=92, 8
bytes of data
ACK=120
timeout
ACK=100
ACK=120
SendBase=100
SendBase=120
SendBase=120
SendBase=92
send cumulative
ACK for 120

TCP: retransmission scenarios
cumulative ACK covers
for earlier lost ACK
Host B
Host A
X
ACK=100
ACK=120

Chapter 3: roadmap
• segment structure
• flow control
• connection management

TCP flow control
application
process
TCP socket
receiver buffers
TCP
code
IP
code
receiver protocol stack
Q: What happens if network
layer delivers data faster than
application layer removes
data from socket buffers?
from sender
Application removing
data from TCP socket
buffers
receive window
flow control: # bytes
receiver willing to accept

TCP flow control
application
process
TCP socket
receiver buffers
TCP
code
IP
code
receiver protocol stack
Q: What happens if network
layer delivers data faster than
application layer removes
data from socket buffers?
receiver controls sender, so
sender won’t overflow
receiver’s buffer by
transmitting too much, too fast
flow control
from sender
Application removing
data from TCP socket
buffers

TCP flow control
▪ TCP receiver “advertises” free buffer
space in rwnd field in TCP header
• RcvBuffer size set via socket
options (typical default is 4096 bytes)
• many operating systems autoadjust
RcvBuffer
▪ sender limits amount of unACKed
(“in-flight”) data to received rwnd
▪ guarantees receive buffer will not
overflow
buffered data
free buffer space
rwnd
RcvBuffer
TCP segment payloads
to application process
TCP receiver-side buffering

TCP flow control
▪ TCP receiver “advertises” free buffer
space in rwnd field in TCP header
• RcvBuffer size set via socket
options (typical default is 4096 bytes)
• many operating systems autoadjust
RcvBuffer
▪ sender limits amount of unACKed
(“in-flight”) data to received rwnd
▪ guarantees receive buffer will not
overflow
flow control: # bytes receiver willing to accept
receive window
TCP segment format

TCP connection management
before exchanging data, sender/receiver “handshake”:
▪ agree to establish connection (each knowing the other willing to establish connection)
▪ agree on connection parameters (e.g., starting seq #s)
connection state: ESTAB
connection variables:
seq # client-to-server
server-to-client
rcvBuffer size
at server,client
application
network
connection state: ESTAB
connection Variables:
seq # client-to-server
server-to-client
rcvBuffer size
at server,client
application
network
Socket clientSocket =
newSocket("hostname","port number");
Socket connectionSocket =
welcomeSocket.accept();

TCP 3-way handshake
SYNbit=1, Seq=x
choose init seq num, x
send TCP SYN msg
ESTAB
SYNbit=1, Seq=y
ACKbit=1; ACKnum=x+1
choose init seq num, y
send TCP SYNACK
msg, acking SYN
ACKbit=1, ACKnum=y+1
received SYNACK(x)
indicates server is live;
send ACK for SYNACK;
this segment may contain
client-to-server data
received ACK(y)
indicates client is live
SYNSENT
ESTAB
SYN RCVD
Client state
LISTEN
Server state
LISTEN
clientSocket = socket(AF_INET, SOCK_STREAM)
serverSocket = socket(AF_INET,SOCK_STREAM)
serverSocket.bind((‘’,serverPort))
serverSocket.listen(1)
connectionSocket, addr = serverSocket.accept()
clientSocket.connect((serverName,serverPort))

Closing a TCP connection
▪ client, server each close their side of connection
• send TCP segment with FIN bit = 1
▪ respond to received FIN with ACK
• on receiving FIN, ACK can be combined with own FIN
▪ simultaneous FIN exchanges can be handled

Chapter 3: roadmap

TCP congestion control: AIMD
▪ approach: senders can increase sending rate until packet loss
(congestion) occurs, then decrease sending rate on loss event
AIMD sawtooth
behavior: probing
for bandwidth
TCP
sender
Sending
rate
time
increase sending rate by 1
maximum segment size every
RTT until loss detected
Additive Increase
cut sending rate in half at
each loss event
Multiplicative Decrease

TCP AIMD: more
Multiplicative decrease detail: sending rate is
▪ Cut in half on loss detected by triple duplicate ACK (TCP Reno)
▪ Cut to 1 MSS (maximum segment size) when loss detected by
timeout (TCP Tahoe)
Why AIMD?
▪ AIMD – a distributed, asynchronous algorithm – has been
shown to:
• optimize congested flow rates network wide!
• have desirable stability properties

Chapter 3: summary
▪ principles behind transport
layer services:
• multiplexing, demultiplexing
• flow control
▪ instantiation, implementation
in the Internet
• UDP
• TCP
Up next:
▪ leaving the network
“edge” (application,
transport layers)
▪ into the network “core”
▪ two network-layer
chapters:
• data plane
• control plane

Chapter_3_v8.1.pdf

More Related Content

Similar to Chapter_3_v8.1.pdf (20)

Recently uploaded (20)

Chapter_3_v8.1.pdf