22-Elec-B4 Information Technology Networks · December 2018

Question 3 of 5: Transport Layer Protocols

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

Question 3: 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 streamed video over a mobile link (5 marks)

UDP, with loss concealment and rate adaptation supplied by the application. Streamed video is delay-sensitive and loss-tolerant: a frame that arrives after its playout instant is worthless even if it is perfect, whereas a frame with a few missing macroblocks is concealed by the decoder and the viewer barely notices. TCP's reliability is bought with retransmission and in-order delivery, so a single lost segment stalls delivery of every later segment until the retransmission arrives — exactly the head-of-line blocking that empties a playout buffer — and TCP's congestion control halves the sending rate on a loss that, over a mobile link, was probably caused by fading rather than by congestion.

UDP with RTP over it gives the application timestamps and sequence numbers so it can order and time packets itself, drop what is late, conceal what is missing, and choose its own rate-adaptation policy. The honest caveat is that this is a design decision rather than a rule: streaming over HTTP, and therefore over TCP, dominates commercial video distribution because a large client-side buffer of several seconds hides the retransmissions and TCP passes through firewalls and NATs that block UDP. The distinction is between interactive or tightly buffered video, where UDP is clearly right, and pre-buffered on-demand video, where TCP is acceptable. In an exam answer, state the choice, the reason, and the condition under which the other choice becomes reasonable.

Part (b) — How congestion turns into loss on a wired network (5 marks)

A packet switch is a statistical multiplexer with finite memory. Each output port is served at the line rate of its link, and packets destined for that port that arrive faster than the line rate are stored in the port's queue. Congestion means precisely that the aggregate arrival rate for some output exceeds its service rate, so the queue grows; and because the buffer is finite, once it is full the only thing the switch can do with the next arrival is discard it. Wired links themselves are extremely reliable — a modern fibre or copper Ethernet link has a bit-error ratio around $10^{-12}$ or better — so essentially every packet lost in a wired network is a packet that a router deliberately dropped for want of buffer space, not one corrupted in transit. That is the reasoning behind TCP's central assumption: a loss is a congestion signal.

Part (c) — Window evolution with no losses (5 marks)

Given. A TCP connection with initial congestion window $cwnd_1 = 1$ segment (measured in maximum segment sizes, MSS) and slow-start threshold $ssthresh = 16$ segments. Every segment sent is acknowledged, and the window is examined once per round-trip time.

Find. The value of $cwnd$ in each successive round, both while the window is below the threshold and after it has passed it.

Approach. Apply the two growth laws in turn: exponential doubling per round-trip while $cwnd$ is below $ssthresh$ (slow start), and an increase of one segment per round-trip once it reaches $ssthresh$ (congestion avoidance).

1. Slow start — double each round-trip. In slow start the sender adds one MSS for every acknowledgement received, and it receives $cwnd$ acknowledgements per round, so the window doubles: $$cwnd_{k+1} = 2\,cwnd_k \quad (cwnd_k \lt ssthresh)$$ Starting at 1 this gives rounds 1 to 5 as $1,\,2,\,4,\,8,\,16$ segments. Slow start is exponential despite its name; what is slow is the starting point, not the growth.
2. Reach the threshold and change gear. At round 5 the window equals $ssthresh = 16$, so the sender leaves slow start and enters congestion avoidance. Cumulatively it has delivered $1+2+4+8+16 = 31$ segments in five round-trips.
3. Congestion avoidance — add one segment per round-trip. Above the threshold the sender adds $MSS/cwnd$ per acknowledgement, hence one MSS per round: $$cwnd_{k+1} = cwnd_k + 1 \quad (cwnd_k \ge ssthresh)$$ so rounds 6 to 9 give $17,\,18,\,19,\,20$ segments. The full sequence is therefore $$\boxed{cwnd = 1,\,2,\,4,\,8,\,16,\,17,\,18,\,19,\,20\ \text{segments in rounds } 1\ldots9}$$ and it continues to grow by one per round until a loss occurs or the receiver's advertised window caps it, since the sending window is always $\min(cwnd,\ rwnd)$.

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

