Transport Layer

Sources

Computer Networking: A Top-Down Approach TCP/IP Protocol Suite

Transport Layer: 3-2
Top Down Approach

Message Application
User Datagram Protocol (UDP)
UDP / TCP segment Transport Transmission Control Protocol (TCP)

Network
Data Link
Physical
Protocols @ Different layers

Source: http://walkwidnetwork.blogspot.com/2013/04/application-layer-internet-protocol.html
Transport Layer Protocols

Transport Layer: 3-5

 Data Transfer between Two Remote Machines
Communication between two remote Machine
Application Application
Transport End-to-end protocol Transport
Network Network Network
Data Link Data Link Data Link Data Link Data Link
Physical Physical Physical Physical Physical
Network layer versus transport layer

TCP/IP Protocol Suite

Transport Layer: 3-7
Port numbers

TCP/IP Protocol Suite

Transport Layer: 3-8
IP addresses versus port numbers

TCP/IP Protocol Suite Transport Layer: 3-9

Socket address

TCP/IP Protocol Suite

Transport Layer: 3-10
 ICANN (Internet Corporation for Assigned Names and Numbers) Ranges

• The well-known port numbers are less than 1,024. These are used by processes that provide widely
used types of network services.
• Registered Port Numbers: They are assigned by IANA (Internet Assigned Numbers Authority,
Owner ICANN) for specific service upon application by a requesting entity.
• Dynamic Port Numbers: This range is used for private or customized services, for temporary purposes,
and for automatic allocation
https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers#Well-known
TCP/IP Protocol Suite
_ports
Socket Pair
application application
proce socket proce controlled by
ss ss app developer

transport transport
network network controlled
link
by OS
link Internet
physical physical

Server socket address

20.22.18.11:80
Client socket address FTP
19.12.14.22:5000 Server
(port
21)
HTTP
Client Server
Connection socket pair (port
(19.12.14.22:5000, 20.22.18.11:80) 80)

Client host address Server host address

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

Transport Layer: 3-13

Transport services and protocols
applicatio
n

▪ provide logical communication transport

mobile network
network data link
between application processes physical
national or global
ISP

log spor
running on different hosts

tra
ica
n
▪ transport protocols actions in end

l en
d-e
t
systems:

nd
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 applicatio
n
network

▪ two transport protocols available to

transport
network
data link
physical
Internet applications enterprise
• TCP, UDP network
Transport Layer: 3-14
Transport Layer Actions

Sender:
application ▪ is passed an application
app. msg
application-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: 3-15

Transport Layer Actions

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

physical physical
Th app. msg

Transport Layer: 3-16

Two principal Internet transport protocols
applicatio

▪TCP: Transmission Control

n
transport
mobile network
network data link
Protocol physical
national or global
ISP
• reliable, in-order delivery

log spor
tra
ica
n
• congestion control

l en
d-e
• flow control

t
nd
• connection setup local or
regional
▪UDP: User Datagram Protocol home network
ISP

content
• unreliable, unordered delivery provider
network datacenter
• no-frills extension of “best-effort” IP applicatio
n
network

▪services not available:

transport
network
data link
physical
• delay guarantees enterprise

• bandwidth guarantees network

Transport Layer: 3-17
 Transport Layer Services

✔ Encapsulation and Decapsulation

✔ Multiplexing and Demultiplexing
✔ Flow Control
✔ Error Control
✔ Congestion Control
✔ Connectionless and Connection-Oriented Services

TCP/IP Protocol Suite

Transport Layer: 3-18
Encapsulation and Decapsulation

TCP/IP Protocol Suite

19
Multiplexing and Demultiplexing

TCP/IP Protocol Suite

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

application

application P1 P2 application socket

P3 transport P4 process
transport network transport
network link network
link physical link
physical physical

Transport Layer: 3-21

 HTTP server
client
application application
HTTP
msg
transport
Ht HTTP
msg
transport Hnnetwork
Ht HTTP transport
msg
Hn Hnetwork link network
t HTTP
msg physical
link link
physical physical

