Question 5 of 5: Transport Layer Protocols

Question 5: Transport Layer Protocols (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) — Congestion control in TCP. TCP controls two different things with two different windows. Flow control protects the receiver from being overrun and is handled by the advertised window carried in every acknowledgement. Congestion control protects the network from being overrun and is handled by a second window, the congestion window cwnd, which the sender maintains for itself. The number of unacknowledged bytes permitted at any instant is the smaller of the two. The difficulty TCP faces is that no router tells it how much capacity is available, so the protocol must discover the operating point by experiment: it increases its rate until the network signals distress, backs off, and repeats.

The signal it uses is packet loss, on the reasoning that on a wired network transmission errors are negligible and a lost segment therefore means a router queue overflowed. Four mechanisms implement the response. Slow start opens the connection with $cwnd = 1$ maximum segment size and doubles it every round-trip time, since each of the $cwnd$ segments returns an acknowledgement that admits two more; the growth is exponential and is called slow only relative to the alternative of starting at the receiver window. Congestion avoidance takes over once $cwnd$ reaches the slow-start threshold ssthresh, after which the window grows by roughly one segment per round trip — additive increase — probing gently for extra capacity. On a timeout, ssthresh is set to half the window in force, $cwnd$ drops to 1, and slow start begins again. On three duplicate acknowledgements, which indicate a single loss with later segments still arriving, TCP Reno performs fast retransmit and fast recovery: it re-sends the missing segment immediately without waiting for the timer and halves the window rather than collapsing it, since the pipe is evidently still flowing.

The result is the characteristic sawtooth of additive increase and multiplicative decrease, an algorithm that provably converges to a fair share among flows sharing a bottleneck. It is worth noting that this is end-to-end congestion control with no help from the network, which is what has kept the Internet stable since the congestion collapses of 1986; explicit congestion notification, and modern algorithms such as CUBIC and BBR, refine the signal but keep the same feedback structure.

Part (b) — Window sizes with no loss.

Given. Slow-start threshold $\mathit{ssthresh} = 64$ segments; initial congestion window $cwnd = 1$; every segment acknowledged; the first eight transmission rounds are required.

Find. The value of $cwnd$ in each of windows 1 to 8.

Approach. Double the window each round while it is below the threshold, then add one per round once the threshold is reached.

1. Apply slow start while $cwnd \lt \mathit{ssthresh}$. Starting at 1 and doubling gives 1, 2, 4, 8, 16, 32, 64 over windows 1 through 7. In general $cwnd_{k} = 2^{k-1}$ during slow start, so the threshold of 64 is met exactly at $k = 7$.
2. Switch to congestion avoidance at the threshold. Window 7 is the first at which $cwnd = \mathit{ssthresh} = 64$, so growth becomes additive and window 8 carries $64 + 1 = 65$ segments. The sequence is therefore $$\boxed{1,\ 2,\ 4,\ 8,\ 16,\ 32,\ 64,\ 65}$$
3. Sanity-check the total. The eight windows carry $1+2+4+8+16+32+64+65 = 192$ segments in eight round-trip times, against the 8 segments a stop-and-wait sender would have managed. The threshold is unchanged at 64 because no loss occurred.

Part (c) — Window sizes with a loss in the third window.

Given. The same connection — $\mathit{ssthresh} = 64$, $cwnd$ starting at 1 — but a segment sent in the third window is not acknowledged, and TCP re-enters slow start in response.

Find. The eight window sizes and the final value of the congestion threshold.

Approach. Run slow start until the loss, halve the threshold to the window in force at the loss, restart at one, and grow again under the new threshold.

1. Windows 1 to 3, up to the loss. Slow start proceeds unchanged: $cwnd = 1$, then 2, then 4. The loss occurs while the third window of 4 segments is outstanding.
2. Set the new threshold. TCP halves the window in force at the moment of loss, so $$\mathit{ssthresh}_{\text{new}} = \frac{cwnd_{\text{at loss}}}{2} = \frac{4}{2} = 2$$ and the congestion window collapses to 1 for window 4.
3. Windows 4 to 8, under the new threshold. Slow start resumes from 1, so window 5 carries 2 — at which point $cwnd$ has already reached the new threshold of 2 and growth turns additive. Windows 6, 7 and 8 therefore carry 3, 4 and 5 segments. The full sequence and the final threshold are $$\boxed{1,\ 2,\ 4,\ 1,\ 2,\ 3,\ 4,\ 5 \quad \text{with} \quad \mathit{ssthresh} = 2}$$
4. Compare the two cases. Eight rounds now deliver $1+2+4+1+2+3+4+5 = 22$ segments against 192 without the loss — a reduction of almost 89 per cent from a single dropped packet. The punishment is severe because the threshold was halved from a window of only 4, stranding the connection in additive increase at a very low rate; this is precisely the case fast recovery was invented to soften.

Part (d) — TCP or UDP for streaming to a wireless device? UDP is the better choice, and the wireless part of the question is what makes the answer decisive rather than merely conventional.

Streaming media is loss-tolerant but delay-intolerant. A frame of audio or video that arrives after its scheduled playout instant is worthless whether or not it is correct, so TCP’s guarantee of in-order reliable delivery buys nothing and costs a great deal: a single lost segment stalls delivery of everything behind it while the retransmission is fetched, producing exactly the rebuffering pause the user notices. Losing one packet outright, by contrast, costs a few milliseconds of concealed audio that most listeners never detect. UDP also allows the application to control its own timing and to layer RTP/RTCP on top for sequencing, timestamping and quality feedback, and it supports multicast, which TCP cannot.

The wireless link sharpens the argument. TCP infers congestion from loss, but on a radio channel most loss comes from fading, interference and handover, not from a full queue. TCP responds by halving its window anyway, so throughput collapses at the very moment the link recovers — the classic misinterpretation problem on wireless links. A streaming application over UDP simply carries on, and adapts its bit rate from its own measurements of loss and jitter.

The honest qualification, worth a sentence in an exam answer, is that much commercial streaming today runs over TCP through HTTP adaptive streaming such as MPEG-DASH, because a large client-side buffer of several seconds hides retransmission delay and TCP passes firewalls unhindered. That is a pragmatic choice for on-demand video with a deep buffer. For live or interactive streaming, where the buffer must stay small, UDP remains the right transport — which is why WebRTC, VoIP and QUIC-based real-time media all sit on it.