Kurose & Ross, Computer Networking: A Top-Down Approach, 9th edition (2025) – Full lecture coverage
The transport layer provides logical communication between application processes running on different hosts. It breaks messages into segments, passes them to the network layer, and reassembles them at the receiver. Two main protocols: TCP and UDP.
12 kids in Ann’s house sending letters to 12 kids in Bill’s house:
| Feature | TCP | UDP |
|---|---|---|
| Connection | Connection-oriented (handshake) | Connectionless |
| Reliability | Reliable (retransmissions, ACKs) | Unreliable (best-effort) |
| Ordering | In-order delivery | No ordering guarantees |
| Congestion Control | Yes (AIMD, slow start, etc.) | None (applications can add their own) |
| Flow Control | Yes (receive window rwnd) | No |
| Header Size | 20–60 bytes | 8 bytes |
| Typical Applications | Web, email, file transfer | Streaming, DNS, VoIP, HTTP/3 |
Having seen the big picture, let’s dive into how transport-layer protocols multiplex and demultiplex data streams.
Multiplexing at sender: handle data from multiple sockets, add transport header (source/destination port #). Demultiplexing at receiver: use header info (IPs + ports) to deliver segments to the correct socket.
Example TCP demultiplexing:
Segment 1: src A:9157 → dst B:80 → socket 1
Segment 2: src C:5775 → dst B:80 → socket 2
Segment 3: src C:9157 → dst B:80 → socket 3
Now that we understand how segments are directed to the right application, we can examine the simpler of the two transport protocols: UDP.
UDP is a “no frills” protocol: no handshake, each segment handled independently. It is used for streaming multimedia, DNS, SNMP, and now HTTP/3 (QUIC). Reliability and congestion control can be added at the application layer.
0 16 31
+--------+--------+
| source port | dest port |
+--------+--------+
| length | checksum |
+--------+--------+
| application data (payload)
Goal: detect bit errors. Sender computes the 1’s complement sum of all 16‑bit words (including pseudo‑header fields) and stores the result in the checksum field. Receiver recomputes the sum and verifies it. It is simple and fast, though not extremely robust (some bit‑flips may cancel out).
UDP is useful when speed and simplicity matter more than reliability. For scenarios that require guaranteed delivery, we need reliable data transfer protocols – our next topic.
We incrementally develop a reliable data transfer protocol (rdt) over an unreliable channel. Finite state machines (FSMs) specify sender and receiver behaviour.
| Protocol | Channel Assumptions | Key Mechanisms |
|---|---|---|
| rdt1.0 | Perfectly reliable (no errors, no loss) | No special mechanism needed |
| rdt2.0 / 2.1 / 2.2 | Bit errors possible, no loss | Checksum, ACKs/NAKs, sequence numbers (to handle duplicates) |
| rdt3.0 | Bit errors and packet loss | All above + timeout & retransmission (stop‑and‑wait) |
No bit errors, no loss. Sender sends packet, receiver extracts data. Trivial.
To increase utilization, allow multiple in‑flight packets. Two generic approaches:
These reliable transfer principles underpin the design of TCP, which we explore next.
TCP: point‑to‑point, reliable, in‑order byte stream, full duplex, flow controlled, connection‑oriented. Uses cumulative ACKs, pipelining, and a dynamic window size.
0 16 31
+--------+--------+--------+--------+
| source port | dest port |
+--------+--------+--------+--------+
| sequence number |
+--------+--------+--------+--------+
| acknowledgement number |
+--------+--------+--------+--------+
| hdr len | not used | U A P R S F |
| | | R C S S Y I |
| | | G K H T N N |
+--------+--------+--------+--------+
| checksum | receive window (rwnd) |
+--------+--------+--------+--------+
| options (if any) |
+--------+--------+--------+--------+
| application data (variable length) |
+--------+--------+--------+--------+
TCP uses an exponentially weighted moving average (EWMA) to estimate the round‑trip time (RTT) and to measure its variation. The actual timeout is the estimated RTT plus a safety margin (typically 4 times the mean deviation). This dynamic calculation prevents premature timeouts while still reacting quickly to packet loss.
Simplified sender: on data from app, create segment, start timer if not running. On ACK, update ACKed base, restart timer if still unACKed data. On timeout, retransmit oldest unACKed segment.
Fast retransmit: if sender receives 3 duplicate ACKs (triple duplicate ACK), resend missing segment immediately, without waiting for timeout.
| Event at Receiver | TCP Receiver Action |
|---|---|
| In‑order segment with expected seq #, all data up to expected seq # already ACKed | Delayed ACK – wait up to 500 ms for next segment; if no next segment, send ACK |
| In‑order segment with expected seq #, one other segment has ACK pending | Immediately send single cumulative ACK, ACKing both in‑order segments |
| Out‑of‑order segment (higher‑than‑expected seq #) – gap detected | Immediately send duplicate ACK, indicating seq # of next expected byte |
| Segment that partially or completely fills gap | Immediate send ACK, provided that segment starts at lower end of gap |
Reliable delivery alone is not enough – TCP also prevents a fast sender from overwhelming a slow receiver through flow control.
Flow control prevents a fast sender from overwhelming a slow receiver. The receiver advertises rwnd (receive window) in the TCP header, telling the sender how much free buffer space it has.
Before any data can flow, TCP must first establish a connection – let’s see how the 3‑way handshake accomplishes that.
TCP uses a 3‑way handshake to establish a connection:
Connection closing involves FIN flags and a 2‑way or 3‑way exchange. The state transitions can be visualised as:
Active close (client): ESTAB → FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT → CLOSED
Passive close (server): ESTAB → CLOSE_WAIT → LAST_ACK → CLOSED
A TIME_WAIT state (2×MSL) ensures any delayed packets are discarded before the socket is fully closed.
With a connection in place, TCP must share network capacity fairly; this leads us to congestion control.
Congestion: too many sources sending too much data too fast for the network to handle. Manifested as long delays and packet loss. Distinct from flow control.
Costs of congestion: wasted capacity from retransmissions, long delays, and upstream resources wasted on eventually dropped packets.
We now focus on TCP’s end‑end congestion control, the dominant mechanism on the Internet.
TCP uses AIMD (Additive Increase, Multiplicative Decrease): increase sending rate by 1 MSS per RTT until loss detected, then halve the rate. This sawtooth behaviour probes for available bandwidth.
The principles of TCP congestion control have been evolving for decades; the latest major evolution is QUIC.
QUIC (Quick UDP Internet Connections) is an application‑layer protocol on top of UDP, designed to improve HTTP performance. It integrates reliability, congestion control, and encryption in one protocol, reducing handshake latency (1‑RTT, even 0‑RTT). QUIC supports multiple streams within a single connection, eliminating head‑of‑line blocking that occurs with TCP.
QUIC supports multiple streams, connection migration, and integrated TLS 1.3. It forms the basis of HTTP/3.
Instructions: Answer all questions in a separate document (PDF or Word). Submit via the learning platform. This assignment counts towards your final grade (5%).
For each false statement, write the correct version.
Grading criteria: correctness, completeness, proper use of terminology, and clarity of explanation.
Deadline: Two weeks from the lecture date.