Hn Ht HTTP
msg

Transport Layer: 3-22

 Q: how did transport layer know to deliver message to Firefox
browser process rather then Netflix process or Skype process?

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

Transport Layer: 3-23

 ?

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)
numbers to direct segment to
appropriate socket TCP/UDP segment format

Transport Layer: 3-30

Flow control

TCP/IP Protocol Suite

31
Error Control

Packets

Error
Control
1. Checksum Error Control Service is responsible for:
2. Acknowledgement 1. Detecting and discarding corrupted packets.
3. Retransmission 2. Keeping track of lost and discarded packets and resending them
3. Recognizing duplicate packets and discarding them.
4. Buffering Out-of-Order packets until the missing packets arrive.

TCP/IP Protocol Suite

32
Flow Control and Error Control Protocol

✔Simple Protocol
✔ Stop-and-Wait Protocol
✔ Go-Back-N Protocol
✔ Selective-Repeat Protocol

33
Flow Control and Error Control Protocol
Cont..

Flow control: It coordinates amount of data that can be sent before receiving an ack.
• Stop and Wait
• Sliding window

Error Control: It is refer to the methods of error detection and retransmission. The most
popular retransmission scheme is known as Automatic-Repeat-Request (ARQ). Three
popular ARQ techniques

34
Chapter 3: roadmap
● Transport-layer services
● Connection-oriented transport:
TCP
• segment structure
• reliable data transfer
• flow control
• connection management

● Connectionless transport: UDP

● Principles of congestion control
● TCP congestion control

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

● TCP is byte stream protocol. Every byte that is being sent is

actually cunted.

TCP/IP Protocol Suite

37
Sending and receiving buffers

TCP/IP Protocol Suite

38
TCP segments

TCP/IP Protocol Suite

39
TCP FEATURES

• TCP has several features

✔Numbering System
✔ Flow Control
✔ Error Control
✔ Congestion Control

40
TCP sequence numbers, ACKs
outgoing segment from
Sequence numbers: sender
source port
#
dest port #
sequence number
• byte stream “number” of acknowledgement
number rwn
first byte in segment’s data checksum urgd pointer

window
Acknowledgements: size
N
• seq # of next byte expected
from other side sender sequence number space

• cumulative ACK sent sent, usable not

ACKe not-yet but not usable
d ACKed yet sent
Q: how receiver handles 41
(“in-flight”)
out-of-order segments outgoing segment from
receiver
source port dest port #
• A: TCP spec doesn’t say, - up #
sequence number

to implementor acknowledgement
number
A rwn
checksum urgd pointer
 TCP sequence numbers

● Both sides of TCP connection randomly choose an initial sequence

number.
● This is done to minimize the possibility that a segment that is still
present in the network from an earlier, already terminated
connection between two hosts is mistake for a valid segment in a
later connection between these same two hosts.
TCP sequence numbers, ACKs
Host A Host B

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, 43
ACK=80

simple telnet scenario

Numbering System
• The bytes of data being transferred in each connection are numbered by TCP.

• The numbering starts with an arbitrarily generated number.

• Suppose a TCP connection is transferring a file of 5,000 bytes. The first byte is numbered 10,001.
What are the sequence numbers for each segment if data are sent in five segments, each carrying
1,000 bytes?

Solution
The following shows the sequence number for each segment:

TCP/IP Protocol Suite 44

Cont..

• The value in the sequence number field of a segment defines

the number assigned to the first data byte contained in that
segment.

• The value of the acknowledgment field in a segment defines the

number of the next byte a party expects to receive.

• The acknowledgment number is cumulative.

45
TCP segment format

• Before discussing TCP in more detail, let us discuss the TCP packets themselves. A packet in
TCP is called a segment.

TCP/IP Protocol Suite 46

 TCP segment structure
32 bits

source port # dest port # segment seq #: counting

