22-Elec-B4 Information Technology Networks · December 2016
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
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 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.
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.
| Quantity | Result |
|---|---|
| Phase rule below the threshold | Slow start: window doubles each round-trip time |
| Phase rule at or above the threshold | Congestion avoidance: window grows by 1 segment per round-trip time |
| Part (c): windows 1–10, no loss | 1, 2, 4, 8, 16, 32, 33, 34, 35, 36 |
| Round trips to reach the threshold of 32 | 5 (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 3 | 1, 2, 4, 1, 2, 3, 4, 5 |
| Alternative under TCP Reno fast recovery | 1, 2, 4, 2, 3, 4, 5, 6 |