Question 1 of 5: Transport Layer Protocols

Question 1: 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 downloading executables (5 marks)

TCP is the correct choice, and the reason is that an executable file has no error tolerance whatsoever. A single bit delivered wrongly, a single 1500-byte segment lost, or two segments delivered out of order will produce a binary that either refuses to run or, worse, runs and misbehaves. TCP supplies exactly the four properties that failure mode demands: a checksum on every segment, cumulative acknowledgment with retransmission of anything unacknowledged, sequence numbers that let the receiver restore the original byte order regardless of the order of arrival, and a connection teardown that tells the application the transfer is complete rather than merely stalled.

UDP supplies none of these. It offers a checksum that is optional in IPv4 and no recovery mechanism at all: a datagram that is dropped by a congested router is simply gone, and the application would have to re-implement sequence numbering, timers, retransmission and duplicate suppression in order to make the download safe. Doing so is not merely wasted effort; an application-level reinvention almost never gets the timer estimation and the congestion response right, which is the second argument for TCP.

That second argument matters as much as reliability. A file download is elastic traffic — it has no deadline and it wants whatever capacity happens to be free — and TCP's congestion control is precisely the mechanism that lets it take that capacity without collapsing the network or starving competing flows. UDP would send at whatever rate the application chose, which is antisocial on a shared path and is why the Internet's bulk transfer protocols (HTTP, FTP, SFTP, BitTorrent's data channel over µTP) are all built on reliable, congestion-controlled transports.

The classic case for UDP — small request/response exchanges such as DNS, or real-time media where a late packet is as useless as a lost one and retransmission would only add delay — simply does not arise here. The download is large, it is not delay-sensitive, and it must be bit-exact. TCP it is.

Part (b) — Why end-to-end congestion control is necessary (5 marks)

Congestion arises whenever the traffic arriving at a router exceeds the capacity of the outgoing link, and in a large wired network the two ends of a connection have no way to know in advance where that mismatch will occur. The path is chosen hop by hop by routing protocols the end systems never see; the bottleneck may be ten hops away, may change when a link fails, and is shared with an unknown number of other flows whose demand varies second by second. Only the end systems observe the outcome — acknowledgments that arrive, are delayed, or never arrive at all — so only the end systems can adapt the offered rate to what the path will actually carry.

A concrete example. A workstation on a 1 Gb/s campus LAN opens a TCP connection to a server reached over a 10 Mb/s leased line; the router where the LAN meets the leased line has a 100-packet output queue and packets are 1500 bytes. The sender can emit 1 Gb/s and nothing at the link layer tells it not to. Suppose it transmits for 100 ms without restraint:

1. Count what is offered. In 100 ms the source can put $R_{\text{LAN}} \times t = 1000\ \text{Mbit/s} \times 0.100\ \text{s} = 100\ \text{Mbit}$ into the network.
2. Count what can leave. Over the same 100 ms the bottleneck drains $R_{\text{WAN}} \times t = 10\ \text{Mbit/s} \times 0.100\ \text{s} = 1\ \text{Mbit}$.
3. The difference has to go somewhere. The backlog is $100 - 1 = 99\ \text{Mbit}$, which at 1500 bytes per packet is $\boxed{99\times10^{6}/12\,000 \approx 8\,250\ \text{packets}}$ offered to a queue that holds 100.

Better than 98 per cent of the burst is discarded. Because the loss is bulk and indiscriminate, it falls on other flows crossing the same router as much as on this one; those flows time out and retransmit, adding to the load, and the useful throughput of the link falls even as the offered load rises. That is congestion collapse, first observed on the NSFNET backbone in 1986 and the reason TCP acquired congestion control at all.

End-to-end control breaks the cycle by making the sender infer the bottleneck rate rather than assume it. The sender probes upward — slow start, then congestion avoidance — treats a loss as the signal that it has found the limit, and backs off. Within a few round trips the 1 Gb/s source settles at a window of roughly the bandwidth-delay product of the 10 Mb/s path, delivering close to 10 Mb/s of goodput with a nearly empty queue. Note also what a purely local, hop-by-hop scheme cannot do here: a datagram network keeps no per-flow state in its routers, so a router that is overrun has no one to push back on except by dropping. The intelligence has to live at the edges, which is exactly the end-to-end argument on which the Internet architecture rests.

Part (c) — Why TCP is suboptimal over a wireless link (5 marks)

TCP contains one deeply embedded assumption: a lost segment means the network is congested. That inference is sound on a wired path, where fibre and copper bit-error rates are of order $10^{-12}$ and essentially every loss really is a full buffer. On a wireless link it is false. Multipath fading, shadowing, interference from co-channel devices and handover between access points routinely produce frame error rates of a few per cent, and none of those losses says anything about the state of any queue.

The consequence is a wrong response to a correctly detected event. When a fade destroys a segment, the right action is to retransmit it promptly at the same rate, because the path capacity has not changed. What TCP does instead is halve its congestion window (Reno) or collapse it to one segment and re-enter slow start (Tahoe, or any timeout). Throughput therefore falls sharply at exactly the moment the channel recovers, and it climbs back only over many round trips. Because fades recur, the sender can spend most of its life in recovery, and measured throughput over a lossy wireless link is often a small fraction of what the link could carry.

Three secondary effects make it worse. First, wireless round-trip times are variable — link-layer retransmission, scheduling and power-save cycles can add tens or hundreds of milliseconds — which inflates TCP's retransmission-timeout estimate and can also trigger spurious timeouts when a delayed acknowledgment is mistaken for a loss. Second, TCP's throughput scales roughly as $1/\sqrt{p}$ in the loss rate $p$, so a random loss rate of one per cent is enough to cap a long-haul connection at a few megabits per second regardless of the available bandwidth. Third, during a handover the path may change entirely, and the congestion window carried across is meaningless on the new path.

The standard remedies all work by hiding the non-congestive loss from TCP or by giving TCP a better signal: link-layer ARQ and hybrid ARQ (used by 802.11, LTE and 5G NR) retransmit locally within a few hundred microseconds so the loss never reaches the transport; split-connection and snoop-agent designs place a proxy at the base station that retransmits on the wireless leg while suppressing the duplicate acknowledgments; Explicit Congestion Notification lets routers signal congestion by marking rather than dropping, so a drop no longer has to carry that meaning; and delay-based or model-based controllers such as TCP Westwood, Vegas and BBR estimate the bottleneck rate from timing rather than from loss.

Part (d) — Window evolution from an initial window of 1 with a threshold of 64 (5 marks)

Given. Initial congestion window $\text{cwnd}_1 = 1$ segment; slow-start threshold $\text{ssthresh} = 64$ segments; every segment is acknowledged, so no loss occurs. One transmission round is one round-trip time, during which the whole current window is sent and acknowledged.

Find. The value of cwnd in each successive round, up to and past the threshold, with the growth law in each region identified.

Approach. Apply TCP's two growth rules in sequence — exponential (slow start) while $\text{cwnd} < \text{ssthresh}$, linear (congestion avoidance) once $\text{cwnd} \ge \text{ssthresh}$ — and tabulate the result.

1. Slow start doubles the window every round. Each acknowledgment increases cwnd by one segment, and a window of $w$ segments produces $w$ acknowledgments, so $\text{cwnd}_{n+1} = 2\,\text{cwnd}_n$ and hence $\text{cwnd}_n = 2^{\,n-1}$.
2. Run it to the threshold. Substituting $n = 1, 2, \ldots, 7$ gives $1, 2, 4, 8, 16, 32, 64$, so the window reaches $\boxed{\text{cwnd}_7 = 64 = \text{ssthresh}}$ at the seventh round. The seven slow-start rounds have delivered $2^{7}-1 = 127$ segments in total.
3. Congestion avoidance takes over. Once $\text{cwnd} \ge \text{ssthresh}$ the sender raises the window by one segment per round trip — each acknowledgment adds $1/\text{cwnd}$ — so $\text{cwnd}_{n+1} = \text{cwnd}_n + 1$, giving $\boxed{65, 66, 67, \ldots}$ in rounds 8, 9, 10.

Written out, the trace the examiner is looking for is:

The point of the threshold is that exponential growth is a fast way to find the operating point but a dangerous way to sit near it: doubling from 64 would overshoot the path capacity by 64 segments in a single round trip, whereas adding one segment per round trip probes the last few per cent gently. This is the “additive increase” half of TCP's additive-increase / multiplicative-decrease control law.

Part (e) — The same trace with a loss in the fourth window (5 marks)

Given. The part (d) scenario — $\text{cwnd}_1 = 1$, $\text{ssthresh} = 64$ — except that one segment in the fourth transmission round is not acknowledged and the loss is detected by retransmission timeout, so TCP re-enters slow start.

Find. The window trace through the loss and the recovery, showing every feature of TCP's congestion control that the event exercises.

Approach. Identify the window in force when the loss occurs, apply the multiplicative-decrease rule to obtain the new threshold, restart slow start from one segment, and continue with the two growth laws of part (d).

1. Locate the loss. The first four windows are $1, 2, 4, 8$, so the loss occurs while $\boxed{\text{cwnd} = 8}$ segments are outstanding. The receiver acknowledges the segments it does get, but the missing one leaves a gap, and after one retransmission timeout the sender concludes the network is congested.
2. Multiplicative decrease sets the new threshold. TCP halves the window in force at the loss and remembers it: $\text{ssthresh}_{\text{new}} = \max\!\left(\dfrac{\text{cwnd}}{2},\, 2\right) = \max\!\left(\dfrac{8}{2},\, 2\right) = \boxed{4\ \text{segments}}$.
3. A timeout collapses the window. Because the loss was detected by timeout rather than by three duplicate acknowledgments, the sender sets $\text{cwnd} = 1$ and re-enters slow start — an eightfold reduction in the sending rate in a single round trip — and retransmits the missing segment.
4. Slow start runs to the new threshold. Doubling from 1 gives $1, 2, 4$, and $\text{cwnd} = 4 = \text{ssthresh}_{\text{new}}$ ends the exponential phase after only three rounds.
5. Congestion avoidance resumes. From there the window grows by one segment per round trip: $\boxed{5, 6, 7, 8, \ldots}$, so it takes four further round trips merely to regain the window the connection had before the loss.

The trace exhibits every feature the question asks to be illustrated: slow start (exponential opening, twice), the slow-start threshold as the boundary between the two growth laws, congestion avoidance (additive increase), multiplicative decrease on detecting loss, and the timeout that distinguishes TCP Tahoe's full collapse from Reno's fast retransmit and fast recovery. Had the same loss been signalled by three duplicate acknowledgments instead, Reno would have halved cwnd to 4 and continued in congestion avoidance without the collapse to 1, and the connection would have regained its throughput in one round trip rather than seven — which is precisely why fast recovery was added.