Chapter 3: Transport Layer

The transport layer is positioned between the application and network layers and plays a
critical role in providing communication services directly to application processes running on
different hosts. 1This chapter examines the principles of transport layer services, particularly
focusing on the Internet's

TCP and UDP protocols. 2It covers how the transport layer extends the network layer's
host-to-host delivery to process-to-process delivery, the fundamental problem of reliable
data transfer, and the mechanisms for network congestion control. 333333333

<hr>

3.1 Introduction and Transport-Layer Services

A transport-layer protocol provides

logical communication between application processes on different hosts. 4This means that
from an application's viewpoint, it seems as if the hosts are directly connected, even though
they might be separated by numerous routers and links across the globe. 5Application
processes use this logical communication to send messages without worrying about the
underlying physical infrastructure. 6

Transport-layer protocols are implemented only in the

end systems, not in network routers. 7

●​ On the​
sending side, the transport layer converts application messages into transport-layer
segments. 8It may break large messages into smaller chunks and adds a transport-layer
header to each one. 9These segments are then passed to the network layer, where they
are encapsulated into network-layer packets (datagrams). 10​
 ●​ On the​
receiving side, the network layer extracts the segment from the datagram and passes it
up to the transport layer, which processes it and makes the data available to the
receiving application process. 11​
​
Network routers only act on network-layer fields and do not examine the transport-layer
segment headers. 12​

3.1.1 Relationship Between Transport and Network Layers

The key distinction between the two layers is:

●​ Transport Layer: Provides logical communication between processes running on
different hosts. 13​

●​ Network Layer: Provides logical communication between hosts. 14​

A Household Analogy: Imagine two houses (hosts), one on the East Coast and one on the
West Coast, each with a dozen kids (processes). 15The kids write letters (application
messages) to their cousins in the other house. 16

●​ The​
postal service (network-layer protocol) provides mail delivery from house to house.
171717
It doesn't care which specific person sent or will receive the letter. 18​

●​ In each house, one kid (Ann on the West Coast, Bill on the East Coast) is responsible for
collecting outgoing mail from their siblings and distributing incoming mail to them. 19Ann
and Bill (transport-layer protocol) provide a delivery service between the cousins
(processes). 20202020​

Just as Ann and Bill's work is confined to their homes, transport-layer protocols live only in the
end systems. 21212121The services a transport protocol can offer are constrained by the
underlying network layer's services. 22For instance, if the network layer cannot guarantee a
maximum delay, neither can the transport layer. 23However, a transport protocol can offer
services that the network layer doesn't, such as providing

reliable data transfer over an unreliable network layer. 24

3.1.2 Overview of the Transport Layer in the Internet

The Internet provides two primary transport protocols:

1.​ UDP (User Datagram Protocol): Provides an unreliable, connectionless service. 25​

2.​ TCP (Transmission Control Protocol): Provides a reliable, connection-oriented service.

26
​

The Internet's network-layer protocol,

IP (Internet Protocol), provides a best-effort delivery service, meaning it makes no

guarantees about segment delivery, order of delivery, or data integrity. 27Because it makes no
guarantees, IP is an

unreliable service. 28

Both UDP and TCP extend IP's host-to-host delivery to

process-to-process delivery through a function called transport-layer multiplexing and

demultiplexing. 29They also provide integrity checking using error-detection fields. 30

●​ UDP offers only these two minimal services: process-to-process delivery and error
checking. It is an unreliable service, just like IP. 31​

●​ TCP offers additional services, most importantly:

○​ Reliable Data Transfer: Using mechanisms like acknowledgments, sequence
numbers, and timers, TCP ensures data is delivered correctly and in order, converting
IP's unreliable service into a reliable one for processes. 32​
 ○​ Congestion Control: TCP prevents any single connection from overwhelming the
network with excessive traffic by regulating the sender's transmission rate. This
benefits the entire Internet. 33333333​

<hr>

3.2 Multiplexing and Demultiplexing

This section details how the transport layer extends host-to-host delivery to
process-to-process delivery.

At the receiving host, the transport layer needs to deliver incoming data to the correct
application process. 34343434It does this by directing the data to an intermediary

socket, which acts as a door to the process. 35Each socket has a unique identifier. 36