ACK: seq # of next expected sequence number bytes of data into bytestream
byte; A bit: this is an ACK (not segments!)
acknowledgement number
head not
length (of TCP header) len used U A PR S F receive window flow control: # bytes
Internet checksum checksum Urg data pointer receiver willing to accept
options (variable length)

TCP options
application data sent by
RST, SYN, FIN: connection data application into
management (variable length) TCP socket

47
TCP Flag Bits

In practice, the PSH, URG, and the urgent pointer are not used.

48
Connection establishment using three-way handshaking
● A SYN segment cannot carry data,
but it consumes one sequence
number.
● A SYN + ACK segment cannot carry
data, but does consume one
sequence number.
● An ACK segment, if carrying no
data, consumes no sequence
number.
 Connection establishment using three-way handshaking
1. Sender starts the process with the following:
● Sequence number (Seq=521): contains the random
initial sequence number generated at the sender
side.
● Syn flag (Syn=1): request the receiver to synchronize
its sequence number with the above-provided
sequence number.
● Maximum segment size (MSS=1460 B): sender tells
its maximum segment size, so that receiver sends
datagram which won’t require any fragmentation.
MSS field is present inside Option field in TCP
header.
● Window size (window=14600 B): sender tells
about his buffer capacity in which he has to store
https://www.geeksforgeeks.org/tcp-connection-establishment/ messages from the receiver.
 Connection establishment using three-way handshaking
2. TCP is a full-duplex protocol so both sender and receiver require
a window for receiving messages from one another.

● Sequence number (Seq=2000): contains the random initial

sequence number generated at the receiver side.
● Syn flag (Syn=1): request the sender to synchronize its
sequence number with the above-provided sequence number.
● Maximum segment size (MSS=500 B): receiver tells its
maximum segment size, so that sender sends datagram which
won’t require any fragmentation.
● MSS field is present inside Option field in TCP header.
● Since MSSreceiver < MSSsender, both parties agree for minimum
MSS i.e., 500 B to avoid fragmentation of packets at both
ends.
Therefore, receiver can send maximum of 14600/500 = 29 packets. This is the receiver's sending
window size.
Pseudoheader added to the TCP segment

The use of the checksum in TCP is mandatory.

TCP/IP Protocol Suite
53
Encapsulation

TCP/IP Protocol Suite

54
Rules for Generating the ACKs

1. When one end sends a data segment to the other end, it must
include an ACK. That gives the next sequence number it expects to
receive. (Piggyback)

2. The receiver needs to delay sending (until another segment arrives

or 500ms) an ACK segment if there is only one outstanding in-order
segment. It prevents ACK segments from creating extra traffic.

3. There should not be more than 2 in-order unacknowledged

segments at any time. It prevent the unnecessary retransmission

55
Rules for Generating the ACKs Cont..

4. When a segment arrives with an out-of-order sequence number

that is higher than expected, the receiver immediately sends an
ACK segment announcing the sequence number of the next
expected (not received) segment. (for fast retransmission)

5. When a missing segment arrives, the receiver sends an ACK

segment to announce the next sequence number expected.

6. If a duplicate segment arrives, the receiver immediately sends an

ACK.
56
Some Scenarios: Normal operation

TCP/IP Protocol Suite 57

Lost segment

The receiver TCP delivers only ordered data to the

TCP/IP Protocol Suite process.
58
 Fast retransmission

● Receipt of three
duplicate ACKs
indicates 3
segments received
after a missing
segment – lost
segment is likely.
So retransmit!
● Retransmission
after 3 duplicates
Acknowledgement
(or) early
Retransmission
TCP/IP Protocol Suite
59
 Lost acknowledgment

Lost acknowledgment corrected by cumulative ack

TCP/IP Protocol Suite

60
Lost acknowledgment corrected by resending a segment

TCP/IP Protocol Suite

61
ACK and Out of Order Handling in TCP

Acknowledgement in TCP – Cumulative acknowledgement

Receiver has received bytes 0, 1, 2, _, 4, 5, 6, 7

