Question 2 of 5: The Transport Layer

Question 2: 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.

1. Part (a) — why congestion control is necessary. Congestion is a property of the network, not of the receiver. Where links have different capacities, traffic arriving on a fast link and leaving on a slow one queues at the router, and because the buffer is finite the queue eventually overflows and packets are discarded. Every discarded packet has already consumed capacity on every upstream link it crossed, so that work is wasted; worse, the sender's retransmission timer fires and it injects the same data again, adding load exactly when the network can least carry it. Without a control loop this positive feedback drives the network into congestion collapse, in which offered load keeps rising while useful throughput (goodput) falls toward zero and queueing delay grows without bound. Congestion control forces every sender to infer the state of the bottleneck — classically from packet loss, or from explicit marks or delay — and to hold its sending rate near the bottleneck capacity, which also apportions that capacity fairly among the competing flows. It must not be confused with flow control: flow control is the receiver-advertised window that stops a fast sender from overrunning a slow host, whereas congestion control protects the network between them, and TCP obeys the smaller of the two windows for exactly that reason.

2. Part (b) — why UDP can beat TCP for video streaming. Streaming media is loss-tolerant but delay-intolerant: a lost frame degrades one moment of picture, whereas a late frame is useless because its playout instant has passed. TCP is built for the opposite priority. It retransmits every lost segment and delivers bytes strictly in order, so one lost segment stalls delivery of every correctly received segment behind it — head-of-line blocking — and the retransmission cannot arrive sooner than one further round-trip time. Its congestion control also halves the sending rate on each loss, producing a sawtooth rate that maps badly onto a constant-bit-rate stream and shows up to the viewer as rebuffering. UDP simply hands each datagram to IP: there is no connection setup delay, no retransmission, no reordering buffer and no rate oscillation, so the application can keep a small playout buffer and control its own pacing. It also lets the application choose its own error strategy, such as forward error correction or concealment of a lost slice, and it supports multicast for a live stream to many viewers, which TCP cannot do. The price is that the application must supply for itself whatever sequencing, timing and rate adaptation it needs, which is what RTP over UDP provides in practice.

3. Part (c) — the two growth regimes. With an initial congestion window $\text{cwnd}_1 = 1$ segment and a slow-start threshold $\text{ssthresh} = 16$ segments, TCP grows the window once per round-trip time under two different rules. While $\text{cwnd} < \text{ssthresh}$ it is in slow start and increases the window by one segment for every acknowledgement received, which doubles it each round trip; once $\text{cwnd} \geq \text{ssthresh}$ it switches to congestion avoidance and adds one segment per round trip:
   $$\text{cwnd}_{n+1} = \begin{cases} 2\,\text{cwnd}_n, & \text{cwnd}_n < \text{ssthresh} \quad \text{(slow start)}\\[4pt] \text{cwnd}_n + 1, & \text{cwnd}_n \geq \text{ssthresh} \quad \text{(congestion avoidance)} \end{cases}$$

   The first regime is exponential and finds the available capacity quickly; the second is linear and probes for extra capacity gently.

4. Tabulate the windows with every packet acknowledged. Doubling from 1 gives 1, 2, 4, 8, 16, so the threshold is reached at the fifth window, after which the growth is additive:

   Window (round)	1	2	3	4	5	6	7	8
   cwnd (segments)	1	2	4	8	16	17	18	19
   Regime	slow start (exponential)				congestion avoidance (linear)

   $$\boxed{\text{cwnd} = 1,\,2,\,4,\,8,\,16,\,17,\,18,\,19,\,\ldots\ \text{segments}}$$

   Two checks are worth making. The window at the start of round $n$ during slow start is $2^{\,n-1}$, so $\text{cwnd}_5 = 2^{4} = 16$ as tabulated, and the total number of segments offered over those five rounds is $1+2+4+8+16 = 31 = 2^{5}-1$. Growth beyond the threshold is one segment per round trip and continues until a loss occurs or the receiver's advertised window becomes the binding constraint.

5. Part (d) — what a lost packet in the third window does. The third window carries $\text{cwnd}_3 = 4$ segments. When one of them is not acknowledged and the retransmission timer expires, TCP (Tahoe behaviour, and the behaviour every implementation still uses after a genuine timeout) treats the loss as evidence of congestion and does two things at once: it halves the threshold to the window that caused trouble,
   $$\text{ssthresh}_{\text{new}} = \max\left(2,\ \frac{\text{cwnd}}{2}\right) = \frac{4}{2} = 2 \ \text{segments}$$

   and it collapses the congestion window back to one segment and re-enters slow start. Doubling from 1 therefore stops at the new threshold of 2 after a single round trip, and growth is linear from there on.

6. Give the first eight windows. Applying that rule to the sequence of part (c):

   Window (round)	1	2	3	4	5	6	7	8
   cwnd (segments)	1	2	4 (loss)	1	2	3	4	5
   ssthresh	16	16	16 → 2	2	2	2	2	2

   $$\boxed{\text{cwnd} = 1,\,2,\,4,\,1,\,2,\,3,\,4,\,5 \ \text{segments}}$$

   If instead the loss is detected by three duplicate acknowledgements rather than by a timeout, a TCP Reno sender performs fast retransmit and fast recovery: it sets ssthresh to 2 as before but resumes from that value in congestion avoidance rather than from 1, giving 1, 2, 4, 2, 3, 4, 5, 6. The Tahoe sequence above is the answer expected here, because the question says only that a packet “is not acknowledged”, which is the timeout case.

7. Plot both cases on one axis. The figure below overlays the loss-free evolution of part (c) with the post-loss evolution of part (d); the circled point is the window in which the loss occurs.
   Figure 2.1 — Congestion-window evolution. Blue: no loss (part c), doubling to the threshold of 16 at round 5 and then adding one per round. Red: a packet in the third window is lost (part d), so ssthresh falls to 2, cwnd restarts at 1, and growth becomes linear after round 5. The dashed line is the initial threshold of 16.