●​ Demultiplexing: The job of examining header fields in a received segment to identify the
receiving socket and delivering the segment to it. 37​

●​ Multiplexing: The job at the source host of gathering data from different sockets,
creating segments by adding headers (with source and destination port numbers), and
passing them to the network layer. 38​

To achieve this, each transport-layer segment contains a

source port number field and a destination port number field. 39

●​ Port numbers are 16-bit numbers ranging from 0 to 65535. 40​

●​ Numbers from 0 to 1023 are​

well-known port numbers, reserved for standard protocols like HTTP (port 80) and FTP
(port 21). 41​
Connectionless Multiplexing and Demultiplexing (UDP)

●​ A​
UDP socket is fully identified by a two-tuple: a (destination IP address, destination
port number). 42​

●​ When a host receives a UDP segment, it examines the destination port number in the
segment and directs it to the socket with that port number. 43​

●​ If multiple UDP segments arrive with different source IPs or source ports but the​
same destination IP and port, they will all be directed to the same destination socket. 44​

●​ The source port number serves as a "return address." When the receiver wants to send
a reply, it uses the source port number from the incoming segment as the destination
port number for the outgoing segment. 45​

Connection-Oriented Multiplexing and Demultiplexing (TCP)

TCP demultiplexing is more specific.

●​ A​
TCP socket is identified by a four-tuple: (source IP address, source port number,
destination IP address, destination port number). 46​

●​ When a TCP segment arrives, the host uses all four values to direct the segment to the
correct socket. 47This means two arriving TCP segments with different source IP
addresses or source port numbers will be directed to two different sockets. 48​

●​ A TCP server has a "welcoming socket" that listens on a well-known port (e.g., port 80 for
a web server). 49When a client sends a connection request (a SYN segment), the server
creates a​
​
new socket dedicated to that specific client connection. 50This new socket is identified
by the four-tuple containing the client's IP/port and the server's IP/port. 51​

●​ This allows a single server process to handle many simultaneous connections, as each
connection is uniquely identified by the full four-tuple. 52High-performing web servers
 often use a single process but create a new​
​
thread with a new connection socket for each client connection. 53​

<hr>

3.3 Connectionless Transport: UDP

UDP (User Datagram Protocol), defined in [RFC 768], is a minimal transport protocol.
54
Beyond multiplexing/demultiplexing and some light error checking, it adds almost nothing to
the underlying IP service. 55It is

connectionless, meaning there is no handshaking between sending and receiving entities

before data is sent. 56

Many applications are better suited for UDP than TCP for several reasons: 57

●​ Finer Control Over Sending: UDP sends a segment as soon as the application passes it
data, unlike TCP, which has congestion control that can throttle the sender. 58Real-time
applications that need a minimum sending rate and can tolerate some loss often prefer
UDP. 59​

●​ No Connection Establishment: TCP requires a three-way handshake, which adds delay.

60
UDP sends data without this delay, which is why DNS runs over UDP. 61​

●​ No Connection State: TCP maintains connection state (buffers, sequence numbers, etc.)
in the end systems. 62UDP does not, allowing a server to support many more active
clients. 63​

●​ Small Header Overhead: The UDP header is only 8 bytes, compared to TCP's 20 bytes.
64
​
While UDP itself is unreliable, an application can build reliability (e.g., acknowledgments and
retransmissions) into the application layer itself. 65

3.3.1 UDP Segment Structure

The UDP header is simple, with only four fields, each two bytes long: 66

●​ Source Port # and Destination Port #: Used for multiplexing and demultiplexing. 67​

●​ Length: Specifies the number of bytes in the UDP segment (header plus data). 68​

●​ Checksum: Used by the receiver to check if errors have been introduced into the
segment. 69​

3.3.2 UDP Checksum

The checksum provides error detection. 70

●​ Calculation: The sender takes all the 16-bit words in the segment (including some IP
header fields), sums them, and performs a 1s complement of the sum. 71Any overflow
during the sum is wrapped around. 72This result is placed in the checksum field. 73​

●​ Verification: The receiver adds all the 16-bit words, including the checksum. 74If no
errors occurred, the sum will be all 1s (1111111111111111). 75If any bit is a 0, an error has
been detected. 76​

