Question 3 of 5: Transport Layer Protocols — TCP Congestion Control and UDP

Question 3: Transport Layer Protocols — TCP Congestion Control and UDP (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) — why congestion drops packets. A router is a store-and-forward device: an arriving packet is buffered on the outgoing interface's queue until the link can carry it. The queue drains at exactly the line rate of that interface, so it is stable only while the aggregate arrival rate stays below the service rate. Because traffic from many sources is bursty and statistically multiplexed, arrivals routinely exceed the service rate for short intervals, and the queue grows.

Buffers are finite, and deliberately so — memory costs money, and a very deep queue merely converts loss into unbounded delay (the pathology now called bufferbloat). When the queue is full, the router has no alternative but to discard: an arriving packet cannot be held, cannot be slowed, and there is no back-pressure mechanism in IP to tell the sender to stop. The default discipline, drop-tail, simply discards whatever arrives at a full queue. So a wired network drops packets almost exclusively because of buffer exhaustion at a bottleneck, not because of transmission errors: a modern fibre or copper link has a bit error rate around $10^{-12}$ or better, and the data-link frame check sequence removes the rare corrupted frame. That statistical fact is what licenses TCP's central inference — loss means congestion — and it is exactly the inference part (d) shows to be unsafe on a radio link.

Part (b) — window evolution with no loss.

Given. Initial congestion window $\mathit{cwnd} = 1$ segment; slow-start threshold $\mathit{ssthresh} = 16$ segments; every segment acknowledged.

Find. The value of $\mathit{cwnd}$ in each successive transmission round, through the threshold and beyond it.

1. Part (b) — slow start doubles the window each round trip. In slow start the sender increases $\mathit{cwnd}$ by one segment for every acknowledgement received, so a window that is fully acknowledged doubles once per round-trip time: $$\mathit{cwnd} \leftarrow 2\,\mathit{cwnd} \qquad \text{while } \mathit{cwnd} < \mathit{ssthresh}.$$ Starting from 1 this gives 1, 2, 4, 8, 16 over rounds 1 to 5. Despite its name, slow start is the aggressive phase — it is exponential.
2. At the threshold TCP switches to congestion avoidance. Once $\mathit{cwnd}$ reaches $\mathit{ssthresh} = 16$, the increase becomes additive: one segment per round-trip time, implemented as $\mathit{cwnd} \leftarrow \mathit{cwnd} + \text{MSS}^2/\mathit{cwnd}$ per acknowledgement, so $$\mathit{cwnd} \leftarrow \mathit{cwnd} + 1 \qquad \text{while } \mathit{cwnd} \ge \mathit{ssthresh}.$$ Rounds 6 to 9 therefore give 17, 18, 19, 20, and the window keeps creeping upward until either loss occurs or the receiver's advertised window caps it.
3. The worked example. The complete sequence is $$\boxed{1,\;2,\;4,\;8,\;16,\;17,\;18,\;19,\;20\ \text{segments, rounds 1 to 9}}$$ a total of 105 segments delivered in nine round-trip times. The sender's actual window is $\min(\mathit{cwnd}, \mathit{rwnd})$, the receiver's advertised window being the flow-control limit that runs alongside congestion control.

Part (c) — the same example with a loss in the second window. Now a segment in the second window (the round in which $\mathit{cwnd} = 2$) is never acknowledged. No duplicate acknowledgements arrive to trigger fast retransmit — with a window of two there is not enough data in flight to generate three of them — so the loss is discovered by the retransmission timer expiring, and RFC 5681 requires the sender to restart slow start.

