Question 5 of 5: Transport layer protocols (25 marks)

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.

Given. TCP as specified in RFC 5681, with congestion window $\text{cwnd}$ in units of maximum segment size, initial window $\text{cwnd}_0 = 1$ MSS and slow-start threshold $\text{ssthresh} = 64$ MSS. In part (c) every segment is acknowledged; in part (d) one segment of the fourth window is not, and TCP responds by entering slow start. Find. A justified choice of transport for streaming video; a worked example showing why congestion control must be end to end; and the round-by-round evolution of $\text{cwnd}$ in both the loss-free and lossy cases, with the mechanisms named.

Part (a) — TCP or UDP for streaming video?

Part (a) — choose UDP (in practice UDP carrying RTP, or QUIC, which is UDP-based). The reasoning is that video playback has a deadline, and TCP's two guarantees both work against a deadline.

The first is reliability. TCP will retransmit a lost segment however long that takes, and will deliver bytes strictly in order. On an unreliable link a retransmission costs at least one further round trip, by which time the frame it carried may already be past its play-out instant — the data arrives correct and useless. Worse, in-order delivery means the lost segment blocks every correctly-received segment behind it in the receive buffer, so one loss stalls the whole stream: head-of-line blocking. A video decoder, by contrast, has excellent defences of its own — error concealment from neighbouring macroblocks, forward error correction, and the fact that the next intra frame resynchronises the picture — so a small loss rate degrades quality gracefully rather than stopping playback.

The second is congestion control. TCP responds to any loss by halving its sending rate; on a link whose loss is caused by corruption rather than congestion, that response is unnecessary and produces exactly the rate collapse and rebuffering the user notices. UDP hands rate control to the application, which can adapt deliberately — switching to a lower bit-rate encoding, dropping enhancement layers, or increasing FEC — using its own knowledge of the codec.

Two qualifications complete the answer. UDP's advantages come with the obligation to implement sequencing, timing and rate adaptation in the application, which is what RTP with RTCP feedback exists for; and a UDP stream must still be congestion-aware, or it becomes exactly the unresponsive flow described in part (b). And in the real world, on-demand streaming (Netflix, YouTube) mostly runs over TCP via HTTP adaptive streaming, because a stored video can be buffered for tens of seconds and because TCP on port 443 traverses NAT and firewalls that block UDP. The question specifies an unreliable link, which points to live or interactive video and to UDP; the complete answer states the choice and names the condition — buffer depth — that would change it.

Part (b) — Why congestion control must be end to end

1. Part (b) — set up a heterogeneous path. A server on a 1 Gbit/s campus LAN sends a large file to a client behind a 10 Mbit/s access link. The router at the junction has a buffer of 100 packets of 1500 bytes:
   $$B = 100 \times 1500 \times 8 = 1\,200\,000\ \text{bits}, \qquad R_{\text{in}} = 1\ \text{Gbit/s}, \qquad R_{\text{out}} = 10\ \text{Mbit/s}$$The capacity ratio is $R_{\text{in}} / R_{\text{out}} = 100$.
2. Send at line rate with no congestion control and time the buffer. The queue grows at the difference of the two rates, so it fills in
   $$t_{\text{fill}} = \frac{B}{R_{\text{in}} - R_{\text{out}}} = \frac{1.2 \times 10^{6}}{9.9 \times 10^{8}} = 1.21\ \text{ms}$$After that the router is in steady overflow and must discard the fraction it cannot forward:
   $$\text{loss} = 1 - \frac{R_{\text{out}}}{R_{\text{in}}} = 1 - 0.01 = 99\%$$
3. Count the wasted work. Every one of those discarded packets was carried across the whole campus LAN, switched, and queued before being thrown away at the last hop. That capacity is consumed and delivers nothing, and it is denied to other flows crossing the same links. This is congestion collapse: offered load rises, goodput falls. The surviving packets fare no better — a full buffer draining at 10 Mbit/s imposes a standing queueing delay of $1.2 \times 10^{6} / 10^{7} = 120$ ms on every one of them, which destroys any interactive traffic sharing the link.
4. Show that only an end-to-end signal fixes it. The sender is the only entity that can reduce the offered load, and the bottleneck is the only entity that knows the load is excessive; those two are separated by the whole path. Hop-by-hop flow control on the LAN would merely push the queue back one switch and cause head-of-line blocking for unrelated flows, and it cannot arbitrate between several senders converging on the same bottleneck. Only a signal that traverses the path — a lost segment, a triple duplicate ACK, or an ECN mark echoed by the receiver — can tell this sender to slow to
   $$\boxed{R_{\text{sender}} \approx R_{\text{out}} = 10\ \text{Mbit/s}}$$which is a rate no node on the path could have computed alone.

The heterogeneity in the question is the crux. If every link had the same capacity there would be no bottleneck to discover and static rate limits would suffice; because capacities differ, and differ again for every destination and every moment, the correct sending rate is a property of the whole path and can only be learned by probing it. That is precisely what TCP's congestion window does, and part (c) shows the probe in action.