UDP provides its own checksum because there is no guarantee that all links in the path
provide error checking, and bits can also be corrupted while a segment is stored in a router's
memory. 77777777This adheres to the

end-to-end principle, which states that some functions (like error detection) must be
implemented on an end-to-end basis. 78

<hr>

3.4 Principles of Reliable Data Transfer

This section explores how to build a protocol for reliable data transfer over an unreliable
channel, where bits can be corrupted or packets can be lost. 79797979The goal is to provide a
service abstraction of a

reliable channel to the upper layer, where no data is lost or corrupted, and all data is
delivered in the order it was sent. 80 This is done by incrementally developing a series of
protocols.

rdt1.0: Reliable Transfer over a Perfectly Reliable Channel

If the underlying channel is perfectly reliable, the protocol is trivial. 81The sender accepts data
from the upper layer, creates a packet, and sends it. 82The receiver gets the packet, extracts
the data, and passes it to the upper layer. 83

rdt2.0: Channel with Bit Errors

A more realistic model is a channel that can corrupt bits but doesn't lose packets. 84848484To
handle this,

Automatic Repeat reQuest (ARQ) protocols are used. 85 They require three new capabilities:
 1.​ Error Detection: Using a checksum to detect when bit errors have occurred. 86​

2.​ Receiver Feedback: The receiver provides explicit feedback to the sender. This can be a
positive acknowledgment (​
ACK) for a correctly received packet or a negative acknowledgment (NAK) for a
corrupted one. 87​

3.​ Retransmission: The sender retransmits a packet that was received in error. 88​

This protocol is a

stop-and-wait protocol because the sender sends a packet and then waits for an ACK or
NAK before sending the next one. 89

A fatal flaw exists if the ACK/NAK packets can also be corrupted. 90To solve this, the sender
can resend the packet if it receives a garbled ACK/NAK. 91However, this introduces

duplicate packets. 92To handle duplicates, data packets are given a

sequence number. 93A 1-bit sequence number (0 or 1) is sufficient for a stop-and-wait

protocol. 94The receiver checks the sequence number to determine if a packet is new or a
retransmission. 95

rdt3.0: Channel with Errors and Loss

Now, assume the channel can also lose packets (both data packets and ACKs). 96 The protocol
must now also handle packet loss. The sender can detect loss by setting a

countdown timer when it sends a packet. 97

●​ If an ACK is received before the timer expires, the timer is stopped.

●​ If the timer expires, the sender assumes the packet was lost and​
retransmits it. 98​
This approach can still lead to duplicate packets if a packet is merely delayed and not lost, but
the sequence numbers from

rdt2.2 can handle this. 99This protocol, which uses a 1-bit sequence number, is also known as
the

alternating-bit protocol. 100

3.4.2 Pipelined Reliable Data Transfer Protocols

Stop-and-wait protocols have a major performance problem, especially on long-delay,

high-bandwidth links. 101The sender often spends most of its time idle, waiting for an ACK.
102
The fraction of time the sender is busy, or

sender utilization, can be extremely low. 103

The solution is

pipelining, which allows the sender to transmit multiple packets without waiting for
acknowledgments. 104 This requires:

●​ An increased range of sequence numbers. 105​

●​ Buffering at both the sender (for unacknowledged packets) and receiver. 106​

There are two basic approaches to pipelined error recovery:

Go-Back-N and Selective Repeat. 107

3.4.3 Go-Back-N (GBN)

In a GBN protocol, the sender can have up to

N unacknowledged packets in the pipeline, where N is the window size. 108The range of
permissible sequence numbers for transmitted but unacknowledged packets is a window that
slides forward as ACKs are received. 109GBN is a type of

sliding-window protocol. 110

●​ Sender:
○​ If a timeout occurs, the sender retransmits​
all packets that have been sent but not yet acknowledged, starting from the oldest
one. 111​

○​ It uses​
cumulative acknowledgments, meaning an ACK for sequence number n confirms
that all packets up to and including n have been correctly received. 112​

●​ Receiver:
○​ If a packet with sequence number​
n is received correctly and in order, the receiver sends an ACK for n and delivers the
data to the upper layer. 113​

