The transport layer: 22-Elec-B4 Information Technology Networks, May 2015, Q3

Question 3: The transport layer (25 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Part (a) — the major differences. Both protocols do the one thing the transport layer must do, which is to multiplex and demultiplex data between processes using port numbers, and to checksum what they carry. Beyond that they are opposites: TCP adds every service a stream could want, and UDP deliberately adds nothing.

Property	TCP (RFC 793)	UDP (RFC 768)
Connection	Connection-oriented: a three-way handshake (SYN, SYN-ACK, ACK) establishes state at both ends before any data moves, and a four-way exchange closes it.	Connectionless: a datagram may be sent at any time with no prior exchange and no state kept.
Reliability	Reliable: every byte is sequence-numbered, acknowledged, and retransmitted on timeout or on triple duplicate ACK.	Best effort: a lost datagram is simply lost, and the application must detect and handle it or tolerate it.
Ordering	Delivers the byte stream in the order sent, buffering out-of-order segments until the gap is filled.	Delivers datagrams in whatever order they arrive.
Flow control	Yes — the receiver advertises a window so a fast sender cannot overrun a slow receiver's buffer.	None; the receiver's buffer can overflow silently.
Congestion control	Yes — slow start plus AIMD, which is what keeps the Internet stable under load.	None; a UDP source transmits at whatever rate the application chooses.
Service model	A byte stream: message boundaries are not preserved, and the receiver may read a different segmentation than the sender wrote.	A message service: each datagram is delivered whole or not at all, preserving boundaries.
Header and overhead	20 bytes minimum, plus handshake round trips and per-connection state at both ends.	8 bytes, no round trips, no state — so one server can serve very large client populations cheaply.
Addressing modes	Unicast only, because a connection has exactly two endpoints.	Supports unicast, broadcast and multicast.

The single sentence that captures it: TCP trades latency and complexity for a guarantee, and UDP trades the guarantee for latency and simplicity.

Part (b) — one application for each. Better for TCP: bulk file transfer, and web page delivery over HTTP. The content is useless unless every byte arrives exactly once and in order — a missing block in an executable or a corrupted row in a database export is a failure, not a glitch — and the transfer is elastic, so it is content to run faster or slower as capacity allows, which is exactly what TCP's congestion control delivers. Better for UDP: real-time voice or video, such as a VoIP call. A packet that has to be retransmitted arrives long after its playout deadline and is therefore worthless, so retransmission would add delay without adding value; the codec conceals the occasional lost packet far more gracefully than the conversation tolerates a stall, and a constant-rate stream has no use for a window that halves on loss. A second good UDP example is DNS, where the whole transaction is one small request and one small reply and a TCP handshake would triple the latency of a lookup that is repeated billions of times a day.

Part (c) — evolution of the congestion window.

Given. Initial congestion window $\text{cwnd}_1 = 1$ MSS; congestion threshold (slow-start threshold) $\text{ssthresh} = 16$ MSS; every segment is acknowledged, so there is no loss and no timeout anywhere in the trace.

Find. The sequence of window sizes, round by round, showing both the behaviour below the threshold and the behaviour above it.

Approach. Apply the two rules of RFC 5681: while $\text{cwnd} < \text{ssthresh}$ the sender is in slow start and increases cwnd by one MSS for every ACK received, which doubles cwnd every round-trip time; once $\text{cwnd} \ge \text{ssthresh}$ it is in congestion avoidance and increases cwnd by one MSS per round-trip time.

Part (c) — slow start: exponential growth to the threshold. In round 1 the sender may have one segment outstanding; its ACK increases cwnd to 2, those two ACKs add two more, and so on, so the window doubles each round: $$\text{cwnd}_{k+1} = 2\,\text{cwnd}_{k} \quad \text{while } \text{cwnd}_k < 16$$ giving 1, 2, 4, 8, 16 over rounds 1 to 5. Note that "slow start" describes the starting point, not the growth rate — the growth is exponential, and the name only makes sense against the alternative of opening at the full receiver window.
Congestion avoidance: linear growth beyond the threshold. At the end of round 5 the window has reached the threshold of 16, so the sender switches rules and now adds only one MSS per round-trip: $$\text{cwnd}_{k+1} = \text{cwnd}_{k} + 1 \quad \text{while } \text{cwnd}_k \ge 16$$ giving 17, 18, 19, 20 over rounds 6 to 9, and continuing to climb by one until either loss occurs or the receiver's advertised window caps it.
Tabulate the example trace. Writing out the first nine transmission rounds:

Round (window)	1	2	3	4	5	6	7	8	9
cwnd (MSS)	1	2	4	8	16	17	18	19	20
Phase	slow start (exponential)					congestion avoidance (linear)

Figure 3.1 — Congestion window against transmission round for part (c). The window doubles each round to the dashed threshold of 16, then rises by one segment per round.

The number of segments the sender has been able to inject by the end of round 9 is $1+2+4+8+16+17+18+19+20 = 105$ MSS, of which the first five rounds contributed only 31 — the exponential phase is short, and almost all of the transfer happens in congestion avoidance.

Part (d) — a packet in the third window is lost.

Given. The same trace as above (initial window 1, threshold 16), except that a segment sent in the third window is not acknowledged. From part (c) the third window has $\text{cwnd} = 4$.

Find. The congestion window for each of the first eight windows.

Approach. An unacknowledged segment that produces no ACK at all is detected by the retransmission timer expiring. On timeout, TCP sets the threshold to half the window in flight, collapses the window to one MSS and re-enters slow start.

Part (d) — windows 1 to 3 are unchanged. Nothing is known to be wrong until the loss is detected, so the sender is still in slow start: cwnd = 1, 2, 4.
Apply the timeout response. The window in flight when the loss occurred was 4, so $$\text{ssthresh}_{\text{new}} = \frac{\text{cwnd}_{\text{loss}}}{2} = \frac{4}{2} = 2\ \text{MSS}, \qquad \text{cwnd} \leftarrow \boxed{1\ \text{MSS}}$$ The threshold's job is to remember, roughly, the rate the path was carrying when it broke, so that the sender rushes back to half of it and then probes gently.
Restart slow start, now against a threshold of 2. Window 4 is 1; window 5 doubles it to 2, which already equals the new threshold, so from window 6 onward the sender is in congestion avoidance and adds one per round: windows 6, 7 and 8 are 3, 4 and 5.
Collect the eight windows. The requested sequence is $$\boxed{1,\; 2,\; 4,\; 1,\; 2,\; 3,\; 4,\; 5}$$ with the drop occurring at the end of window 3.

Window	1	2	3	4	5	6	7	8
cwnd (MSS)	1	2	4 (loss)	1	2	3	4	5
ssthresh (MSS)	16	16	16	2

Figure 3.2 — Part (d) in blue against the loss-free trace of part (c) in grey. The circle marks the loss at the end of window 3; the window collapses to 1 and slow start restarts against the new threshold of 2.

Check: this answer assumes the loss is detected by timeout, which is what "a packet is not acknowledged" most directly describes, and it is the behaviour of TCP Tahoe and of any Reno sender whose window is too small to generate three duplicate ACKs — with only four segments in flight, three duplicate ACKs are in fact unlikely, so the timeout reading is also the physically correct one here. If instead the loss were signalled by three duplicate ACKs, a TCP Reno sender would use fast retransmit and fast recovery: it would halve the window rather than collapse it, giving 1, 2, 4, 2, 3, 4, 5, 6. State whichever assumption you use.

Topic. Transport-layer service models, and TCP's additive-increase / multiplicative-decrease congestion control.

Key relations. Slow start: $\text{cwnd} \leftarrow 2\,\text{cwnd}$ per RTT while $\text{cwnd} < \text{ssthresh}$. Congestion avoidance: $\text{cwnd} \leftarrow \text{cwnd} + 1$ MSS per RTT. On timeout: $\text{ssthresh} \leftarrow \text{cwnd}/2$ and $\text{cwnd} \leftarrow 1$. On triple duplicate ACK (Reno): $\text{ssthresh} \leftarrow \text{cwnd}/2$ and $\text{cwnd} \leftarrow \text{ssthresh}$. Sending rate $\approx \text{cwnd} \times \text{MSS} / \text{RTT}$.

Why this works. A sender cannot see the network's capacity, so TCP discovers it by experiment: increase until something breaks, then back off and creep up again. The two rates are chosen for stability rather than for speed. Exponential increase is used only at the very start, where the sender knows nothing and the cost of being wrong is small, and it stops at the threshold because the threshold is the last rate known to have worked. Linear increase thereafter probes for extra capacity slowly enough that many flows sharing a bottleneck converge on a fair share, while multiplicative decrease sheds load fast enough to clear congestion before buffers collapse — it is the asymmetry between the gentle increase and the sharp decrease that makes the whole system stable and roughly fair.

Common pitfall. Three recur. First, halving the window instead of collapsing it to 1 after a timeout: halving is the fast-recovery response to duplicate ACKs, not the timeout response. Second, setting the new threshold to half of the old threshold (8) rather than half of the window actually in flight when the loss occurred (2). Third, counting the loss window twice, so that the answer has nine entries; the loss happens at the end of window 3, and window 4 is the first window of the restart.

Source. Kurose and Ross, Computer Networking: A Top-Down Approach, 8th ed., §3.5–3.7; RFC 5681 §3.1 (slow start and congestion avoidance); Leon-Garcia and Widjaja, Communication Networks, 2nd ed., §8.2–8.4.

Question 3 of 5: The transport layer

Question 3: The transport layer (25 marks)