Part (c) — Window evolution with no loss

1. Part (c) — slow start, while cwnd is below the threshold. The sender starts with $\text{cwnd} = 1$ MSS and increases cwnd by one MSS for every segment acknowledged. A window of $w$ segments generates $w$ acknowledgements in one round trip, so
   $$\text{cwnd} \leftarrow \text{cwnd} + 1 \text{ per ACK} \quad\Longrightarrow\quad \text{cwnd}_{n+1} = 2\,\text{cwnd}_{n} \text{ per RTT}$$The growth is exponential in round-trip times — the name “slow start” refers to starting from one segment rather than to the rate of increase.
2. Run it to the threshold. Doubling from 1 reaches $\text{ssthresh} = 64$ after six doublings, since $2^{6} = 64$, so cwnd takes the values 1, 2, 4, 8, 16, 32, 64 in rounds 1 to 7. Over those seven rounds the sender has injected $1+2+4+8+16+32+64 = 127$ segments, i.e. $2^{7} - 1$.
3. Switch to congestion avoidance at the threshold. Once $\text{cwnd} \ge \text{ssthresh}$ the sender increases cwnd by roughly one MSS per round trip rather than per ACK:
   $$\text{cwnd} \leftarrow \text{cwnd} + \frac{1}{\text{cwnd}} \text{ per ACK} \quad\Longrightarrow\quad \text{cwnd}_{n+1} = \text{cwnd}_{n} + 1 \text{ per RTT}$$so rounds 8 onward give 65, 66, 67, 68, 69, … This is the additive increase of AIMD: having found the neighbourhood of the path's capacity, TCP now probes it gently.

The example in full:

$$\boxed{1,\ 2,\ 4,\ 8,\ 16,\ 32,\ 64 \;\text{(slow start)}, \quad 65,\ 66,\ 67,\ 68,\ 69, \ldots \;\text{(congestion avoidance)}}$$

Part (d) — The same example with a loss in the fourth window

1. Part (d) — locate the loss. Rounds 1 to 3 are unchanged: cwnd = 1, 2, 4. The fourth window is therefore $\text{cwnd} = 8$ segments, and one of those eight is not acknowledged.
2. Apply multiplicative decrease. The sender halves the threshold to the window that was in flight when the loss occurred, and — as the question specifies — restarts slow start from one segment, which is the response to a retransmission timeout:
   $$\text{ssthresh} \leftarrow \frac{\text{cwnd}}{2} = \frac{8}{2} = 4, \qquad \text{cwnd} \leftarrow 1$$The lost segment is retransmitted, and the retransmission timer is backed off exponentially in case the loss repeats.
3. Slow-start again, but only as far as the new threshold. From round 5 cwnd doubles: 1, 2, 4. It reaches the new $\text{ssthresh} = 4$ in round 7, five rounds earlier than before because the threshold is sixteen times lower.
4. Then additive increase. From round 8 onward cwnd grows by one per round trip: 5, 6, 7, 8, 9, … It regains the pre-loss window of 8 segments in round 11, seven round trips after the loss — the cost of one dropped packet.

$$\boxed{1,\ 2,\ 4,\ 8 \;\text{(loss)}, \quad 1,\ 2,\ 4 \;\text{(slow start to the new ssthresh} = 4), \quad 5,\ 6,\ 7,\ 8,\ 9, \ldots \;\text{(congestion avoidance)}}$$

The features of TCP this example illustrates, which is what the last marks are for:

• Slow start — exponential probing from one segment, used both at connection start and after a timeout, because the sender has no estimate of the path capacity.
• The slow-start threshold — the boundary between the two growth laws, and TCP's memory of where trouble was last found.
• Congestion avoidance — additive increase of one MSS per RTT near the estimated capacity.
• Multiplicative decrease — halving on loss. Together with additive increase this is AIMD, which is what makes competing TCP flows converge on a fair share of a bottleneck.
• Loss as the congestion signal — TCP has no explicit message from the network (absent ECN), so a missing acknowledgement is the only evidence available.
• Timeout versus fast retransmit — the question specifies entering slow start, which is the timeout response (and TCP Tahoe's response to any loss). A TCP Reno sender that detected the same loss from three duplicate ACKs would use fast retransmit and fast recovery, setting $\text{cwnd} = \text{ssthresh} = 4$ and continuing in congestion avoidance without ever dropping to 1 — the ACKs prove the path is still delivering, so the collapse to one segment is unwarranted. Comparing the two on the same example is the neatest way to show the distinction.
• Cumulative acknowledgement and self-clocking — an ACK acknowledges everything up to a byte number, and each arriving ACK is what releases the next segment, so the sender is paced by the bottleneck itself.
• Exponential backoff of the retransmission timer — RTO doubles on each successive timeout, so a persistently congested path is probed ever more gently.