○​ In all other cases (e.g., an out-of-order packet arrives), the receiver​

discards the packet and resends an ACK for the most recently received in-order
packet. 114This simplifies receiver design, as no out-of-order packets need to be
buffered. 115​

3.4.4 Selective Repeat (SR)

GBN can be inefficient because a single packet error can cause the retransmission of many
correct packets. 116

Selective Repeat (SR) protocols avoid this by having the sender retransmit only those
packets that were lost or corrupted. 117
 ●​ Sender:
○​ Retransmits only the specific packets for which it suspects an error.
○​ Each packet has its own logical timer. 118​

●​ Receiver:
○​ Individually acknowledges each correctly received packet, whether it's in order or
not. 119119119119​

○​ Buffers out-of-order packets until the missing packets arrive. 120Once a gap is filled,
a batch of in-order packets can be delivered to the upper layer. 121​

The window size for SR must be less than or equal to half the size of the sequence number
space to avoid ambiguity between a retransmitted old packet and a new packet with the same
sequence number. 122

<hr>

3.5 Connection-Oriented Transport: TCP

TCP is the Internet's connection-oriented, reliable transport protocol, and it uses many of the
principles discussed in Section 3.4. 123

3.5.1 The TCP Connection

TCP is

connection-oriented. 124124Before data can be sent, the client and server must perform a

three-way handshake to establish a connection. 125125125125

 ●​ This is a​
logical connection; state (buffers, variables) resides only in the two end systems.
126
Intermediate routers are oblivious to TCP connections. 127127127127​

●​ The connection is​

full-duplex (data can flow in both directions simultaneously) and point-to-point
(between a single sender and a single receiver). 128​

When a TCP connection is established, each side allocates a

send buffer and a receive buffer. 129129129129The sender's TCP grabs chunks of data from its
send buffer, forms segments, and passes them to the network layer. 130The maximum amount
of application-layer data that can be placed in a segment is the

Maximum Segment Size (MSS). 131

3.5.2 TCP Segment Structure

The TCP segment consists of a header and a data field. 132The header is typically 20 bytes and
includes: 133

●​ Source and Destination Port Numbers: For multiplexing/demultiplexing. 134​

●​ Sequence Number (32-bit): The byte-stream number of the first byte in the segment's
data. 135135135135TCP views data as an ordered stream of bytes, and sequence numbers
refer to these bytes, not the segments. 136​

●​ Acknowledgment Number (32-bit): The sequence number of the next byte a host is
expecting from the other side. 137137137137TCP uses​
​
cumulative acknowledgments. 138​

●​ Header Length (4-bit): Specifies the length of the TCP header. 139​

●​ Receive Window (16-bit): Used for flow control; indicates the number of bytes a
receiver is willing to accept. 140​
 ●​ Flag Field (6-bit): Contains bits like ACK (acknowledgment field is valid), SYN (for
connection setup), and FIN (for connection teardown). 141141141141​

3.5.3 Round-Trip Time Estimation and Timeout

TCP uses a timeout/retransmit mechanism to recover from lost segments. 142The timeout
interval must be larger than the connection's Round-Trip Time (RTT). 143

●​ TCP measures the​