Given. The connection of part (c), but a segment sent in the third window — the round in which $cwnd = 4$ — is not acknowledged, and the sender detects the loss by retransmission timeout, so TCP re-enters slow start.

Find. The window sequence after the loss, and the features of TCP that the sequence displays.

Approach. On a timeout, Tahoe-style TCP sets $ssthresh$ to half the window in flight, resets $cwnd$ to one segment, and repeats the slow-start then congestion-avoidance cycle against the new threshold.

1. Rounds 1 to 3 are unchanged. The window still evolves $1,\,2,\,4$; the loss happens inside the third window, so the damage is done with $cwnd = 4$ segments outstanding.
2. Detect the loss and back off multiplicatively. The missing acknowledgement lets the retransmission timer expire, which TCP reads as a congestion signal. It halves the threshold and restarts: $$ssthresh_{new} = \max\!\left(\frac{cwnd}{2},\,2\right) = \max(2,2) = 2\ \text{segments}, \qquad cwnd \leftarrow 1\ \text{segment}$$ The lost segment is retransmitted at this point, and the retransmission timer is doubled for the next attempt — Karn's algorithm plus exponential backoff.
3. Slow start again, against the lower threshold. Round 4 sends 1 segment and round 5 sends 2, at which point $cwnd = ssthresh = 2$ and the sender switches to congestion avoidance.
4. Congestion avoidance from the new threshold. Rounds 6 onwards add one segment per round: $3,\,4,\,5,\,6,\ldots$ The complete sequence is $$\boxed{cwnd = 1,\,2,\,4,\,1,\,2,\,3,\,4,\,5,\,6\ \text{segments in rounds } 1\ldots9}$$ Compared with part (c), the connection is at 6 segments in round 9 instead of 20 — the cost of one lost packet.

The example displays every mechanism the question asks to be illustrated: slow start (exponential growth from one segment), the slow-start threshold that ends it, congestion avoidance (additive linear growth), multiplicative decrease of the threshold to half the window in flight, loss as the congestion signal, and retransmission of the missing segment with timer backoff. It is worth adding that TCP Reno would behave differently had the loss been detected by three duplicate acknowledgements instead of a timeout: fast retransmit plus fast recovery would set $cwnd$ to the new $ssthresh$ of 2 rather than to 1, because the duplicate acknowledgements prove that packets are still flowing. A timeout, by contrast, is evidence that the pipe has emptied, which is why the window is reset all the way to one segment.

Part (e) — Why slow start performs badly over a wireless link (5 marks)

TCP's congestion control rests on the inference established in part (b): a lost packet means a full router queue. Over a wireless link that inference is false. A momentary fade, a burst of interference or a handover corrupts frames for a few tens of milliseconds and destroys packets while every queue in the path is empty and the bottleneck link is idle. TCP cannot tell the two causes apart — it sees only a missing acknowledgement — so it applies the congestion remedy to a non-congestion problem: it halves the threshold, drops the window to one segment, and rebuilds it over many round-trip times.

The performance loss compounds in three ways. The sender withdraws capacity precisely when the channel has recovered and is free, so the link runs far below its capability. Recovery is slow because it takes $\log_2(ssthresh)$ round-trips of slow start plus a linear climb thereafter, and a mobile round-trip time of 50–100 ms makes that a visible stall to a user. And because fades recur, the connection may be knocked back to one segment before it has recovered from the previous fade, so its average window — and hence its throughput, which is roughly $cwnd \cdot MSS / RTT$ — stays a small fraction of what the radio link could carry. The standard remedies all attack the same misdiagnosis: link-layer ARQ and hybrid ARQ hide short fades from TCP entirely, split-connection or performance-enhancing proxies terminate TCP at the base station, explicit loss notification tells the sender that a loss was not congestion, and modern congestion controllers such as BBR infer congestion from measured delay and delivery rate rather than from loss alone.