• TCP sends a cumulative acknowledgement with ACK number 3, acknowledging
everything up to byte 2
• Once 4 is received, a duplicate ACK with ACK number 3 (next expected byte) is
forwarded
• After timeout, sender retransmits byte 3
• Once byte 3 is received, it can send another cumulative ACK with ACK number 8 (next
expected byte)

62
Window size or Advertisement Window

● A sender should never send more than what the receiver receives.
● During connection establishment phase, both sides advertise
window size.
● Importance of persistence timer (PT).
TCP round trip time, timeout
Q: how to set TCP timeout Q: how to estimate RTT?
value? ▪ SampleRTT:measured time
▪ longer than RTT, but RTT varies! from segment transmission until
ACK receipt
▪ too short: premature timeout,
• ignore retransmissions
unnecessary retransmissions
▪ SampleRTT will vary, want
▪ too long: slow reaction to estimated RTT “smoother”
segment loss • average several recent
measurements, not just current
SampleRTT

64
TCP round trip time, timeout
EstimatedRTT = (1- α)*EstimatedRTT + α*SampleRTT
▪ exponential weighted moving average (EWMA)
▪ influence of past sample decreases exponentially fast
▪ typical value: α = 0.125
RTT: gaia.cs.umass.edu to
fantasia.eurecom.fr

(milliseconds)
RTT

sampleRTT
EstimatedRTT

time
(seconds) 65
TCP round trip time, timeout
▪ timeout interval: EstimatedRTT plus “safety margin”
• large variation in EstimatedRTT: want a larger safety margin
TimeoutInterval = EstimatedRTT + 4*DevRTT

estimated RTT “safety margin”

▪ DevRTT: EWMA of SampleRTT deviation from EstimatedRTT:

DevRTT = (1-β)*DevRTT + β*|SampleRTT-EstimatedRTT|
(typically, β = 0.25)

* Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/
66
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

67
Principles of congestion control
Congestion:
▪ informally: “too many sources sending too much data too fast for
network to handle”
• long delays (queueing in router buffers)
• packet loss (buffer overflow at routers)

▪ different from flow control! congestion control:

too many senders,
sending too fast

flow control: one sender

too fast for one receiver
68
Congestion control
• Congestion in a network may occur if the load on the
network—the number of packets sent to the network—is greater
than the capacity of the network—the number of packets a
network can handle.
• Congestion control refers to the mechanisms and techniques to
control the congestion and keep the load below the capacity.
Approaches towards congestion control

End-end congestion control:

● no explicit feedback from
network
● congestion inferred from ACK
dat dat
observed loss, delay s
a a ACK
s
▪ Approach taken by TCP

70
Approaches towards congestion control

Network-assisted congestion
control:
explicit congestion info
▪ routers provide direct feedback
to sending/receiving hosts with
flows passing through congested ACK
dat
a
dat
ACK
a
router s
s
▪ may indicate congestion level or
explicitly set sending rate
● TCP ECN (Explicit Congestion
Notification)
71
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

72
TCP: Triggering congestion control
● Two ways to trigger a congestion notification in TCP – (1) RTO, (2) Duplicate ACK

● RTO: A sure indication of congestion, however time consuming

● Duplicate ACK: Receiver sends a duplicate ACK when it receives out of order
segment
○ A loose way of indicating congestion
○ TCP arbitrarily assumes that THREE duplicate ACKs (DUPACKs) imply that a
packet has been lost – triggers congestion control mechanism
○ The identity of the lost packet can be inferred – the very next packet in
sequence
○ Retransmit the lost packet and trigger congestion control

73
 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
▪ Chiu and Jain (1989): Let w(t) be
the sending rate. a (a > 0) is the
additive increase factor, and b
TCP sender Sending

(0<b<1) is the multiplicative

decrease factor
rate

74
time
TCP AIMD: more
Multiplicative decrease detail: sending rate is
▪ Cut to 1 MSS (maximum segment size) when loss detected by
timeout (TCP Tahoe)
▪ Cut in half on loss detected by triple duplicate ACK (TCP Reno)

