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

Given. A TCP sender whose initial congestion window is $cwnd_{0} = 1$ MSS and whose slow-start threshold is $ssthresh = 32$ MSS. In part (c) every segment is acknowledged; in part (d) a segment of the fourth window is lost and the sender times out, so it re-enters slow start.

Find. The round-by-round evolution of the congestion window in both cases, with the transition from slow start to congestion avoidance identified.

Part (a) — TCP against UDP. Both are transport protocols that add a 16-bit port number pair to multiplex many processes onto one IP address, and there the similarity stops. TCP is connection-oriented: a three-way handshake establishes state at both ends before any data flows, and a four-way exchange tears it down. It presents a reliable, in-order byte stream, achieved with sequence numbers, cumulative acknowledgements, retransmission timers and fast retransmit, so the application never sees a loss, a duplicate or a reordering. It also runs two distinct feedback loops that UDP does not have: flow control, which stops a fast sender from overrunning a slow receiver by honouring the advertised receive window, and congestion control, which stops the aggregate of all senders from overrunning the network. The price is a 20-byte minimum header, a round trip of set-up latency and head-of-line blocking, because a single lost segment stalls delivery of everything behind it. UDP is connectionless and adds only an 8-byte header containing source and destination ports, a length and an optional checksum; it delivers datagrams best-effort with no ordering, no retransmission, no flow control and no congestion control. That makes UDP the right choice for single-exchange request/response protocols where a retransmission by the application is cheaper than a connection (DNS, SNMP, DHCP), for real-time media where a late packet is worthless and a retransmitted one is worse than a lost one (voice and video), and for multicast, which TCP cannot support at all because its acknowledgement model is strictly point-to-point.

Part (b) — why end-to-end congestion control is necessary. Consider a large wired network in which fifty branch offices each attach at 10 Mbit/s and all reach one data centre through a single 45 Mbit/s wide-area link. Nothing in the IP layer tells a sender how much capacity is available, so if the offices between them offer 100 Mbit/s to a 45 Mbit/s link, the router queue in front of that link fills, its delay grows until it exceeds the senders’ retransmission timers, and the senders begin retransmitting segments that are in fact still queued. Those retransmissions are indistinguishable from new data, so the offered load rises further, the queue overflows, and packets are dropped after having already consumed capacity on every upstream link they crossed. The link stays 100 per cent utilised while the useful throughput — the goodput — falls towards zero. This is congestion collapse, and it is not a thought experiment: in October 1986 the link between Lawrence Berkeley Laboratory and the University of California at Berkeley collapsed from its nominal 32 kbit/s to about 40 bit/s, a factor of eight hundred, which is what prompted Van Jacobson’s congestion avoidance algorithms. Hop-by-hop backpressure alone cannot fix this in a large datagram network, because a router would have to keep per-flow state for every conversation crossing it and because backpressure simply pushes the queue one hop upstream. Only the end systems observe the end-to-end signal — a missing acknowledgement or a rising round-trip time — and only they can reduce their sending rate; because every conforming sender reacts the same way, the aggregate load is driven back to the capacity of the bottleneck without any router keeping per-flow state.

Parts (c) and (d) — window evolution. The two trajectories are computed below and plotted in Figure 2.1.

1. Part (c) — apply the slow-start rule. During slow start the sender increases $cwnd$ by one MSS for every segment acknowledged, so a full window of acknowledgements doubles the window once per round-trip time: $$cwnd_{k+1} = 2\,cwnd_{k}, \qquad cwnd \lt ssthresh$$ Starting from $cwnd_{1} = 1$ this gives 1, 2, 4, 8, 16 and 32 MSS in rounds 1 to 6, that is $cwnd_{k} = 2^{k-1}$, and $\boxed{cwnd_{6} = 32\text{ MSS} = ssthresh}$ after six round trips. Summing the windows, the sender has put $1+2+4+8+16+32 = 63$ segments on the wire during slow start.
2. Cross the threshold into congestion avoidance. Once $cwnd \ge ssthresh$ the sender switches to additive increase, raising the window by one MSS per round trip rather than doubling it: $$cwnd_{k+1} = cwnd_{k} + 1, \qquad cwnd \ge ssthresh$$ so rounds 7, 8 and 9 carry windows of $\boxed{33,\ 34\text{ and }35\text{ MSS}}$. The change of gear is the whole point of the threshold: exponential growth probes for the available capacity quickly when the sender knows nothing, and linear growth takes over once the window is near the level that previously caused trouble.
3. Part (d) — a loss in the fourth window. The first four windows are unchanged at 1, 2, 4 and 8 MSS. A segment of the fourth window is not acknowledged, and because the loss is detected by the retransmission timer expiring rather than by duplicate acknowledgements, the sender treats it as evidence of serious congestion. It records half of the window in flight as the new threshold and collapses the window to one segment: $$ssthresh_{new} = \frac{cwnd}{2} = \frac{8}{2} = 4\text{ MSS}, \qquad cwnd = 1\text{ MSS}$$ so $\boxed{ssthresh = 4\text{ MSS}}$ and slow start begins again.
4. Restart and re-converge. Slow start now doubles from 1 to 2 to 4 MSS in rounds 5, 6 and 7, at which point $cwnd = 4 = ssthresh$ and congestion avoidance resumes, giving 5, 6 and 7 MSS in rounds 8, 9 and 10. The window therefore follows $\boxed{1,2,4,8 \rightarrow 1,2,4 \rightarrow 5,6,7\text{ MSS}}$, the characteristic TCP sawtooth.
5. The features on display. The trace exercises every mechanism the question asks to be illustrated: slow start (exponential probing from one segment), the slow-start threshold as the memory of the last congestion event, congestion avoidance (additive increase), multiplicative decrease on loss, and the loss-detection path itself. It is worth adding that a modern Reno or CUBIC sender reaching the same loss through three duplicate acknowledgements would use fast retransmit and fast recovery instead: it would set $ssthresh = 4$ as above but resume at $cwnd = 4$ rather than 1, because duplicate acknowledgements prove that segments are still leaving the network. The drop all the way to one segment shown here is the timeout behaviour that the question specifies.