optional · CSS study notes
Congestion Avoidance
🧭
On this page — click any heading below to jump straight to it. ⬅️ Back to P-II.II. Computer Communications & Networks
OSI Layer: Transport Layer (L4)
Definition
Congestion control is a set of mechanisms that prevent a sender from injecting more data into the network than the network's routers/links can carry, which would otherwise cause queue overflow, packet loss, and a collapse in overall throughput. It is distinct from flow control, which protects only the receiver's buffer, not the shared network.
Flow Control vs Congestion Control
| Basis | Flow Control | Congestion Control |
|---|---|---|
| Protects | The receiver (its buffer) | The network (routers/links in between) |
| Limit imposed by | Receiver's advertised window size | Sender's inferred congestion window (cwnd) |
| Signal used | Explicit window value in ACK | Inferred from packet loss / delay / duplicate ACKs |
| Effective window | — | min(cwnd, receiver's advertised window) |
Types / Phases of TCP Congestion Control
- Slow Start:
cwndbegins at an initial window determined by the implementation/standard and grows roughly exponentially per RTT (exponential growth) until it reaches a thresholdssthresh, or a loss occurs. Despite the name, growth is fast — "slow" only refers to starting from a small window rather than flooding the network immediately. - Congestion Avoidance: once
cwndpassesssthresh, growth switches to linear, additive increase (roughly +1 segment per RTT) to probe for more bandwidth cautiously rather than exponentially. - Multiplicative Decrease (on loss via timeout):
cwndis reset all the way back to 1 segment andssthreshis set to half the previouscwnd; slow start resumes from scratch — a drastic, conservative response to a serious congestion signal (timeout). - Fast Retransmit / Fast Recovery (classic Reno): three duplicate ACKs trigger retransmission, a reduced threshold and temporary window inflation during recovery. After recovery, the window is reduced to the threshold and congestion avoidance resumes. This differs from the more severe timeout response.
- Together, the additive-increase/multiplicative-decrease cycle is called AIMD, producing the characteristic TCP sawtooth graph of
cwndover time.
Congestion Control Approaches (broader classification)
- End-to-end congestion control: the network layer provides no explicit feedback; the transport layer (TCP) infers congestion purely from observed loss and delay at the endpoints. The Internet also supports network-assisted feedback such as ECN.
- Network-assisted congestion control: routers provide explicit feedback to the endpoints about congestion state, e.g., via a bit in the packet header.
- Choke packets: a congested router directly signals the source to reduce its sending rate.
- Explicit Congestion Notification (ECN): routers mark packets (rather than dropping them) as they approach congestion, letting endpoints react before loss actually occurs.
Numericals
Q1 — Slow start growth
cwnd starts at 1 MSS, ssthresh = 16 MSS. Assuming no loss, cwnd doubles each RTT.
- RTT1: 1 → RTT2: 2 → RTT3: 4 → RTT4: 8 → RTT5: 16 (= ssthresh, switches to congestion avoidance)
- Starting at time 0 with 1 MSS, the window reaches 16 MSS after 4 elapsed RTTs: 1 → 2 → 4 → 8 → 16. Five values are shown, not five elapsed doubling intervals.
Q2 — AIMD after a timeout
cwnd = 32 MSS when a timeout occurs.
- New
ssthresh= 32 ÷ 2 = 16 MSS - New
cwndresets to 1 MSS, slow start resumes up to 16, then congestion avoidance (linear +1/RTT) continues from there.
Q3 — AIMD after 3 duplicate ACKs (fast recovery)
cwnd = 32 MSS when 3 duplicate ACKs are received (not a timeout).
- New
ssthresh= 32 ÷ 2 = 16 MSS - Assuming flight size is 32 MSS, the new threshold is 16 MSS. In Reno, cwnd is temporarily inflated to threshold + 3 MSS on the third duplicate ACK, increases with further duplicate ACKs, and returns to the threshold when the recovery ACK arrives. Congestion avoidance resumes after recovery; it is not simply an immediate jump to 16 MSS.
CSS Exam Angle
- A graph question is very common: sketch
cwndvs time showing the sawtooth AIMD pattern, marking the exponential slow-start ramp and the linear congestion-avoidance climb, with a sharp drop at each loss event. - Clearly distinguish flow control vs congestion control first — this is the single most common examiner trap on this topic.
- Explicitly separate the two different reactions to loss: full reset after timeout vs halving after 3 duplicate ACKs (fast recovery) — this level of detail separates a top answer from an average one.
- Mention end-to-end vs network-assisted control as the broader theoretical classification if the question asks generally about "congestion control approaches" rather than specifically about TCP.
Example
When an undersea cable is cut and international bandwidth drops sharply, TCP senders worldwide detect increased packet loss and back off via AIMD (dropping cwnd, re-growing slowly), which is why sudden global link failures cause a visible, temporary slowdown rather than a total collapse — congestion control is precisely what keeps the network usable during such events.
Likely Questions
- Explain TCP's congestion control mechanism, distinguishing it from flow control.
- Describe slow start and congestion avoidance with a labelled graph of
cwndover time. - How does TCP's response to a timeout differ from its response to three duplicate ACKs?
- Differentiate end-to-end and network-assisted congestion control approaches.
📜 Past-Paper Questions & Structured Answers
Questions are paraphrased; answer focus is suggested guidance, not an official marking scheme.
2026 · Paper-II · Q4 · 20 marks
Question (paraphrased): Analyse TCP’s congestion strategies, contrast UDP, and explain consequences for network stability.
Answer focus: Suggested balance: problem/distinctions 2; TCP mechanisms 8; UDP comparison 4; stability/example/evaluation 6. This is a study allocation, not FPSC’s official rubric.
1. Congestion and the control problem
Congestion occurs when offered traffic persistently exceeds a bottleneck’s service capacity. Queues grow, delay and jitter increase, buffers overflow, and packets are lost. Repeated retransmissions can consume capacity without increasing successfully delivered data, reducing useful throughput or goodput.
Congestion control protects the network; flow control protects the receiver. TCP’s congestion window (cwnd) limits traffic in flight according to network conditions, while the advertised receive window (rwnd) limits it according to available receive space. Outstanding data is constrained by approximately min(cwnd, rwnd). A receiver with free memory can still sit behind a congested link.
2. TCP’s feedback loop
TCP uses ACK arrivals to pace progress and uses loss, timeouts or explicit signals to infer congestion. Its aim is to discover available capacity while backing off when a path cannot support the offered load. The classic exam model is TCP Reno; modern variants do not all use precisely the same window-growth rule.
| Mechanism | Behaviour | Purpose / consequence |
|---|---|---|
| Slow start | The window grows roughly exponentially per RTT while ACKs acknowledge new data, until a threshold or congestion signal | Quickly discovers available capacity, but can overshoot it |
| Congestion avoidance | Reno increases the window by roughly one MSS per RTT | Probes for extra capacity more cautiously |
| Fast retransmit | Three duplicate ACKs commonly trigger retransmission of a suspected missing segment | Repairs loss without waiting for a timeout |
| Fast recovery | Reno reduces its target window after loss and manages ACKs during recovery | Avoids returning to the smallest window for every isolated loss |
| Retransmission timeout | Retransmit, reduce the threshold and restart conservatively; back off the timer | Responds more strongly when ACK progress stops |
The initial window is not universally one MSS; it depends on the applicable standard and implementation. In the classic timeout response, cwnd falls to one MSS. Slow-start threshold is based on flight size, with a lower bound; “halve the current window” is a teaching approximation. Fast recovery temporarily inflates the window during duplicate ACKs, then deflates it when recovery completes. Classic mechanisms: RFC 5681
3. Worked illustration and interpretation
Assume a simplified Reno sender has cwnd=16 MSS, sufficient rwnd and one ACK per segment. During congestion avoidance, successive rounds might allow approximately 16, 17, 18 and 19 MSS. If a loss is detected through duplicate ACKs at flight size 20 MSS, the new threshold is roughly 10 MSS. After recovery, cautious growth resumes near that level. If instead a retransmission timeout occurs, the response is more severe and slow start resumes from one MSS.
This is the familiar additive increase / multiplicative decrease pattern: gradual exploration followed by a substantial reduction. It permits sharing among responsive senders, but exact fairness depends on RTTs, algorithms, packet sizes and network scheduling. It is not a universal equal-bandwidth guarantee.
4. UDP’s limitations and appropriate use
UDP provides datagrams, ports and a checksum, but no built-in ACK-based congestion window, retransmission, ordered delivery or receiver flow control. Its sending rate is determined by the application or a protocol above it. A constant-rate UDP sender may continue sending into a full queue while TCP senders back off, increasing delay and loss and taking an unfair share.
This does not mean every UDP application is uncontrolled. Real-time applications can adapt codec bitrate or packet rate based on feedback; QUIC implements reliable streams and congestion control over UDP. DCCP is a separate transport protocol, not merely a UDP application. UDP’s suitability for interactive media comes from giving the application control over deadlines and recovery, not from guaranteed speed. UDP application responsibilities
5. Why transport choices affect the whole network
Consider a hypothetical 10 Mbps bottleneck. An unresponsive application sends 8 Mbps while other users collectively request 8 Mbps. The 16 Mbps offered load cannot fit: queues or losses grow. If only the TCP users reduce their demand, the unresponsive sender can dominate. If all senders react appropriately and the router applies fair scheduling, offered load can approach usable capacity without continually overwhelming buffers. Exact shares depend on implementation; this is an illustration, not a guaranteed allocation.
Transport decisions also influence burstiness and retransmission load. Overly aggressive recovery wastes bandwidth; excessively conservative control underuses capacity. Large buffers may hide loss while creating long delays (bufferbloat). Active queue management and ECN can signal congestion before severe overflow, while pacing can smooth bursts. Modern approaches such as CUBIC and BBR reflect different capacity-probing choices; no algorithm is ideal for every path.
6. Evaluation and conclusion
TCP’s feedback-based mechanisms make reliability compatible with shared-network operation, but wireless loss, unequal RTTs and competing controllers complicate performance. UDP is useful when applications need message boundaries or deadline-aware recovery, provided congestion response is supplied elsewhere. Network stability therefore depends on the behaviour of all offered traffic, supported by router queue management and capacity planning, rather than on reliability alone.
Exam checklist: define congestion; distinguish cwnd/rwnd; explain slow start, avoidance, fast retransmit/recovery and timeout; contrast UDP; show an example; discuss fairness and stability. A generic TCP-versus-UDP table does not answer the full question.