22-Elec-B4 Information Technology Networks · May 2018

Question 2 of 5: Transport Layer Protocols — TCP, UDP and Congestion Control

Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)

Question 2: Transport Layer Protocols — TCP, UDP and Congestion Control (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 video streaming over a mobile wireless link? (5 marks)

For a real-time video stream over a mobile wireless link the right transport is UDP, with reliability and rate adaptation implemented in the application above it. The reasoning turns on the mismatch between what TCP guarantees and what video actually needs. Video is a continuous, delay-sensitive medium with a playout deadline: a frame that arrives after its scheduled display instant is worthless even if it is perfect, whereas a frame with a few corrupted macroblocks is still watchable and is concealed by the decoder. TCP inverts that priority. It will retransmit a lost segment as many times as necessary and will hold every subsequent, correctly received segment in the receive buffer until the gap is filled, so a single loss stalls delivery of data that has already arrived — the head-of-line blocking that the viewer experiences as a freeze.

The mobile wireless link sharpens the argument. Fading causes bursts of loss that have nothing to do with congestion, and TCP's congestion control interprets every loss as a signal to halve or collapse its sending rate, so the encoded bit rate the application can sustain fluctuates violently for reasons unrelated to network load (this is the subject of part (e)). UDP simply hands each datagram to the network and gets out of the way: the application, typically over RTP with RTCP feedback, decides what to do about loss — forward error correction, selective retransmission of reference frames only, or concealment — and adapts the encoder rate on its own timescale. It can also multicast, which TCP cannot.

The honest qualification, worth a sentence in an exam answer, is that most commercial streaming today is not real-time: services such as YouTube and Netflix use HTTP adaptive streaming (DASH or HLS) over TCP, buffering tens of seconds of video so that retransmission delay is hidden and the firewall-friendliness of TCP port 443 is gained for free. The choice therefore hinges on latency tolerance: buffered, on-demand video over TCP; conversational or live video, where the delay budget is a fraction of a second, over UDP.

Part (b) — Why congestion causes packet loss in wired networks (5 marks)

In a wired network the physical link is essentially error-free — a modern optical or twisted-pair link runs at a bit error rate of order $10^{-12}$ or better — so virtually no packet is lost to corruption. Loss happens inside the routers, and it happens because a router is a statistical multiplexer with a finite buffer.

A router accepts packets from several input links and forwards each one towards its destination on a chosen output link. Whenever the instantaneous arrival rate destined for a given output exceeds that output's transmission capacity, the surplus packets must wait in the queue serving that interface. Provided the overload is brief the queue absorbs it and the only cost is delay; that is exactly what the buffer is for. But the buffer holds a bounded number of bytes. If the arrival rate stays above the service rate the queue grows monotonically, reaches its limit, and every further arrival has nowhere to go: the router discards it. This is tail drop, and it is the ordinary mechanism of congestion loss.

Two refinements complete the picture. Modern routers often run active queue management — random early detection and its relatives — which deliberately drops (or ECN-marks) a randomly chosen packet once the average queue length passes a threshold, before the buffer is actually full. The purpose is to signal congestion to the sources early and to avoid the global synchronisation that occurs when a full buffer drops packets from many flows at once. Second, congestion loss is self-reinforcing without control: a dropped packet is retransmitted, adding still more load. That is why TCP treats loss as the congestion signal at all, and it is the design assumption that parts (c) to (e) explore.

Part (c) — Window evolution with every packet acknowledged (5 marks)

Given. A TCP connection with initial congestion window $\mathrm{cwnd}_1 = 1$ segment (MSS), slow-start threshold $\mathrm{ssthresh} = 32$ segments, and every transmitted segment acknowledged — no loss and no timeout.

Find. An explicit example of how the congestion window evolves, round by round, up to the threshold and beyond it.

Approach. Apply the two TCP window rules in turn: while $\mathrm{cwnd} \lt \mathrm{ssthresh}$ the connection is in slow start and the window doubles each round-trip time; once $\mathrm{cwnd} \ge \mathrm{ssthresh}$ it is in congestion avoidance and the window grows by one segment per round-trip time.

1. Apply the slow-start rule while below the threshold. In slow start the sender increases $\mathrm{cwnd}$ by one MSS for every acknowledgement received, so a window of $w$ segments that is fully acknowledged produces a window of $2w$ in the next round: $$\mathrm{cwnd}_{n+1} = 2\,\mathrm{cwnd}_n \quad \text{while } \mathrm{cwnd}_n \lt \mathrm{ssthresh}$$ Starting from one segment this gives the sequence 1, 2, 4, 8, 16, 32 over rounds 1 to 6 — that is, $\mathrm{cwnd}_n = 2^{\,n-1}$, exponential growth, which is what “slow start” unhelpfully names (it is slow only in its starting value, not in its rate of increase).
2. Switch to congestion avoidance at the threshold. Round 6 delivers $\mathrm{cwnd} = 32 = \mathrm{ssthresh}$, so the connection leaves slow start. Thereafter the sender increases the window by one MSS per round-trip time — implemented as an increase of $\text{MSS}/\mathrm{cwnd}$ per acknowledgement, which sums to one MSS over a full window: $$\mathrm{cwnd}_{n+1} = \mathrm{cwnd}_n + 1 \quad \text{while } \mathrm{cwnd}_n \ge \mathrm{ssthresh}$$ giving 33, 34, 35, … in rounds 7, 8, 9. This is the additive-increase half of TCP's additive-increase/multiplicative-decrease behaviour.
3. State the worked example. Collecting the two phases: $$\boxed{\,\mathrm{cwnd} : \underbrace{1,\ 2,\ 4,\ 8,\ 16,\ 32}_{\text{slow start (exponential)}},\ \underbrace{33,\ 34,\ 35,\ \ldots}_{\text{congestion avoidance (linear)}}\,}$$ Over these nine rounds the sender delivers $1+2+4+8+16+32+33+34+35 = 165$ segments.

Part (d) — The same example with a loss in the third window (5 marks)

Given. The connection of part (c) — initial window 1, $\mathrm{ssthresh}=32$ — but now a packet transmitted in the third window is not acknowledged, and TCP responds by entering slow start (the timeout, or Tahoe, response rather than fast recovery). The printed text says “repeat part b”; part (c) is the example intended, since part (b) contains no window.

Find. The window evolution after the loss, annotated with each of the TCP features it exhibits.

Approach. Identify the window size in round 3, apply multiplicative decrease to set the new threshold, restart the window at one segment, and then re-apply the slow-start and congestion-avoidance rules of part (c) to the new threshold.

1. Identify the window in which the loss occurs. From part (c) the rounds carry 1, 2 and 4 segments, so the third window contains $$\mathrm{cwnd}_{\text{loss}} = 4\ \text{segments}$$ One of those four segments is never acknowledged, so the retransmission timer for it expires.
2. Apply multiplicative decrease to the threshold. On a timeout TCP records half the window in flight as the new threshold, which is its estimate of the largest safe operating point: $$\mathrm{ssthresh}_{\text{new}} = \left\lfloor \frac{\mathrm{cwnd}_{\text{loss}}}{2}\right\rfloor = \frac{4}{2} = 2\ \text{segments}$$
3. Restart the window and grow again. A timeout in TCP Tahoe collapses the window to one segment and re-enters slow start, so $\mathrm{cwnd}$ becomes 1 in round 4, doubles to 2 in round 5 — at which point it has already met the new threshold — and then grows linearly: $$\boxed{\,\mathrm{cwnd} : 1,\ 2,\ \underbrace{4}_{\text{loss}},\ \underbrace{1,\ 2}_{\text{slow start}},\ \underbrace{3,\ 4,\ 5,\ 6,\ \ldots}_{\text{congestion avoidance}}\,}$$ Over the same nine rounds the sender now delivers only $1+2+4+1+2+3+4+5+6 = 28$ segments against 165 without the loss — a shortfall of 137 segments, which is the throughput cost of one lost packet.

The example displays, in order, every feature the question asks to be illustrated: slow start (the exponential opening, rounds 1–3 and again 4–5); the slow-start threshold as the boundary between the two growth laws; congestion avoidance (the linear phase from round 6); loss detection by retransmission timeout in round 3; multiplicative decrease of the threshold from 32 to 2; and the window collapse to one segment that defines the Tahoe response. It is worth adding what a modern stack would do instead: if the loss were detected by three duplicate acknowledgements rather than by a timeout, TCP Reno would perform fast retransmit and fast recovery, halving the window to 2 and continuing from there in congestion avoidance instead of dropping to 1. The distinction matters because it is the difference between losing one round-trip and losing several.

Part (e) — Why slow start performs poorly over wireless links (5 marks)

TCP's congestion control rests on one inference: that a lost packet means a full router queue. On a wired path that inference is sound, for the reason given in part (b) — the bit error rate is so low that congestion is essentially the only cause of loss. On a wireless link the inference is false. Momentary fading, shadowing, interference from other radios and handover between base stations all destroy packets while the network is completely uncongested, and TCP cannot tell the two causes apart because the only evidence it has is a missing acknowledgement.

The consequence is that a fade triggers the full congestion response even though the correct response would have been simply to retransmit. The threshold is halved and, on a timeout, the window collapses to one segment. The sender must then climb back — exponentially at first, but from a starting point of a single segment, and thereafter only one segment per round-trip time once the halved threshold is crossed. Recovering a window of $w$ segments takes roughly $\log_2(\mathrm{ssthresh})$ rounds of slow start plus $w - \mathrm{ssthresh}$ rounds of congestion avoidance, so on a link with a long round-trip time the recovery occupies many hundreds of milliseconds during which the radio channel — now perfectly healthy again — sits under-used. Fades recur on a timescale of tens of milliseconds, so the connection can be driven into a cycle in which it spends most of its life climbing back and never reaches the rate the link could actually support. The measured effect on cellular and satellite links is a throughput far below capacity, and it worsens as the bandwidth–delay product grows.

A secondary effect compounds it. Repeated timeouts cause exponential backoff of the retransmission timer, so the sender waits progressively longer before probing, and a link that has already recovered may remain idle for seconds. The standard remedies attack the false inference rather than the window algorithm: link-layer ARQ and hybrid ARQ hide residual radio errors from TCP altogether (this is what LTE and Wi-Fi both do); split-connection or performance-enhancing proxies terminate TCP at the base station; explicit congestion notification lets routers signal genuine congestion without dropping anything, so that a loss with no ECN mark is more plausibly a radio error; and loss-discrimination or delay-based congestion control — TCP Vegas, Westwood, and today BBR — infer congestion from round-trip time and delivery rate rather than from loss alone.