ID
3
ย
Chapter 3: Transport Layer
๐น 1. Transport Layer Overview: Core Goals
โ What Does the Transport Layer Do?
- Provides logical communication between application processes on different hosts.
- Builds on network layer (IP) โ adds port-number-based demultiplexing and reliability/service controls.
- Two protocols:
- TCP: Connection-oriented, reliable, flow/congestion controlled
- UDP: Connectionless, unreliable, lightweight
โ Analogy:
- IP = Postal Service โ delivers letter (datagram) from house to house
- TCP/UDP = Ann & Bill โ deliver letter to specific kid in the house (via port)
๐น 2. Multiplexing & Demultiplexing (CRITICAL!)
โ Defining Terms
Term | Meaning |
Multiplexing | Sender combines data from multiple processes into one transport stream. Adds headers. |
Demultiplexing | Receiver delivers incoming segment to the correct process using header info. |
โ How Demultiplexing Works
โค UDP: 1-Tuple Demultiplexing
- Uses only destination port number
- All segments to same
(host:port)go to same socket
- Multiple clients โ same server port = one server socket
Example:
Client A (IP: 1.1.1.1, port 5000) โ Server (10.10.10.10:53)Client B (IP: 1.1.1.2, port 5001) โ Server (10.10.10.10:53)
โ
Both go to same DNS server socket!โ UDP is connectionless โ no connection state โ simple demux
โค TCP: 4-Tuple Demultiplexing
Uses four values to identify a unique connection:
Allows multiple concurrent TCP connections to same server port.
Example:
Three browsers open TCP to
gaia.cs.umass.edu:80 โ three different sockets on server!Connection 1 | 192.168.1.2 : 5000 โ 128.119.245.12 : 80 |
Connection 2 | 192.168.1.5 : 5001 โ 128.119.245.12 : 80 |
Connection 3 | 192.168.1.2 : 5002 โ 128.119.245.12 : 80 |
โ
Server has three separate sockets (one per connection).
๐ง Exam Tip:
- UDP demux = destination port only
- TCP demux = 4-tuple โ allows multiple persistent connections
๐น 3. UDP: User Datagram Protocol
โ UDP Features Table
Feature | UDP |
Reliability | โ No retransmissions, no ACKs |
Order | โ Packets may arrive out-of-order |
Connection | โ No handshaking |
Congestion Control | โ No flow or rate control โ can flood network |
Header Size | 8 bytes (tiny!) |
Checksum | โ
Optional (but usually used) |
Use Cases | DNS, VoIP, live video, online games, DHCP, SNMP, HTTP/3 |
โ Why Use UDP?
- Low overhead โ no connection setup delay (0-RTT)
- No head-of-line blocking
- Ideal for delay-sensitive apps (e.g., Zoom, Twitch)
- Apps add their own reliability if needed โ e.g., QUIC (HTTP/3)
โ UDP Header (8 bytes)
โ Checksum includes:
- UDP header + payload
- 96-bit pseudo-header: Source IP, Dest IP, Protocol (17), UDP Length โ End-to-end integrity โ not just link-level
โ Internet Checksum: 1's Complement Sum
- Treats data as 16-bit integers โ sum โ take 1โs complement
- Receiver recomputes โ must equal 0 if no error
- Weak protection: Can detect single-bit and some multi-bit errors โ Fails on two flipped bits that cancel out โ not cryptographically secure
๐ก Example:0000 1111 + 1111 0000 = 1 0000 0000 โ wraparound โ 0000 0000 โ checksum = 1111 1111
๐น 4. Reliable Data Transfer: Principles (The Foundation)
We design rdt protocols to provide reliable transport over unreliable channel (loss, corruption, reordering).
โ Four Core Abstractions
Function | Description |
rdt_send(data) | App calls this to send data |
udt_send(packet) | Transport sends packet over unreliable channel |
rdt_rcv(packet) | Transport receives packet from channel |
deliver_data(data) | Transport delivers data to app |
โ We model sender and receiver as Finite State Machines (FSMs).
โ Progression of rdt Protocols
Protocol | Channel Assumption | Key Innovation |
rdt1.0 | Perfect channel | Just send and receive |
rdt2.0 | Bit errors (corruption) | ACKs and NAKs |
rdt2.1 | Bit errors + garbled ACK/NAK | Sequence numbers (0,1) |
rdt2.2 | Bit errors | NAK-free โ ACKs with seq# |
rdt3.0 | Bit errors + packet loss | Timers + timeout |
โ Stop-and-Wait: One packet sent โ wait for ACK โ then next โ Terrible efficiency
โ rdt3.0 Performance: STOP-AND-WAIT IS SLOW!
๐ก Pipelining โ allows multiple in-flight packets โ fixes this!
๐น 5. Pipelined Protocols: Go-Back-N & Selective Repeat
โ Basic Idea: Pipelining
- Send N packets before waiting for ACK โ improves utilization
- Use sequence numbers to track packets
- Window size = N โ max unACKed packets allowed
โ Go-Back-N (GBN) โ Simpler, Less Efficient
Feature | GBN |
ACK Type | Cumulative ACK โ ACK(n) means 0โn received |
Receiver | Discards out-of-order packets โ only buffers in-order |
Sender | On timeout โ retransmit all packets from the lost one onward |
Window Size | Max N = 2^k โ 1 (for k-bit sequence numbers) |
Why? Simpler receiver logic โ no buffer needed
Drawback: Wastes bandwidth if only one packet lost
โ Example: Window size=4. Packet 2 lost โ sender retransmits 2,3,4,5 (even if 3,4,5 arrived OK)
โ Selective Repeat (SR) โ Efficient, Complex
Feature | SR |
ACK Type | Individual ACKs for each correctly received packet |
Receiver | Buffers out-of-order packets, delivers only in-order |
Sender | Retransmits only timeout packet, not whole window |
Window Size | Max N = 2^{k-1} โ must be โค half sequence number space |
๐ก Critical Rule: Window size โค half sequence number space โ to avoid โduplicate ACKโ ambiguity โ Example: 2-bit seq nums (0,1,2,3), window=3 โ ambiguity if 0 lost & retransmitted
โ Use Case: High-bandwidth, high-delay networks (e.g., satellite)
โ Comparison: GBN vs SR
Scenario | Go-Back-N | Selective Repeat |
Packet 3 lost | Retransmit 3,4,5,6 | Retransmit 3 only |
ACK 4 lost | Retransmit 4,5,6 | Retransmit 4 only |
Receives out-of-order | Discards | Buffers |
Receiver Buffer | Small | Large |
Complexity | Low | High |
Efficiency | Low | High |
โ TCP uses GBN-style (cumulative ACK) + fast retransmit to simulate SR
๐น 6. TCP: Connection-Oriented Reliability
โ TCP Features (Must Memorize!)
- โ Connection-oriented โ 3-way handshake
- โ Reliable, in-order byte stream โ no message boundaries
- โ
Flow control: via
rwndfield
- โ Congestion control: congestion avoidance, slow start
- โ Full-duplex: both sides send/receive simultaneously
- โ ACKs: Cumulative, delayed, duplicate
- โ Retransmissions: timeout + fast retransmit (3 dup ACKs)
โ TCP Segment Header (20+ bytes)
Field | Purpose | Size |
Source Port | Sender port | 16 bits |
Destination Port | Receiver port | 16 bits |
Sequence Number | Byte # of first byte of data | 32 bits |
Acknowledgement Number | Next byte expected | 32 bits |
Header Len | TCP header size (in 32-bit words) | 4 bits |
Flags: URG, ACK, PSH, RST, SYN, FIN | Connection control | 6 bits |
Receive Window (rwnd) | How many bytes receiver can accept | 16 bits |
Checksum | Covers pseudo-header + header + data | 16 bits |
Urgent Pointer | Used with URG flag (rare) | 16 bits |
Options | e.g., MSS, Window Scaling | variable |
๐ Key Insight: Sequence numbers = bytes (not packets)! This enables reassembly in order โ stream abstraction
โ TCP Sequence & ACK Numbers
Case | Example |
A sends: โCโ (seq=42, 1 byte) โ B gets it | B ACKs: ACK=43 (next expected byte) |
B replies: โCโ (seq=79, 1 byte) โ A gets it | A ACKs: ACK=80 |
โ ACK=80 means: โI received up to byte 79. Next I expect byte 80.โ
โ TCP Round-Trip Time (RTT) Estimation
Used to set timeout values
Formula | Description |
EstimatedRTT = (1-ฮฑ) * EstimatedRTT + ฮฑ * SampleRTT | Exponential Weighted Moving Avg (EWMA) โ ฮฑ = 0.125 |
`DevRTT = (1-ฮฒ) * DevRTT + ฮฒ * | SampleRTT โ EstimatedRTT |
TimeoutInterval = EstimatedRTT + 4 * DevRTT | Safety margin = 4ร stddev |
โ More variation โ higher timeout โ avoids premature retransmits
๐น 7. TCP Reliable Data Transfer: Fast Retransmit & Delayed ACK
โ TCP ACK Generation Rules [RFC 5681]
Event | Action |
In-order segment received โ no pending ACK | Delayed ACK: wait โค500ms for next segment |
In-order segment received โ pending ACK | Send single cumulative ACK |
Out-of-order segment | Send duplicate ACK (ACK of last in-order byte) |
Segment fills gap | Send ็ซๅณ ACK |
โ Fast Retransmit (Crucial!)
- Sender receives 3 duplicate ACKs โ assume loss โ retransmit immediately
- Avoids timeout โ improves performance
- Works because 3 dup ACKs = 3 packets received after a gap โ probable lost segment in between
โ TCP Reno uses 3 dup ACKs โ fast retransmit โ TCP Tahoe waits for timeout โ slower
๐น 8. TCP Flow Control
โ Purpose
Prevent sender from overwhelming receiverโs buffer
โ How It Works
- Receiver advertises available buffer space in
rwndfield of TCP header
- Sender only sends up to
min(cwnd, rwnd)bytes
rwnd=RcvBuffer โ (LastByteReceived โ LastByteRead)
๐ก Example: Receiver buffer = 4KB Bytes received = 5000 Bytes read by app = 3000 โrwnd = 4096 โ (5000 - 3000) = 4096 โ 2000 = 2096โ Sender can only send 2096 bytes more.
โ rwnd can shrink โ receiver tells sender โslow downโ
๐ Always observe: TCP is receiver-driven โ Pearl of orchestration
๐น 9. TCP Connection Management: 3-Way Handshake
โ Steps
Step | Message | Meaning |
1 | SYN (seq=x) | Client โ server: โI want to connect, my seq=xโ |
2 | SYN-ACK (seq=y, ack=x+1) | Server โ client: โI accept, my seq=y, I expect your next byte=x+1โ |
3 | ACK (ack=y+1) | Client โ server: โGot it, I expect your next byte=y+1โ |
๐ States:
- Client:
CLOSED โ SYN_SENT โ ESTABLISHED
- Server:
LISTEN โ SYN_RCVD โ ESTABLISHED
โ Why 3-Way? (Not 2-Way!)
- To prevent half-open connections
- Example: Stale SYN gets retransmitted โ server accepts โ client gone โ dangling connection
โ Human analogy:
- โOn belay?โ
- โBelay on.โ
- โClimbing.โ โ mutual confirmation
โ Connection Termination: 4-Way FIN Handshake
Step | Message | Meaning |
1 | FIN (seq=x) | Client: โIโm done sendingโ โ FIN_WAIT_1 |
2 | ACK (ack=x+1) | Server: โGot your FINโ โ CLOSE_WAIT |
3 | FIN (seq=y) | Server: โIโm done tooโ โ LAST_ACK |
4 | ACK (ack=y+1) | Client: โGot itโ โ TIME_WAIT โ CLOSED |
๐ก TIME_WAIT: Client waits 2ร MSL (max segment lifetime) to ensure last ACK arrives โ prevents old packets from reappearing
๐น 10. TCP Congestion Control
โ Congestion vs Flow Control
Flow Control | Congestion Control |
Prevent sender from overwhelming ONE receiver | Prevent sender from overwhelming NETWORK |
Managed by receiver via rwnd | Managed by sender via cwnd |
Always active | Activated when network gets busy |
โ Congestion Signs
- Packet loss (buffer overflow)
- Increase in RTT (queueing delay)
โ TCP treats any loss as congestion โ even wireless or noise-induced โ suboptimal
โ TCP Congestion Control Phases
Stage | Behavior | Algorithm |
Slow Start | aggresively increase | cwnd doubles every RTT โ exponential |
Congestion Avoidance | linear increase | cwnd += 1 MSS per RTT |
Fast Retransmit | react to 3 dup ACKs | cwnd = cwnd/2, ssthresh = cwnd/2, enter recovery |
Fast Recovery | after fast retransmit | cwnd = ssthresh + 3 โ additive increase |
Timeout | slow start restart | cwnd = 1 MSS, ssthresh = cwnd/2 |
โ Algorithm State Diagram (Must Know!)
๐ ssthresh = โslow start thresholdโ โ set tocwnd/2on loss
โ Actions:
- On 3 dup ACKs:
ssthresh = cwnd/2,cwnd = ssthresh + 3, enter fast recovery
- On timeout:
ssthresh = cwnd/2,cwnd = 1, restart slow start
โ TCP Throughput Formula
Average throughput โ 1.22 ร MSS / (RTT ร โL) โ Mathis Formula โ
Scenario | L (loss rate) | Throughput |
1 Gbps, 100ms RTT | 10โปยนโฐ | ~10 Gbps! โ
|
100 Mbps, 20ms RTT | 10โปโด | ~200 Mbps |
๐ก High-speed long pipes need extremely low loss โ TCP Reno struggles
๐น 11. Advanced TCP: CUBIC & BBR
โ TCP CUBIC (Linux default until ~2024)
- Uses cubic function to scale cwnd โ faster recovery after loss
- Smooth, predictable window growth
- Avoids aggressive ramp-down โ better network utilization
Key Idea:
- After packet loss โ cwnd = W_max / 2
- Modern delay โ W_max hasnโt changed much
- So, ramp back to W_max faster, then slow down
โ Result: Better for high-BDP (bandwidth-delay product) networks
โ BBR (Bottleneck Bandwidth and Round-Trip time)
- Sending rate based on measured bandwidth + min RTT โ no loss!
- Doesnโt wait for loss โ probes to find max capacity
- Sends just enough to fill pipe โ avoid queuing
Phases:
- Startup: Increase rate fast until throughput plateaus
- Drain/BTL: Reduce rate โ drain queue โ find true min RTT
- Probe BW: Adjust rate up/down based on recent throughput
โ Used by Google, YouTube, Cloudflare โ higher throughput, lower latency โ Newer standard โ replacing CUBIC in many modern systems
๐น 12. QUIC & HTTP/3: Transport Layer in Application Layer
Aspect | TCP | QUIC (Over UDP) |
Transport Protocol | TCP | UDP |
Encryption | TLS (separate handshake) | QUIC built-in โ TLS 1.3 |
Handshake | 3-way + TLS handshake (2 RTTs) | 1-RTT or 0-RTT |
Multiplexing | Single stream per connection โ HOL blocking | Multiple independent streams โ No HOL blocking |
Congestion Control | TCP Reno/CUBIC | QUICโs own (TCP-like) |
Connection Migration | Hard (depends on IP:port) | โ
Easy โ based on connection ID |
โ QUIC = UDP + TLS + TCP-like reliability + multiplexing
๐น 13. Evolution & Trends in Transport Layer
Challenge | Traditional TCP | Modern Solutions |
High-speed, long pipes (fat pipes) | Slow recovery after loss | TCP CUBIC / BBR |
Wireless loss | Treats bit errors as congestion | TCP Westwood, TCP for WiFi |
Long RTT (satellite) | Slow start takes too long | TCP Window Scaling, SACK, BBR |
Data centers | High sensitivity to latency | BBR, DCTCP |
Background flows | All flows treat equally | Fair queuing, ECN |
Security | TLS + TCP separate | QUIC (crypto built-in) |
โ Trend: Move transport logic to application layer โ take control from infrastructure
๐จ Chapter 3: Exam Checklist (Must Know!)
Topic | Must Know? |
Multiplexing vs Demultiplexing (UDP vs TCP) | โ๏ธโ๏ธโ๏ธ |
UDP header, checksum, use cases | โ๏ธโ๏ธ |
rdt1.0 to rdt3.0 progression | โ๏ธโ๏ธ |
Stop-and-Wait utilization formula | โ๏ธโ๏ธ |
GBN vs SR โ window size, ACK types, retransmission | โ๏ธโ๏ธโ๏ธ |
TCP segment structure โ seq #, ack #, rwnd, flags | โ๏ธโ๏ธโ๏ธ |
3-way handshake steps & states | โ๏ธโ๏ธโ๏ธ |
4-way FIN handshake | โ๏ธโ๏ธ |
Delayed ACKs, Fast Retransmit (3 dup ACKs) | โ๏ธโ๏ธโ๏ธ |
TCP flow control โ rwnd | โ๏ธโ๏ธ |
Congestion control phases โ Slow Start, CA, Fast Recovery, Timeout | โ๏ธโ๏ธโ๏ธ |
ssthresh, cwnd behavior on events | โ๏ธโ๏ธ |
Mathis formula โ high-speed TCP | โ๏ธ (Can be asked to calculate) |
CUBIC vs BBR โ intuition | โ๏ธ |
QUIC โ built-in encryption, 0-RTT, no HOL blocking | โ๏ธโ๏ธ |
TCP over wireless โ limitation | โ๏ธ |
๐ง Key Takeaways (Quote These in Exams!)
โข โTransport layer enables process-to-process communication โ IP only does host-to-host.โ โข โTCP is reliable, ordered, flow- and congestion-controlled โ UDP is โfire and forget.โโ โข โSequence numbers count bytes, not packets โ making TCP a byte stream!โ โข โ3 duplicate ACKs mean a packet is lost โ donโt wait for timeout!โ โข โCongestion control is not about bandwidth โ itโs about queueing delay and loss. โ โข โCUBIC is for high-speed networks, BBR is for low-latency, and QUIC is the future.โ โข โThe Internet is moving transport functions to the application layer โ TCP is no longer the only option.โ
๐ Practice Suggestions for Exam Prep
- โ Simulate TCP handshake with 3 states on paper
- โ Practice drawing GBN/SR timelines with lost packets
- โ Calculate stop-and-wait utilization given L, R, RTT
- โ Trace TCP fast retransmit with 3 dup ACKs
- โ Write down TCP header fields (seq, ACK, rwnd, flags, checksum)
- โ Use Wireshark to capture TCP 3-way handshake โ identify SYN, ACK, flags
- โ Review cwnd growth on diagram: slow start โ CA โ loss โ recovery โ CA
โ You now command the Transport Layer: from UDP sockets to BBR congestion. Youโre ready for Chapter 4 (Network Layer: Data Plane) โ the core of the Internet!
Good luck, future network engineer! ๐๐พ๐ง






