Question 2 of 5: Transport Layer Protocols

Question 2: 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) — TCP or UDP for video streaming over a mobile wireless link? For a live or interactive stream the answer is UDP, carrying RTP and a codec that tolerates loss. The reasoning turns on what the two transports do when a packet goes missing. TCP guarantees an ordered, complete byte stream, which it achieves by retransmitting; on a mobile link a retransmission costs at least one round-trip time, and the replacement frame arrives after its playout instant has passed, so it is useless to the decoder while simultaneously stalling every packet queued behind it — head-of-line blocking. Worse, as part (c) develops, TCP interprets a fading loss as congestion and halves its rate, so the picture quality falls at exactly the moment the radio channel recovers. UDP simply delivers what arrives: a lost slice degrades one macroblock region for a few frames, the decoder conceals it, and the stream keeps its timing.

The engineering trade is therefore timeliness against fidelity, and video is one of the few applications that prefers timeliness. The application must then supply what UDP does not: RTP sequence numbers and timestamps for reordering and jitter removal, a de-jitter buffer of 100–300 ms, forward error correction or a scalable codec layer for resilience, and RTCP feedback so the sender can rate-adapt — because an application that ignores congestion signals is not welcome on a shared network. The honest qualification: stored, non-interactive streaming (Netflix, YouTube) does the opposite and runs adaptive-bitrate HTTP over TCP, because a buffer of tens of seconds absorbs retransmission delay and fidelity then matters more than latency. The deciding question is the size of the playout buffer relative to the round-trip time.

Part (b) — why end-to-end congestion control is necessary when links differ in capacity. A packet network offers no admission control: a source may emit at any rate its own interface allows, and every router it traverses absorbs the mismatch in a finite buffer. Where capacities differ, the mismatch is structural rather than accidental, and only the end systems — which alone know the whole path — can resolve it.

Example. Two hosts, A and B, each attached by 1 Gbit/s Ethernet to a router R, which reaches the destination network over a single 10 Mbit/s wide-area link with a 250-packet buffer. A begins a bulk transfer and, without congestion control, sends at its line rate. R can drain only 10 Mbit/s, so the buffer fills in a few milliseconds and the queue then discards a hundred packets for every one it forwards. Three things now happen, and each of them is the reason end-to-end control exists:

• Goodput collapses. The 10 Mbit/s link stays busy, but most of what it carries is a packet whose earlier or later siblings were dropped, so the receiver can reassemble very little. A blind retransmitter re-sends the losses, adding yet more load — the classic congestion-collapse feedback loop of the mid-1980s Internet.
• The queue destroys latency for everyone. A full 250-packet buffer at 10 Mbit/s and 1500 bytes per packet holds $250 \times 1500 \times 8 / (10 \times 10^{6}) = 0.30$ s of standing delay, so host B's interactive session, which is offering only 100 kbit/s and is congesting nothing, suffers 300 ms of added round-trip delay.
• Nothing local can fix it. R cannot slow A down: flow control between A and R is satisfied, because the Ethernet is not the bottleneck. Only A knows it is receiving loss or delay signals from the far end, and only A can reduce its offered rate.

With end-to-end control the first losses (or ECN marks) reach A within one round-trip time, A halves its congestion window, and the sending rate converges on the fair share of the 10 Mbit/s bottleneck. The general principle is that the bottleneck may be any link on the path, may change during the connection, and is invisible to every node except the ones that can measure the path end to end — which is the argument for placing the control loop in the transport layer.

Part (c) — why TCP is suboptimal over a wireless link. TCP's congestion control rests on one inference: that a lost segment means a full queue somewhere on the path. That inference was sound when the only lossy element was a router buffer, and it is false on a radio link, where the multipath fading of Question 1(d) destroys frames while every queue on the path is empty. TCP cannot tell the two apart — both present as a missing acknowledgement — so it applies the congestion remedy to a corruption problem: on three duplicate ACKs it halves the congestion window and the slow-start threshold; on a timeout it collapses the window to one segment and restarts slow start.