1. Part (c) — act on the timeout. On a retransmission timeout the sender halves its estimate of the pipe and collapses the window: $$\mathit{ssthresh} \leftarrow \max\!\left(\frac{\mathit{cwnd}}{2},\; 2\,\text{MSS}\right) = \max(1,\,2) = 2, \qquad \mathit{cwnd} \leftarrow 1 .$$ The $2\,\text{MSS}$ floor is what makes the new threshold 2 rather than 1 here.
2. Slow start restarts, then congestion avoidance resumes. Round 3 retransmits with $\mathit{cwnd} = 1$; round 4 doubles to 2, which already equals the new $\mathit{ssthresh}$, so from round 5 the growth is additive again: 3, 4, 5, 6, 7. The full sequence over the same nine rounds is $$\boxed{1,\;2,\;1,\;2,\;3,\;4,\;5,\;6,\;7\ \text{segments}}$$ — 31 segments against 105 in part (b), a 70 per cent loss of throughput from a single dropped segment.
3. The features the example illustrates. Reading across the two curves in the figure: slow start (exponential, rounds 1–2 and 3–4), the congestion threshold and its multiplicative decrease ($\mathit{ssthresh}$ falling from 16 to 2), congestion avoidance (the linear segment from round 5), retransmission timeout as the loss signal, and the cumulative-acknowledgement, go-back-N-style recovery that retransmits from the lost segment. Had the loss occurred in a later, larger window, three duplicate acknowledgements would have triggered fast retransmit and fast recovery instead, halving $\mathit{cwnd}$ rather than resetting it to 1 — the difference between the sawtooth of TCP Reno and the collapse shown here. From $\mathit{cwnd} = 1$ it takes a further 19 round trips to climb back to the window of 20 the connection had reached in part (b).

Part (d) — why slow start performs badly over wireless. TCP has no way of asking why a segment was lost; it only observes that an acknowledgement failed to arrive. Part (a) established that on a wired path this inference is sound, because buffer overflow dominates every other loss mechanism. On a radio link it is not: momentary fading, shadowing, interference and handover destroy frames on a link whose bit error rate is many orders of magnitude worse than copper or fibre, and these losses carry no information whatever about the state of any queue.

The consequence is that TCP applies the congestion remedy to a non-congestion problem. A fade lasting a few tens of milliseconds costs one segment; TCP responds by halving $\mathit{ssthresh}$ and, on timeout, collapsing $\mathit{cwnd}$ to one segment. The bottleneck was never full, so the reduction buys nothing — it simply idles a link that is now perfectly healthy again, since fades are typically much shorter than the recovery. Recovery is then slow in absolute terms: as part (c) shows, regaining a window of 20 segments takes 19 further round trips, and on a cellular path with a round-trip time of 50–100 ms that is one to two seconds of under-utilisation per fade. Worse, the penalty compounds, because a fading channel delivers losses repeatedly, so the connection can spend most of its life in slow start and never reach the window the link could support. High-bandwidth-delay-product wireless paths, which need large windows precisely to fill the pipe, suffer most. Practical remedies split the problem apart rather than change TCP's inference: link-layer ARQ and hybrid ARQ hide the fade below TCP, split-connection or performance-enhancing proxies terminate TCP at the wireless edge, explicit loss notification tells the sender the loss was not congestion, and modern congestion controllers such as BBR infer congestion from delay and delivery rate instead of from loss.

Part (e) — a service better served by UDP. Real-time voice over IP — a VoIP call, or equally live video conferencing or interactive gaming — is the standard example, carried over RTP on UDP.

The reason is that TCP's guarantees are the wrong ones for interactive media. A voice codec produces a 20 ms frame whose value expires the moment its playout instant passes; a retransmission arriving one round trip later is useless, yet TCP insists on delivering it and, because it also guarantees in-order delivery, holds back every subsequent frame until the missing one arrives. That head-of-line blocking converts a single lost packet into an audible gap far longer than the packet itself. Concealing one lost 20 ms frame by interpolation is almost inaudible; stalling the stream is not. TCP's congestion control is equally unhelpful for a constant-rate codec, since halving the sending rate is not something a voice encoder can usefully do, and its per-connection overhead — a three-way handshake before the first byte, a 20-byte header against UDP's 8 — adds setup delay and bytes to small, frequent packets. UDP supplies exactly what such an application needs and nothing more: a port number, a length and an optional checksum. Sequencing, timing and loss concealment are handled above it by RTP and the jitter buffer, where the application's own knowledge of the codec can be brought to bear. The same argument explains DNS queries (one small request, one small reply, cheaper to retry than to set up a connection for), DHCP, and multicast streaming, none of which fit TCP's connection-oriented, unicast, reliable-byte-stream model.

Final results.