NivaarExam PrepOfficial exam papers ↗

22-Elec-B4 Information Technology Networks · December 2016

Question 3 of 5: The Transport Layer

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

Notes on this paper

Paper format. Professional Engineers of Ontario, Annual Examinations — December 2016, 07-Elec-B4 Information Technology Networks. Three hours, closed book, a PEO-approved non-programmable calculator permitted. Five questions of 25 marks each; any four constitute a complete paper worth 100 marks, and the marks are printed in the left margin against every sub-part. All five questions are solved here, because this set is a study resource rather than an exam attempt.

Reference texts.



Question 3: The Transport Layer (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) — why congestion control is necessary (5 marks). Because the links have different capacities, there is always some router at which the arrival rate can exceed the departure rate. A sender that transmits as fast as its own access link permits will therefore drive traffic into a router whose outgoing link is slower, and the difference accumulates in that router's buffer. The buffer is finite, so three things follow in sequence. First, the queue grows and the end-to-end delay grows with it, which is already a failure for interactive traffic. Second, the buffer fills and the router must discard arriving packets, so goodput falls even as offered load rises. Third — and this is the reason congestion control is necessary rather than merely desirable — the discarded packets are retransmitted, which increases the offered load still further, and the network can collapse into a state where nearly all the capacity of the upstream links is spent carrying packets that will be dropped downstream. This is congestion collapse, observed on the early Internet in 1986 and the direct cause of TCP's congestion-control mechanisms.

Flow control cannot substitute for it: flow control protects the receiver from being overrun by the sender and is negotiated end to end, whereas the resource being exhausted here belongs to a router in the middle that neither end can see. The sender must therefore infer the state of that hidden bottleneck — from loss, from delay, or from an explicit mark — and regulate itself accordingly.

Part (b) — TCP versus UDP (5 marks). TCP is connection-oriented and reliable: a three-way handshake establishes state at both ends, every byte is sequenced and acknowledged, lost segments are retransmitted, the byte stream is delivered in order and without duplication, and the sending rate is regulated by both flow control and congestion control. UDP is connectionless and unreliable: it adds only ports, a length and an optional checksum to IP, so datagrams may be lost, duplicated or reordered, and nothing throttles the sender. The trade is latency and control against reliability — TCP's retransmission and in-order delivery mean a single lost segment stalls everything behind it (head-of-line blocking), while UDP delivers what arrives, when it arrives, and leaves any recovery to the application.

Example applications: TCP carries a web page or a file transfer (HTTP over TCP, SFTP), where a single corrupted byte would ruin the object and a hundred milliseconds of delay would not be noticed. UDP carries a real-time voice or video call, or a DNS query (VoIP with RTP over UDP, DNS), where a late packet is worthless anyway so retransmitting it wastes capacity, and where a one-datagram exchange would spend more time on TCP's handshake than on the transaction itself.

Given. An initial congestion window of one segment, a slow-start threshold of 32 segments, and for part (d) a loss of an unacknowledged packet in the third transmission window; all other packets are acknowledged. Window sizes are expressed in segments (maximum segment sizes) and one window is sent per round-trip time.

Find. The evolution of the congestion window through and beyond the threshold (part c), and the congestion window for each of the first eight windows when the third one suffers a loss (part d).

Approach. Apply the two-phase rule of TCP congestion control — multiplicative increase while below the threshold (slow start), additive increase above it (congestion avoidance) — then apply the multiplicative decrease triggered by the loss and restart the same two-phase rule from the new threshold.

  1. Part (c) — state the rule that governs each phase. The sender maintains a congestion window cwnd and a slow-start threshold ssthresh. While $\text{cwnd} < \text{ssthresh}$ the connection is in slow start: each acknowledgement increases cwnd by one segment, so a whole window of acknowledgements doubles it, and the growth per round-trip time is $$\text{cwnd}_{k+1}=2\,\text{cwnd}_{k}\qquad(\text{slow start}).$$ Once $\text{cwnd}\ge\text{ssthresh}$ the connection enters congestion avoidance: the window grows by one segment per round-trip time, $$\text{cwnd}_{k+1}=\text{cwnd}_{k}+1\qquad(\text{congestion avoidance}).$$ The name “slow start” is historical — the phase is exponential and is slow only compared with the previous behaviour of opening the whole receiver window at once.
  2. Walk the window forward from cwnd = 1. With $\text{ssthresh}=32$, doubling from one segment gives $$1\rightarrow2\rightarrow4\rightarrow8\rightarrow16\rightarrow32,$$ so the threshold is reached in the sixth window, after five round-trip times. Each of these windows is sent in one round trip and fully acknowledged, which is what the question's “assuming all packets are acknowledged” guarantees.
  3. Continue past the threshold in congestion avoidance. From window 6 onwards the increase is linear: $$\boxed{\text{cwnd}=1,\,2,\,4,\,8,\,16,\,32,\,33,\,34,\,35,\,36,\ \ldots}$$ for windows 1 to 10. The sender has spent five round trips probing exponentially and thereafter adds a single segment per round trip, which is the “additive increase” half of TCP's additive-increase / multiplicative-decrease control law. Plotted, the trace is the familiar knee at the threshold shown below.