The penalty is severe and self-reinforcing. Throughput falls just when the channel is recovering, so the connection under-uses a link that is once again perfectly good; the loss rate seen by TCP is far higher than the residual rate a wired path would show, and since steady-state throughput varies roughly as $1/\sqrt{p}$ with loss probability $p$, a 1 percent frame-loss rate is enough to cripple a long connection. Recovery is slow because it proceeds one segment per round-trip time in congestion avoidance, and a link that fades every few hundred milliseconds may never leave the low-window region at all. The usual mitigations attack the false inference rather than TCP itself: link-layer ARQ and hybrid ARQ hide residual radio losses from the transport (this is what LTE's RLC layer does), split connections or performance-enhancing proxies terminate TCP at the base station, explicit congestion notification lets routers signal real congestion without dropping, and loss-differentiating or delay-based algorithms — TCP Westwood, Veno, and today BBR — estimate the bottleneck rate directly instead of reading every loss as congestion.

Part (d) — window evolution from 1 to beyond a threshold of 64.

Given. Initial congestion window $cwnd_0 = 1$ segment (MSS); slow-start threshold $ssthresh = 64$ segments; every transmitted segment is acknowledged, so no loss occurs; one window is sent per round-trip time.

Find. The congestion window in each successive transmission round, up to the threshold and beyond it.

Approach. Apply the two growth laws of TCP congestion control in turn — exponential (slow start) while $cwnd < ssthresh$, then linear (congestion avoidance) once the threshold is reached.

1. Slow start: double the window every round. While $cwnd$ is below $ssthresh$, every acknowledgement increases $cwnd$ by one segment, so a whole window of ACKs doubles it: $$cwnd_{k+1} = 2\,cwnd_{k}, \qquad cwnd < ssthresh.$$ Starting from one segment the window therefore takes the values 1, 2, 4, 8, 16, 32, 64 in transmission rounds 1 to 7.
2. Identify the round at which the threshold is met. Since $cwnd_{k} = 2^{\,k-1}$ during slow start, the threshold is reached when $2^{\,k-1} = 64$, that is $$k = 1 + \log_2 64 = \boxed{\text{round } 7,\ cwnd = 64 \text{ segments}}$$ By that point $1+2+4+8+16+32+64 = 127$ segments have been sent, so the exponential phase costs only seven round-trip times to reach a large window.
3. Congestion avoidance: add one segment per round. At and beyond the threshold TCP switches to additive increase, raising $cwnd$ by one MSS per round-trip time (each ACK contributes $1/cwnd$): $$cwnd_{k+1} = cwnd_{k} + 1, \qquad cwnd \ge ssthresh.$$ The window therefore continues 65 in round 8, 66 in round 9, and so on, probing for the path capacity gently instead of doubling into it.

Written out, the example asked for is:

Round: 1  2  3  4  5  6  7  8  9  —  cwnd: 1  2  4  8  16  32  64  65  66

Part (e) — the same example with a loss in the fourth window.

Given. $cwnd_0 = 1$ segment; initial $ssthresh = 64$ segments; a segment sent in the fourth window is lost, and the loss is discovered by retransmission timeout, so TCP re-enters slow start.

Find. The window sequence before and after the loss, identifying the new threshold and the point at which growth becomes linear.

Approach. Grow the window exponentially to the fourth round, apply the multiplicative decrease that a timeout triggers, then repeat the two growth laws against the new threshold.

1. Grow to the fourth window. Slow start is unaffected until the loss, so rounds 1 to 4 carry windows of $$cwnd = 1,\ 2,\ 4,\ 8 \text{ segments,}$$ and the segment that goes missing is one of the eight sent in round 4.
2. Apply multiplicative decrease at the loss. The retransmission timer expires before the missing acknowledgement arrives. TCP records half the window in flight as the new threshold and restarts from one segment: $$ssthresh_{new} = \frac{cwnd_{loss}}{2} = \frac{8}{2} = \boxed{4 \text{ segments}}, \qquad cwnd \leftarrow 1 \text{ segment.}$$ The lost segment is retransmitted, and the original threshold of 64 is discarded — the network has just demonstrated that 64 was optimistic.
3. Slow start again, against the new threshold. Exponential growth resumes from one segment but now stops much sooner, at the new threshold: rounds 5, 6 and 7 carry $$cwnd = 1,\ 2,\ 4 \text{ segments,}$$ so slow start lasts only three rounds instead of seven.
4. Congestion avoidance from the new threshold. With $cwnd = ssthresh = 4$ the algorithm switches to additive increase, giving 5, 6, 7 segments in rounds 8, 9 and 10: $$cwnd_{k+1} = cwnd_{k} + 1 \quad\text{for } cwnd \ge 4.$$ Twelve rounds after the loss — at round 16 — the window has recovered only to 13 segments, against the 64 the loss-free run of part (d) reached in seven — the cost of a single lost packet.

The complete example is:

Round: 1  2  3  4  5  6  7  8  9  10  —  cwnd: 1  2  4  8 (loss)  1  2  4  5  6  7

The features of TCP the question asks to be illustrated are all visible in that sequence: slow start (rounds 1–4 and 5–7, exponential); the slow-start threshold as the boundary between the two growth laws, and its adaptation from 64 to 4; multiplicative decrease at the loss and additive increase afterwards, the AIMD pair that makes TCP converge to a fair share; timeout-based loss detection, which is what forces the window all the way back to one; and self-clocking, since each round advances only when the previous window's acknowledgements return.