75
TCP Congestion Control

• TCP maintains a Congestion Window (CWnd) – number of bytes the sender

may have in the network at any time

• Sender Window (SWnd) = Min (CWnd, RWnd)

• RWnd – Receiver advertised window size

76
TCP Congestion Control

• In the slow-start phase the window size starts from

1 and grows exponentially until it reaches the
threshold.
• After it reaches the threshold, the congestion
avoidance (additive increase) procedure allows the
window size to increase linearly until a timeout
occurs or the maximum window size is reached.

77
TCP slow start
Host Host
▪ When connection begins, A B

increase rate exponentially

one
until first loss event: segment

RT
T
• initially cwnd = 1 MSS two
• double cwnd every RTT segments

• done by incrementing cwnd

for every ACK received four
segments

▪ summary: initial rate is

slow, but ramps up
ti
exponentially fast m
e
78
TCP: from slow start to congestion avoidance

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/
79
Slow Start Cont..

• Slow start causes exponential growth, eventually it will send too many packets
into the network too quickly.

• To keep slow start under control, the sender keeps a threshold for the
connection called the slow start threshold (ssthresh).

• Whenever a packet loss is detected by a timeout, the ssthresh is set to be half of

the congestion window

80
 Congestion Control: Slow start, exponential increase

In the slow start algorithm, the

size of the congestion window
increases exponentially until it
reaches a threshold.

TCP/IP Protocol Suite

81
 Congestion avoidance, additive increase

In the congestion
avoidance algorithm
the size of the
congestion window
increases additively
until
congestion is
detected.

TCP/IP Protocol Suite

82
 Congestion example

TCP/IP Protocol Suite

83
Fast Retransmission - TCP Tahoe

Use THREE DUPACK as the sign of congestion

Once 3 DUPACKs have been received,

Retransmit the lost packet (fast retransmission)
Set ssthresh as half of the current CWnd
Set CWnd to 1 MSS

84
Fast Recovery – TCP Reno
● Once a congestion is detected through 3 DUPACKs, do TCP really
need to set CWnd = 1 MSS ?

● DUPACK means that some segments are still flowing in the network
– a signal for temporary congestion, but not a prolonged one

● Immediately transmit the lost segment (fast retransmit), then transmit

additional segments based on the DUPACKs received (fast recovery)

85
 Fast Recovery – TCP Reno
● Fast recovery:
● set ssthresh to half of the current congestion window. Retransmit the missing segment.
● set cwnd = ssthresh + 3.
● Each time another duplicate ACK arrives, set cwnd = cwnd + 1. Then, send a new data segment
if allowed by the value of cwnd.
● Once receive a new ACK (an ACK which acknowledges all intermediate segments sent between
the lost packet and the receipt of the first duplicate ACK), exit fast recovery. This causes setting
cwnd to ssthresh (the ssthresh in step 1). Then, continue with linear increasing due to
congestion avoidance algorithm.

86
Example: Fast Recovery – TCP Reno

88
Summary: TCP congestion control
Ne
Ne w
w new ACK
duplicate
ACK
dupACKcou
AC
new ACK
K!
.
dupACKcount = 0
AC
cwnd = cwnd + MSS (MSS/cwnd)
K!
nt++ cwnd = cwnd+MSS transmit new segment(s), as allowed
dupACKcount = 0
Λ transmit new segment(s), as allowed
cwnd = 1 MSS
ssthresh = 64 KB cwnd >
dupACKcount = 0 slow ssthresh congestion
start time avoidance
ssthresh
out = cwnd/2
cwnd = 1 MSS duplicate
time dupACKcount = 0 ACK
dupACKcou
out = cwnd/2
ssthresh retransmit missing segment nt++
cwnd = 1 MSS
dupACKcount = 0
retransmit missing segment
time
Ne
w
out
ssthresh = cwnd/2 AC
cwnd = 1 K!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

89
TCP Congestion Control Algorithms

● TCP Cubic: Used by Many Linux

systems

