03 Transport Layer
Table of Contents
Overview
The transport layer provides end-to-end communication services between applications running on different hosts. It serves as the bridge between the application layer and the network layer.
Key Responsibilities
Logical Communication
Provides communication between processes (not just hosts)
Multiplexing/Demultiplexing
Multiple applications share network
Segmentation
Break application messages into segments
Reassembly
Reconstruct segments into messages
Error Detection
Detect transmission errors
Reliability
Ensure accurate delivery (TCP)
Flow Control
Prevent sender from overwhelming receiver
Congestion Control
Prevent network congestion
Transport vs Network Layer
Scope
Host-to-host
Process-to-process
Services
Best-effort delivery
Reliability, flow/congestion control
Addressing
IP addresses
Port numbers
Protocols
IP, ICMP, routing
TCP, UDP
Transport Layer Protocols
TCP (Transmission Control Protocol):
Connection-oriented
Reliable, ordered delivery
Flow control, congestion control
Higher overhead
Use cases: Web, email, file transfer
UDP (User Datagram Protocol):
Connectionless
Unreliable, unordered delivery
No flow/congestion control
Minimal overhead
Use cases: DNS, streaming, gaming
Multiplexing and Demultiplexing
Multiplexing at sender: Gather data from multiple sockets, add transport header, pass to network layer
Demultiplexing at receiver: Use header info to deliver segments to correct socket
Application Layer:
[App 1] [App 2] [App 3]
↓ ↓ ↓
Transport Layer (Multiplexing):
[Port 80][Port 443][Port 8080]
↓
[TCP/UDP Segment]
↓
Network Layer:
[IP Packet]Port Numbers
16-bit unsigned integer: 0-65535
Well-Known Ports: 0-1023 (HTTP=80, HTTPS=443, SMTP=25, DNS=53)
Registered Ports: 1024-49151 (Application-specific)
Dynamic/Private Ports: 49152-65535 (Temporary, ephemeral)
Socket Identification
UDP Socket: Identified by 2-tuple (destination IP, destination port)
Host A (10.0.0.1) Host B (10.0.0.2)
App on port 5000 App on port 9000
↓ ↑
UDP segment UDP segment
Src: 10.0.0.1:5000 Dst: 10.0.0.2:9000
Dst: 10.0.0.2:9000 ─────────→ Src: 10.0.0.1:5000TCP Socket: Identified by 4-tuple (source IP, source port, destination IP, destination port)
Allows multiple connections from same client IP to same server.
UDP
User Datagram Protocol provides minimal, connectionless transport service.
UDP Characteristics
Connectionless
No handshake, no connection state
Unreliable
No delivery guarantees, no retransmission
Unordered
Segments may arrive out of order
Lightweight
Minimal header overhead (8 bytes)
Fast
No connection setup delay
Multicast/Broadcast
Supports one-to-many communication
UDP Segment Structure
0 16 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Data (Payload) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Header Fields:
Source Port (16 bits): Sending application port
Destination Port (16 bits): Receiving application port
Length (16 bits): Length of UDP segment (header + data) in bytes
Minimum: 8 bytes (header only)
Maximum: 65,535 bytes
Checksum (16 bits): Error detection (optional but recommended)
UDP Checksum
Detects errors in transmitted segment (bit flips).
Calculation:
Treat segment contents as sequence of 16-bit integers
Compute sum (with wraparound carry)
Compute 1's complement of sum
Result is checksum
Verification:
Add all 16-bit words including checksum
If result is all 1's → no errors detected
If result has 0's → error detected
Limitation: May not detect all errors (e.g., two bit flips that cancel out)
Why Use UDP?
Advantages:
No connection establishment: Reduced latency (no RTT delay)
No connection state: Server can support more clients
Small header: 8 bytes vs TCP's 20+ bytes
Fine-grained control: Application controls when data is sent
Use Cases:
DNS
Simple request-response, retries handled by application
SNMP
Network management queries
RTP (streaming)
Loss tolerant, rate sensitive
Online gaming
Low latency critical, some loss acceptable
VoIP
Real-time, loss tolerant
Reliable Data Transfer Principles
Building reliable communication over unreliable channel.
RDT 1.0: Reliable Transfer over Reliable Channel
Assumptions:
Underlying channel is perfectly reliable
No bit errors, no packet loss
Sender: Receiver:
rdt_send(data) rdt_rcv(packet)
↓ ↓
make_pkt(data) extract(packet, data)
↓ ↓
udt_send(packet) deliver_data(data)Analysis: Trivial case, no error handling needed.
RDT 2.0: Channel with Bit Errors
Assumptions:
Bits in packet may be corrupted
No packet loss
Mechanisms:
Error detection: Checksum
Feedback: Acknowledgments (ACKs/NAKs)
ACK: Receiver tells sender packet OK
NAK: Receiver tells sender packet had errors
Retransmission: Sender retransmits on receiving NAK
Sender: Receiver:
send pkt ─────────────────────────→ receive pkt
↓ ↓
wait for ACK/NAK check checksum
↑ ↓
←─ ACK (if OK) or NAK (if error) ────────┘
↓
if NAK: retransmit
if ACK: send next packetProblem: What if ACK/NAK corrupted?
RDT 2.1: Handling Corrupted ACKs
Solution: Add sequence numbers to packets
Sender adds sequence number to each packet
Receiver discards duplicate packets
For Stop-and-Wait: 1-bit sequence number suffices (0, 1, 0, 1, ...)
Sender State 0: Receiver State 0:
send pkt 0 expect seq 0
wait for ACK if pkt 0 OK:
if NAK or corrupt ACK: send ACK
resend pkt 0 goto State 1
if ACK: if pkt 0 error or pkt 1:
goto State 1 send NAK
stay in State 0RDT 2.2: NAK-Free Protocol
Improvement: Replace NAKs with duplicate ACKs
Receiver sends ACK for last correctly received packet
Duplicate ACK indicates problem with next packet
Receiver:
if pkt n OK and in-order:
send ACK(n)
deliver data
if pkt n corrupted or out-of-order:
send ACK(n-1) [duplicate ACK]RDT 3.0: Channels with Errors and Loss
New assumption: Packets can be lost (dropped) in channel
New mechanism: Timeout - Sender waits reasonable amount of time for ACK
Sender:
send pkt
start timer
if timeout:
retransmit pkt
restart timer
if ACK received:
stop timer
send next packetPerformance (Stop-and-Wait):
Utilization = (L/R) / (RTT + L/R)
where:
L = packet size (bits)
R = transmission rate (bps)
RTT = round-trip time
Example:
L = 1 KB = 8,000 bits
R = 1 Gbps
RTT = 30 ms
Utilization = (8,000 / 10^9) / (0.03 + 8,000/10^9)
= 0.000008 / 0.030008
= 0.027% (very inefficient!)Pipelined Protocols
Solution: Allow multiple unacknowledged packets in transit
Stop-and-Wait:
Time ─→
Send pkt 0 ───→ [wait RTT] ← ACK 0
Send pkt 1 ───→ [wait RTT] ← ACK 1
Send pkt 2 ───→ [wait RTT] ← ACK 2
Pipelined:
Time ─→
Send pkt 0 ───→
Send pkt 1 ───→ ← ACK 0
Send pkt 2 ───→ ← ACK 1
Send pkt 3 ───→ ← ACK 2Benefits:
Increased utilization
Higher throughput
Better network resource utilization
Requirements:
Range of sequence numbers must increase
Sender and/or receiver must buffer packets
Two approaches: Go-Back-N, Selective Repeat
Go-Back-N (GBN)
Sender:
Window of up to N unacknowledged packets
Cumulative ACK: ACK(n) acknowledges all packets up to sequence number n
Timer for oldest unacknowledged packet
On timeout: retransmit all unacknowledged packets
Sender Window (N=4):
[0][1][2][3]|4 5 6 7 8 9 ...
└─────┬────┘
Sent, unacked
After ACK(1):
[2][3][4][5]|6 7 8 9 ...
└─────┬────┘
Sent, unackedReceiver:
Only sends cumulative ACK
Discards out-of-order packets
Simple: no buffering needed
Example (packet loss):
Sender transmits: 0, 1, 2, 3
Packet 1 lost
Receiver receives: 0, -, 2, 3
Receiver ACKs: ACK(0), [no ACK], discard 2, discard 3
Timeout on packet 1
Sender retransmits: 1, 2, 3 (Go-Back-N!)Performance:
Simple receiver
Inefficient: may retransmit many correct packets
Selective Repeat (SR)
Sender:
Window of up to N unacknowledged packets
Individual ACK: Each packet individually acknowledged
Timer for each packet
On timeout: retransmit only that packet
Receiver:
Individually acknowledges all correctly received packets
Buffers out-of-order packets
Delivers in-order data to application
Sender Window (N=4):
[0][1][2][3]|4 5 6 7 8 9 ...
Receiver Window (N=4):
[0][1][2][3]|4 5 6 7 8 9 ...
Packet 1 lost:
Sender receives: ACK(0), -, ACK(2), ACK(3)
Receiver buffers: [0][–][2][3]
Timeout on packet 1
Sender retransmits: 1 only
Receiver: [0][1][2][3] → deliver all to applicationPerformance:
More efficient: only retransmit lost packets
More complex: receiver must buffer, reorder
GBN vs Selective Repeat
ACK Type
Cumulative
Individual
Retransmit
All from lost packet
Only lost packet
Receiver Buffer
No
Yes (out-of-order)
Complexity
Simple
More complex
Efficiency
Lower (many retransmits)
Higher (minimal retransmits)
TCP Uses
Modified GBN
-
TCP
Transmission Control Protocol provides reliable, ordered, connection-oriented transport.
TCP Characteristics
Connection-Oriented
3-way handshake before data transfer
Reliable
Guarantees delivery, detects errors, retransmits
Ordered
Data delivered in sequence
Full-Duplex
Bidirectional data flow
Flow Control
Prevents overwhelming receiver
Congestion Control
Prevents overwhelming network
Point-to-Point
One sender, one receiver
TCP Segment Structure
0 16 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Data | |U|A|P|R|S|F| |
|Offset Res|R|C|S|S|Y|I| Window Size |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Data (Payload) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Key Fields:
Sequence Number (32 bits): Byte number of first data byte in segment
Acknowledgment Number (32 bits): Next byte expected from other side
Data Offset (4 bits): Header length in 32-bit words
Flags (6 bits):
URG: Urgent data
ACK: Acknowledgment valid
PSH: Push data immediately
RST: Reset connection
SYN: Synchronize sequence numbers
FIN: Finish, no more data
Window Size (16 bits): Flow control, receiver's buffer space
Checksum (16 bits): Error detection
Options: MSS, timestamps, window scaling, etc.
TCP Connection Management
Three-Way Handshake (Connection Establishment):
Client Server
│ │
├─── SYN (seq=x) ─────────────────→│
│ │ (Server allocates
│ │ resources)
│←── SYN-ACK (seq=y, ack=x+1) ─────┤
│ │
│ (Client allocates │
│ resources) │
│ │
├─── ACK (ack=y+1) ───────────────→│
│ │
│ [Connection ESTABLISHED] │
│ │
├══ Data transfer ═════════════════┤Step 1: Client sends SYN
SYN flag set
Initial sequence number (ISN) chosen
Step 2: Server responds with SYN-ACK
SYN and ACK flags set
Server's ISN chosen
Acknowledges client's SYN
Step 3: Client sends ACK
ACK flag set
May contain data
Four-Way Handshake (Connection Termination):
Client Server
│ │
├─── FIN (seq=x) ─────────────────→│
│ │
│←─── ACK (ack=x+1) ────────────────┤
│ │
│ [Half-close: Client→Server] │
│ [Server can still send data] │
│ │
│←─── FIN (seq=y) ──────────────────┤
│ │
├─── ACK (ack=y+1) ───────────────→│
│ │
│ [Connection CLOSED] │TCP Reliability
Mechanisms:
Checksums: Detect bit errors
Sequence Numbers: Detect lost/duplicate/reordered segments
Acknowledgments: Confirm receipt
Timeouts: Detect lost segments, trigger retransmission
Retransmission: Resend lost segments
Timeout Calculation:
TCP uses adaptive timeout based on RTT measurements.
EstimatedRTT = (1-α) × EstimatedRTT + α × SampleRTT
(typically α = 0.125)
DevRTT = (1-β) × DevRTT + β × |SampleRTT - EstimatedRTT|
(typically β = 0.25)
TimeoutInterval = EstimatedRTT + 4 × DevRTTFast Retransmit:
If sender receives 3 duplicate ACKs for same data, resend segment before timeout.
Send seg 1 ───→
Send seg 2 ───→ (lost)
Send seg 3 ───→
←─── ACK 1 (expecting seg 2)
Send seg 4 ───→
←─── ACK 1 (dup 1)
Send seg 5 ───→
←─── ACK 1 (dup 2)
Send seg 6 ───→
←─── ACK 1 (dup 3)
[Fast retransmit seg 2]
Retransmit 2 →
←─── ACK 6 (all received!)TCP Flow Control
Purpose: Prevent sender from overwhelming receiver's buffer
Mechanism: Receiver advertises receive window (rwnd) in TCP header
Sender's Send Window = min(cwnd, rwnd)
where:
cwnd = congestion window (congestion control)
rwnd = receive window (flow control)Receiver Buffer:
┌─────────────────────────────────────────┐
│ Application reads │ Buffered │ Free │
│ from buffer │ Data │ Space │
└─────────────────────────────────────────┘
←─ rwnd ──→Receiver calculates:
rwnd = RcvBuffer - (LastByteRcvd - LastByteRead)Sender ensures:
LastByteSent - LastByteAcked ≤ rwndTCP Congestion Control
Purpose: Prevent sender from overwhelming the network
Key Idea: Probe for available bandwidth, adapt sending rate
Congestion Window (cwnd): Number of unacknowledged bytes sender can have in-flight
Effective Window = min(cwnd, rwnd)
Sending Rate ≈ cwnd / RTTTCP Congestion Control Algorithm:
1. Slow Start:
Begin with cwnd = 1 MSS
Double cwnd every RTT (exponential growth)
Continue until:
Loss detected, OR
cwnd reaches ssthresh (slow start threshold)
RTT 0: cwnd = 1 MSS
RTT 1: cwnd = 2 MSS
RTT 2: cwnd = 4 MSS
RTT 3: cwnd = 8 MSS
...2. Congestion Avoidance:
Increase cwnd by 1 MSS per RTT (linear growth)
Continue until loss detected
cwnd = cwnd + MSS × (MSS / cwnd)3. Fast Recovery:
After fast retransmit (3 dup ACKs):
ssthresh = cwnd / 2
cwnd = ssthresh + 3 MSS
Increase cwnd by 1 MSS for each additional dup ACK
When new ACK arrives: cwnd = ssthresh (enter congestion avoidance)
Loss Detection:
Timeout: Severe congestion
ssthresh = cwnd / 2
cwnd = 1 MSS
Enter slow start
3 Duplicate ACKs: Mild congestion
ssthresh = cwnd / 2
cwnd = ssthresh + 3 MSS
Enter fast recovery
TCP Congestion Control State Machine:
┌──────────────┐
│ Slow Start │
│ (exp growth) │
└──────┬───────┘
│ cwnd ≥ ssthresh
↓
┌──────────────┐
New ACK │ Congestion │
┌─────────┤ Avoidance │
│ │ (lin growth) │
│ └──────┬───────┘
│ │
│ │ 3 dup ACKs
│ ↓
│ ┌──────────────┐
└─────────┤ Fast │
│ Recovery │
└──────────────┘
↑
│ Timeout
│
(Reset to
Slow Start)TCP Variants:
TCP Tahoe
Timeout or dup ACKs → slow start
Original, conservative
TCP Reno
Timeout → slow start 3 dup ACKs → fast recovery
Most common
TCP NewReno
Improved fast recovery
Better multiple loss handling
TCP CUBIC
Time-based growth
Better for high-speed networks
TCP BBR
Bottleneck bandwidth
Google's algorithm, probes bandwidth & RTT
Summary
The transport layer provides end-to-end communication between processes:
Multiplexing/Demultiplexing:
Use port numbers to identify processes
UDP: 2-tuple socket
TCP: 4-tuple socket
UDP:
Connectionless, unreliable, minimal overhead
8-byte header
Use when speed > reliability
Reliable Data Transfer:
RDT 1.0: Perfect channel
RDT 2.x: Bit errors → checksums, ACKs/NAKs
RDT 3.0: Loss → timeouts, retransmission
Pipelining: GBN (cumulative ACK), SR (individual ACK)
TCP:
Connection-oriented (3-way handshake, 4-way termination)
Reliable (checksums, sequence numbers, ACKs, retransmission)
Flow control (receive window, rwnd)
Congestion control (cwnd, slow start, congestion avoidance, fast recovery)
Adaptive timeout, fast retransmit
References
Course Materials:
CSEE 4119: An Introduction to Computer Networks - Columbia University
Textbooks:
Kurose, James F., and Keith W. Ross. Computer Networking: A Top-Down Approach. 8th Edition, Pearson, 2021.
RFCs:
RFC 768: User Datagram Protocol
RFC 793: Transmission Control Protocol
RFC 2001: TCP Slow Start, Congestion Avoidance, Fast Retransmit, Fast Recovery
RFC 5681: TCP Congestion Control
Last updated