SampleRTT for a segment (time from when it's sent until its ACK is received). 144It only
measures one​
​
SampleRTT at a time and never for a retransmitted segment. 145145145145​

●​ It calculates a smoothed RTT estimate, EstimatedRTT, using an Exponential Weighted

Moving Average (EWMA):​
EstimatedRTT = (1-α) * EstimatedRTT + α * SampleRTT​
where the recommended value for​
α is 0.125. 146146146146​

●​ It also calculates the RTT variation,​

DevRTT, which measures how much the SampleRTT deviates from EstimatedRTT. 147​

●​ The TimeoutInterval is then set based on these two values:​

​
​
TimeoutInterval = EstimatedRTT + 4 * DevRTT 148​

3.5.4 Reliable Data Transfer

TCP creates a reliable service on top of IP's unreliable service. 149

 ●​ It uses a​
single retransmission timer for the oldest unacknowledged segment. 150​

●​ When the timer expires (​

timeout), it retransmits the segment with the smallest sequence number that has not yet
been acknowledged. 151​

●​ Doubling the Timeout Interval: Each time TCP retransmits due to a timeout, it sets the
next timeout interval to twice the previous value. 152This exponential backoff provides a
limited form of congestion control. 153​

●​ Fast Retransmit: A timeout period can be long. 154To detect packet loss faster, the
sender uses​
​
duplicate ACKs. 155When a receiver gets an out-of-order segment, it detects a gap and
immediately sends a duplicate ACK for the last in-order byte it received. 156156156156If the
sender receives​
​
three duplicate ACKs for the same data, it takes this as a sign that the subsequent
packet was lost and performs a fast retransmit of the missing segment before its timer
expires. 157​

TCP's error recovery is best categorized as a hybrid of GBN and SR protocols. 158It uses
cumulative ACKs like GBN, but many implementations buffer out-of-order segments like SR,
and its fast retransmit mechanism avoids the unnecessary retransmissions common in GBN.
159159159159

3.5.5 Flow Control

TCP provides a

flow-control service to prevent the sender from overflowing the receiver's buffer. 160This is a
speed-matching service. 161

●​ The sender maintains a variable called the​

receive window (rwnd). 162​
●​ The receiver communicates how much free buffer space it has by placing the current
value of​
rwnd in the receive window field of every segment it sends back to the sender. 163​
​
​
rwnd = RcvBuffer - (LastByteRcvd - LastByteRead)​
where​
RcvBuffer is the total size of the receive buffer. 164​

●​ The sender ensures that the amount of unacknowledged data it sends is less than the
value of rwnd:​
​
​
(LastByteSent - LastByteAcked) ≤ rwnd 165​

3.5.6 TCP Connection Management

●​ Establishing a Connection (Three-Way Handshake):

1.​ The client sends a​
SYN segment to the server with a randomly chosen initial sequence number
(client_isn). 166​

2.​ The server, upon receiving the SYN, allocates buffers and variables, and sends back a​
SYNACK segment. 167This segment has the SYN bit set, acknowledges the client's
SYN (​
​
ack = client_isn + 1), and contains the server's own random initial sequence number
(server_isn). 168​

3.​ The client receives the SYNACK, allocates its own buffers and variables, and sends a
final​
ACK segment to the server, acknowledging the server's SYN (ack = server_isn + 1).
169
This third segment can carry application data. 170​

●​ Closing a Connection:
○​ Either side can initiate the teardown by sending a segment with the​
FIN bit set to 1. 171171171​
 ○​ The other side sends an ACK for the FIN segment. 172​

○​ It then sends its own FIN segment, which is in turn acknowledged by the initiating
side. 173Resources are then deallocated. 174​

This process involves transitions through various

TCP states, such as CLOSED, SYN_SENT, ESTABLISHED, FIN_WAIT, and TIME_WAIT. 175

<hr>

3.6 Principles of Congestion Control

Network congestion occurs when too many sources try to send data at too high a rate,
leading to overflowing router buffers and packet loss. 176

Congestion control refers to mechanisms that throttle senders to prevent this. 177

3.6.1 The Causes and the Costs of Congestion

Three scenarios illustrate the costs of congestion:

1.​ Two Senders, Infinite Buffers: As the combined sending rate approaches the link
capacity R, the average queuing delay at the router grows infinitely large. 178178178178 Cost:​
​
Large queuing delays.
2.​ Two Senders, Finite Buffers: With finite buffers, packets are dropped when the buffer
overflows. 179A reliable protocol will retransmit these packets. 180Cost 1:​
​
Sender must perform retransmissions to compensate for loss. 181Cost 2:​
 ​
Unneeded retransmissions can occur if a sender times out prematurely for a delayed
(but not lost) packet, wasting link capacity by forwarding duplicate packets. 182​

3.​ Four Senders, Multihop Paths: When a packet is dropped at a downstream router, the
transmission capacity used at all upstream links to get the packet to that point is wasted.
183
In severe cases, as offered load increases, the effective throughput can drop to zero as
nearly all router resources are spent forwarding packets that are ultimately dropped. 184​

3.6.2 Approaches to Congestion Control

1.​ End-to-end Congestion Control: The network layer provides no explicit support. 185End
systems must infer congestion from network behavior like packet loss and delay. 186​
​
TCP uses this approach, treating packet loss (detected via timeout or triple duplicate
ACKs) as a signal of congestion and reducing its sending rate. 187​

2.​ Network-assisted Congestion Control: Routers provide explicit feedback to the sender
about the congestion state. 188This feedback can be a​
​
choke packet sent directly to the sender or a bit marked in a packet flowing from sender
to receiver. 189​

<hr>

3.7 TCP Congestion Control

TCP uses an end-to-end, network-unassisted approach. 190It has each sender limit its send
rate based on perceived network congestion. 191

●​ A TCP sender maintains an additional variable, the​

congestion window (cwnd). 192The amount of unacknowledged data a sender can have
is limited by​
 ​
min{cwnd, rwnd}. 193By adjusting​
​
cwnd, the sender controls its sending rate, which is roughly cwnd/RTT bytes/sec. 194​

●​ The sender perceives congestion when a​

"loss event" occurs (either a timeout or the receipt of three duplicate ACKs). 195​

●​ The guiding principles of the algorithm are:

1.​ A lost segment implies congestion, so the send rate should be​
decreased. 196​

2.​ An acknowledged segment indicates the network is working, so the send rate can be​
increased. 197​

3.​ This creates a​

bandwidth probing dynamic: increase rate until loss occurs, then back off, then
probe again. 198​

The TCP congestion-control algorithm has three main components:

Slow Start, Congestion Avoidance, and Fast Recovery. 199

Slow Start

●​ When a connection begins,​

cwnd is initialized to 1 MSS. 200​

●​ The value of​

cwnd is increased by 1 MSS for every acknowledged segment. 201This results in the
sending rate doubling every RTT (exponential growth). 202​

●​ Slow start ends when:

○​ A timeout loss event occurs.​
cwnd is reset to 1, and a variable ssthresh (slow start threshold) is set to cwnd/2. 203​

○​ cwnd reaches the value of ssthresh. The sender then transitions to the more
 conservative congestion avoidance mode. 204​

○​ Three duplicate ACKs are detected. TCP then performs a fast retransmit and enters
the fast recovery state. 205​

Congestion Avoidance

●​ Instead of doubling​
cwnd every RTT, TCP increases cwnd by just 1 MSS per RTT. 206This is a linear increase,
which is much more conservative than slow start's exponential growth. 207​

●​ If a timeout occurs,​
cwnd is reset to 1 MSS and ssthresh is set to cwnd/2, and the sender returns to the slow
start phase. 208​

●​ If a triple-duplicate-ACK loss occurs,​

cwnd is halved, ssthresh is set to this new halved value, and the sender enters fast
recovery. 209​

Fast Recovery

●​ This state is entered after a triple-duplicate-ACK event.

●​ The value of​
cwnd is increased by 1 MSS for every duplicate ACK received for the missing segment. 210​

●​ When the ACK for the missing segment finally arrives, TCP deflates​
cwnd and enters the congestion avoidance state. 211​

An older version of TCP,

TCP Tahoe, always reset cwnd to 1 after any loss event. 212A newer version,

TCP Reno, incorporated fast recovery to avoid the drastic rate reduction after a
triple-duplicate-ACK event. 213

TCP's overall behavior is often described as

Additive-Increase, Multiplicative-Decrease (AIMD). 214It linearly increases its window size (

+1 MSS per RTT) and then halves it on a loss event, resulting in a characteristic "sawtooth"
pattern of throughput over time. 215

Fairness

A congestion-control mechanism is considered

fair if K competing TCP connections each get approximately R/K of a bottleneck link's
capacity R. 216

●​ TCP's AIMD algorithm tends to converge to a fair allocation. 217Connections that are
consuming less than their fair share will increase their rate, while those consuming more
will eventually experience loss and decrease their rate, pushing the system toward the
equal-share point. 218218218218​

●​ However, applications using​

UDP do not have built-in congestion control and can be unfair, potentially crowding out
TCP traffic. 219219219219​

●​ Similarly, an application can be unfair by using​

multiple parallel TCP connections (e.g., a web browser), as it will grab a larger share of
the bottleneck bandwidth than an application using only one connection. 220​