123456789109182736Transmission round (window)Congestion window (segments)cwnd, no loss
Part (c): congestion window with no loss. Exponential slow start doubles the window each round trip to the dashed threshold of 32 segments, after which congestion avoidance adds one segment per round trip.
  1. Part (d) — identify the window in which the loss occurs. The first three windows follow the slow-start sequence of part (c), so windows 1, 2 and 3 carry 1, 2 and 4 segments. The loss is in the third window, i.e. while $\text{cwnd}=4$.
  2. Apply the multiplicative decrease. A packet that is never acknowledged is detected by the retransmission timer expiring, and TCP's response to a timeout is to halve the threshold and restart from one segment: $$\text{ssthresh}_{\text{new}}=\frac{\text{cwnd at loss}}{2}=\frac{4}{2}=2\ \text{segments},\qquad \text{cwnd}_{\text{new}}=1\ \text{segment}.$$ Halving the threshold is the estimate of a safe operating point — the network was demonstrably unable to carry four windows' worth — and restarting at one re-probes the path conservatively.
  3. Re-run the two-phase rule from the new threshold. Window 4 carries 1 segment. Slow start doubles it, but the new threshold is only 2, so window 5 carries 2 segments and the connection is immediately in congestion avoidance; windows 6, 7 and 8 then add one segment each. The eight windows are therefore $$\boxed{\text{cwnd}=1,\,2,\,4,\,1,\,2,\,3,\,4,\,5\ \text{segments for windows }1\ldots8.}$$
  4. Sanity-check the shape of the answer. The trace must fall to 1 exactly once, must resume exponential growth for at most one step (because the new threshold is only one doubling away), and must then be linear with slope one. It reaches 4 again at window 7, three round trips after the loss, which is the throughput cost of a single timeout and the reason later TCP versions avoid the full restart wherever they can.
123456782468Transmission round (window)Congestion window (segments)cwnd, loss in window 3
Part (d): a loss in the third window (circled) triggers a timeout. The threshold drops to 2 segments (dashed) and the window restarts at 1, giving 1, 2, 4, 1, 2, 3, 4, 5 for the first eight windows.

Check: the exam text for part (d) says “the same setup as in part b”, but part (b) is the TCP-versus-UDP discussion and carries no window parameters; the intended reference is plainly part (c), whose initial window of 1 and threshold of 32 are the only setup on the page. Part (d) is answered on that reading. Two further modelling choices are stated openly: an unacknowledged packet is treated as a timeout (TCP Tahoe behaviour, cwnd back to 1), which is what “is not acknowledged” describes most directly. Had the loss instead been signalled by three duplicate acknowledgements, TCP Reno's fast recovery would halve the window without restarting, giving 1, 2, 4, 2, 3, 4, 5, 6 — a legitimate alternative answer if the fast-retransmit reading is stated.

Question 3 — final results
QuantityResult
Phase rule below the thresholdSlow start: window doubles each round-trip time
Phase rule at or above the thresholdCongestion avoidance: window grows by 1 segment per round-trip time
Part (c): windows 1–10, no loss1, 2, 4, 8, 16, 32, 33, 34, 35, 36
Round trips to reach the threshold of 325 (threshold reached in window 6)
New threshold after the loss (timeout at cwnd = 4)2 segments; window restarts at 1
Part (d): windows 1–8 with loss in window 31, 2, 4, 1, 2, 3, 4, 5
Alternative under TCP Reno fast recovery1, 2, 4, 2, 3, 4, 5, 6