90
Chapter 3: roadmap
● Transport-layer services
● Connectionless transport: UDP
● Connection-oriented transport:
TCP
• segment structure
• reliable data transfer
• flow control
• connection management
● Principles of congestion control
● TCP congestion control

91
UDP: User Datagram Protocol
▪ Simple and quick Internet Why is there a UDP?
transport protocol ▪ no connection
▪ “best effort” service, UDP establishment (which can
segments may be: add RTT delay)
• lost ▪ simple: no connection state
• delivered out-of-order to at sender, receiver
app ▪ small header size
▪ connectionless: ▪ no congestion control
• no handshaking between ▪ UDP can blast away as fast as
desired!
UDP sender, receiver ▪ can function in the face of
• each UDP segment handled congestion
independently of others
92
UDP: User Datagram Protocol
▪ UDP use:
▪ streaming multimedia apps (loss tolerant, rate sensitive)
▪ DNS
▪ Simple Network Management Protocol (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

93
UDP: User Datagram Protocol [RFC 768]

94
 UDP Header

Source: TCP/IP Protocol Suite

95
UDP segment header cont..
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

96
Questions

The following is a dump of a UDP header in hexadecimal

format.

a. What is the source port number?

b. What is the destination port number?
c. What is the total length of the user datagram?
d. What is the length of the data?
e. Is the packet directed from a client to a server or vice versa?

TCP/IP Protocol Suite

97
Answers

Solution
a. The source port number is the first four hexadecimal digits (CB84)16 or 52100.
b. The destination port number is the second four hexadecimal digits (000D)16 or 13.
c. The third four hexadecimal digits (001C)16 define the length of the whole UDP
packet as 28 bytes.
d. The length of the data is the length of the whole packet
minus the length of the header, or 28 – 8 = 20 bytes.
e. Since the destination port number is 13 (well-known port), the packet is from the
client to the server.

TCP/IP Protocol Suite 98

Encapsulation and decapsulation

Source: TCP/IP Protocol

Suite 99
 Multiplexing and demultiplexing

SOURCE: TCP/IP Protocol

100
Suite
UDP checksum
Goal: detect errors (i.e., flipped bits) in transmitted segment
1st 2nd
number number sum
Transmitted: 5 6 11

Received: 4 6 11

receiver-computed sender-computed
checksum
= checksum (as received)

101
UDP 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
fields and IP addresses) as segment
sequence of 16-bit integers ▪ check if computed checksum equals
▪ checksum: addition (one’s checksum field value:
complement sum) of segment
content • Not equal - error detected
▪ checksum value put into • Equal - no error detected. But maybe
UDP checksum field errors nonetheless? More later ….

102
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/
103
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!

104
UDP Checksum Calculations

105
 Cont..

At receiver, add everything including checksum and complement if solution is zero then packet is correctly received.
Source: TCP/IP Protocol Suite, Forouzan
Point to Note

• UDP is an example of the connectionless simple protocol

we discussed in as a part of Transport layer services with
the exception of an optional checksum added to packets
for error detection.

TCP/IP Protocol Suite

107
Summary: UDP
▪ Simple 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) 🡪 Optional
▪ build additional functionality on top of UDP in application layer
(e.g., HTTP/3)
DNS
● The Domain Name System (DNS) is a hierarchical and distributed naming
system for computers, services, and other resources in the Internet or
other Internet Protocol (IP) networks.
● It associates various information with domain names (identification strings)
assigned to each of the associated entities.
● Most prominently, it translates readily memorized domain names to the
numerical IP addresses needed for locating and identifying computer
services and devices with the underlying network protocols.
HTTP
● The Hypertext Transfer Protocol (HTTP) is the foundation of the World
Wide Web, and is used to load webpages using hypertext links.
● HTTP is an application layer protocol designed to transfer information
between networked devices and runs on top of other layers of the network
protocol stack.
● HTTP functions as a request–response protocol in the client–server
model.
● A web browser, for example, may be the client whereas a process, named
web server, running on a computer hosting one or more websites may be
the server.
● The client submits an HTTP request message to the server. The server,
which provides resources such as HTML files and other content or
performs other functions on behalf of the client, returns a response
message to the client.
● The response contains completion status information about the request
and may also contain requested content in its message body.
HTTP
● HTTP is inband protocol (both commands and data use same
connection).
● HTTP is stateless protocol
● HTTP 1.0: non-persistant connection
● HTTP 1.1: persistent connection
● HTTP methods
○ Head
○ Get
○ Post
○ Put
○ Delete
○ ….
FTP, SMTP, and POP
● Filezilla
Optional slides
A New Transport Protocol

