Question 4 of 5: Transport layer protocols

Question 4: 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 congestion window starts at $cwnd_0 = 1$ segment with a slow-start threshold of $ssthresh = 16$ segments, on a path where every segment is acknowledged and no segment is lost. Time is counted in round-trip times, and the window is expressed in maximum-segment-size units.

Find. The evolution of the congestion window round trip by round trip, up to the threshold and beyond it.

Approach. Apply the two growth laws of RFC 5681 in turn — multiplicative increase while $cwnd \lt ssthresh$, additive increase once $cwnd \ge ssthresh$ — and tabulate one row per round trip.

(a) Evolution of the congestion window

1. Part (a) — state the two growth rules. In slow start the sender increases $cwnd$ by one segment for every acknowledgement received, so a window of $w$ segments returns $w$ acknowledgements in one round trip and the window doubles: $$cwnd \leftarrow 2\,cwnd \qquad \text{while } cwnd \lt ssthresh$$ In congestion avoidance the increase is one segment per round trip, implemented as $cwnd \leftarrow cwnd + 1/cwnd$ per acknowledgement: $$cwnd \leftarrow cwnd + 1 \qquad \text{once } cwnd \ge ssthresh$$
2. Run the doubling until the threshold is reached. Starting from one segment, the window takes the values 1, 2, 4, 8, 16 over round trips 0 to 4. Growth is exponential in time even though it is called “slow” start — the name refers to starting from one segment rather than from the receiver’s advertised window, which is what the pre-1988 TCP did. By the end of round trip 4 the sender has delivered $1+2+4+8+16 = \boxed{31\ \text{segments}}$ and the window has reached the threshold of 16.
3. Switch to additive increase beyond the threshold. With $cwnd = ssthresh = 16$ the sender leaves slow start and adds one segment per round trip, giving 17, 18, 19, 20 over round trips 5 to 8: $$cwnd = \{1,\,2,\,4,\,8,\,16,\,17,\,18,\,19,\,20\}$$ The characteristic sawtooth follows: if a loss is now inferred from three duplicate acknowledgements at $cwnd = 20$, fast recovery halves the window to $ssthresh = cwnd/2 = 10$ and resumes congestion avoidance from there; a retransmission timeout instead resets $cwnd$ to 1 and restarts slow start with the halved threshold.

(b) Why TCP performs poorly when losses are caused by fading, not congestion

TCP’s congestion control rests on an inference that was sound when it was designed and is false on a radio link: that the network layer discards packets only when a queue overflows, so a lost segment means the path is congested. There is no other loss signal in the protocol, because the wired networks TCP grew up on had bit-error rates low enough that corruption was negligible. When the real cause of loss is a fade — a brief, purely local dropout of the radio channel with no queue anywhere near full — TCP applies the congestion remedy to a problem that is not congestion, and every step of the remedy is counterproductive.

The immediate cost is the reaction itself. A fade of a few tens of milliseconds destroys a handful of segments; TCP responds by halving the congestion window on a fast retransmit, or by collapsing it to one segment and re-entering slow start if the loss burst is long enough to lose the duplicate acknowledgements as well and force a retransmission timeout. The link, meanwhile, has recovered and is idle. Because congestion avoidance rebuilds the window by only one segment per round trip, the recovery from a single fade takes as many round trips as the window had segments — on a long path this is seconds of deliberate under-utilisation caused by a dropout that lasted milliseconds.

The damage compounds when fades recur, which is exactly what mobility produces. If the interval between fades is shorter than the time the window needs to climb back, the sender never reaches the window the link could support, and average throughput settles far below capacity: the connection spends its life on the rising edge of the sawtooth. Repeated timeouts also double the retransmission timer at each attempt, so after a burst the sender may sit silent for seconds while a perfectly good channel goes unused. Two further effects make it worse. The round-trip-time samples taken across a fade are wildly variable, which inflates the estimated deviation and therefore the timeout, and link-layer retransmission — the usual local fix — itself adds delay variation that TCP reads as more evidence of trouble. TCP is also unable to distinguish a loss from a long delay, so a link-layer recovery that takes longer than the timeout produces a spurious retransmission and a spurious window reduction on top of everything else.

The remedies all amount to keeping the wireless hop’s losses out of the end-to-end control loop, or telling the sender the truth about them: local link-layer retransmission with a tuned persistence (as in 802.11 and in radio-link protocols); split-connection or performance-enhancing proxies that terminate TCP at the base station; snoop agents that cache segments at the wireless edge and suppress the duplicate acknowledgements that would trigger a needless window reduction; selective acknowledgement so a burst of losses costs one recovery rather than several; and explicit loss notification or explicit congestion notification, which give the sender a signal that distinguishes corruption from queue overflow. Each attacks the same root cause — an inference that no longer holds.

(c) Two differences between TCP and UDP

The two protocols occupy the same layer and differ in what they promise. First, TCP is connection-oriented and reliable while UDP is connectionless and unreliable: TCP performs a three-way handshake, numbers every byte, acknowledges, retransmits what is lost and delivers the byte stream to the application in order and without duplicates, whereas UDP simply prepends an eight-byte header to a datagram and hands it to the network layer, with no handshake, no sequence numbers, no acknowledgement, no retransmission and no ordering guarantee. Second, TCP performs flow control and congestion control while UDP performs neither: a TCP sender is limited both by the receiver’s advertised window and by the congestion window of part (a), so it adapts its rate to the slowest element in the path, whereas a UDP sender transmits at whatever rate the application chooses and will happily overrun both the receiver and the network.

A third difference worth a sentence is that TCP is a byte-stream service with no message boundaries, so the receiver may read the data in units unrelated to the sender’s writes, while UDP preserves datagram boundaries exactly. The trade-off explains the division of labour in practice: file transfer, mail and the web use TCP because correctness matters more than delay, while real-time voice, video, DNS queries and network management use UDP because a late packet is worthless anyway and the application can do its own, lighter recovery.