QUIC: Quick UDP Internet Connections

HTTP/3: HTTP over QUIC is next Generation

115
 Introduction: Change
• Increasing scale of ............ everything
• Flow size changes
• Flow count increases (e.g., web pages)
• Flow diversity increase (e.g., web pages)
https request
o Multiple connections
4x in 4 years

Web page size

116
HTTP Network Stack
HTTP / 1.1
• January 1997
HTTP • Many parallel TCP connection
TLS 1.2+ (6 connections per host name)
TCP • HTTP head of line blocking

IP HTTP / 2
• May 2015
• Using Single connection per
host
• Many parallel streams
• TCP head of line blocking
TLS – Transport Layer Security
TCP – Transport Control Protocol
IP – Internet Protocol

https://http3-explained.haxx.se/en/why-quic 117
QUIC: Quick UDP Internet
Connections
● application-layer protocol, on top of UDP
○ increase performance of HTTP
○ deployed on many Google servers, apps (Chrome, mobile YouTube app)

HTTP/ HTTP/2 (slimmed)

Application 2 HTTP/3
TL QUI
S C
Transport TCP UD
P
Network IP IP

HTTP/2 over HTTP/2 over QUIC over

TCP UDP
118
HTTP Over QUIC Network Stack
HTTP over TCP HTTP over QUIC
HTTP / 3

• No - TCP head of line blocking

▪ streams are independent to each other
• Faster handshake
▪ Earlier data
• More encryption, always • Steam impact not connection impact
• Over UDP (Connection less, No resend, No flow control)

https://http3-explained.haxx.se/en/why-quic 119
QUIC: Quick UDP Internet
Connections
adopts approaches we’ve studied in this chapter for connection establishment,
error control, congestion control

• error and congestion control: “Readers familiar with TCP’s loss detection and
congestion control will find algorithms here that parallel well-known TCP ones.”
[from QUIC specification]
• connection establishment: reliability, congestion control, authentication,
encryption, state established in one RTT

● multiple application-level “streams” multiplexed over single QUIC connection

○ separate reliable data transfer, security
○ common congestion control

120
QUIC: Connection
establishment

TCP handshake
(transport layer) QUIC handshake

TLS handshake
dat
(security) a
dat
a
TCP (reliability, congestion control QUIC: reliability, congestion control,
state) + TLS (authentication, crypto authentication, crypto state
state)
▪2 serial handshakes ▪ 1 handshake

121
 QUIC: streams: parallelism, no HOL
blocking
HTTP HTTP
GET GET HTTP
GET
HTTP HTTP
application

GET GET
HTTP
GET QUIC QUIC QUIC QUIC QUIC QUIC
encrypt encrypt encrypt encrypt encrypt encrypt
QUI QUI QUI QUI QUI QUI
TLS encryption TLS encryption C C C C error!
C C
RDT RDT RDT RDT RDT RDT
QUIC Cong. Cont. QUIC Cong. Cont.
TCP RDT TCP
error! RDT
transport

TCP Cong. Contr. TCP Cong. Contr. UDP UDP

(a) HTTP 1.1 (b) HTTP/2 with QUIC: no HOL blocking

122
 QUIC Status

RFC 9000

https://conferences.sigcomm.org/sigcomm/2020/tutorial-quic.ht 123
Source: SIGCOMM 2020, QUIC Tutorial, Link: