Questions: TCP Flow Control and Congestion Control

Question 1

A server is sending data to a fast client over a congested network link. The client's receive buffer is nearly empty and rwnd is large, but packets are being dropped at an intermediate router. Which mechanism is currently limiting the transmission rate?

• A. Flow control — the receive window is the bottleneck because the client is processing data slowly
• B. Congestion control — the congestion window is limiting transmission because loss signals network congestion
• C. Both equally — TCP always takes the maximum of rwnd and cwnd to set the sending rate
• D. Neither — TCP retransmits dropped packets automatically without adjusting the sending rate

Answer: (B)

The effective sending rate is the *minimum* of rwnd and cwnd. Here, rwnd is large (fast client with empty buffer) but packets are dropping at the network — a congestion signal. TCP interprets loss as congestion and shrinks cwnd accordingly. Flow control is not the constraint because the receiver's buffer is healthy; the network is the bottleneck. Option C gets the formula backwards — TCP uses the minimum, not maximum. Option D is wrong: TCP does retransmit but *also* reduces cwnd to relieve congestion, which is precisely the point of congestion control.

Question 2

Why does TCP Slow Start use exponential rather than linear window growth at the beginning of a connection?

• A. Exponential growth wastes less time reaching the available bandwidth without staying cautiously slow for too long
• B. Linear growth would immediately cause congestion by exceeding network capacity
• C. The TCP specification requires exponential growth for historical backward-compatibility reasons
• D. Exponential growth allows the sender to detect packet loss faster than linear growth

Answer: (A)

Slow Start is called 'slow' because it begins with a small cwnd (1–2 segments) rather than immediately sending at maximum. But exponential doubling quickly probes available bandwidth — within a few RTTs, cwnd reaches the available capacity. Linear growth from a small initial value would take far longer to reach a useful sending rate, wasting time. The name is somewhat misleading: Slow Start starts slowly but scales up fast. Once cwnd reaches ssthresh (the estimated capacity threshold), the algorithm switches to linear congestion avoidance to probe more cautiously.

Question 3

Flow control and congestion control are redundant mechanisms — either one alone is sufficient to prevent packet loss in any real network scenario.

• T. True
• F. False

Answer: False

They solve fundamentally different problems and protect different resources. Flow control protects the *receiver's buffer* using the explicitly advertised rwnd — it prevents the sender from overwhelming a slow receiver. Congestion control protects the *network* using the inferred cwnd — it prevents the sender from overwhelming intermediate routers. A fast receiver with a large buffer provides no flow control constraint, yet the network can still congest. Conversely, a slow receiver constrained by rwnd still needs congestion control on the sender's side to avoid filling router queues. Each mechanism can be the binding constraint independently.

Question 4

The effective TCP sending rate is governed by the minimum of the receive window (rwnd) and the congestion window (cwnd).

• T. True
• F. False

Answer: True

This is the fundamental rule that unifies flow control and congestion control. The amount of data TCP can have unacknowledged in flight cannot exceed either limit. If rwnd = 64KB and cwnd = 32KB, the network is the bottleneck and the sender is limited to 32KB in flight. If rwnd = 16KB and cwnd = 64KB, the receiver is the bottleneck and the sender is limited to 16KB in flight. Both windows are enforced simultaneously, and whichever is smaller determines the actual sending rate. This is why both mechanisms can independently limit throughput.

Question 5

Why does TCP interpret packet loss as a signal of network congestion, and why might this assumption break down in modern networks?

Model answer: TCP was designed when networks were simple and nearly all packet loss was caused by router buffer overflow — a direct indicator of congestion. Loss-based algorithms like Reno and Cubic treat any loss event as a congestion signal and reduce cwnd. This assumption breaks down in wireless networks, where packet loss often occurs due to noise, interference, or fading rather than congestion. If TCP misinterprets wireless loss as congestion, it unnecessarily reduces its sending rate even though the network has available capacity. BBR addresses this by estimating bottleneck bandwidth and minimum RTT directly rather than inferring congestion from loss.

The core issue is that loss is an imperfect proxy for congestion — it was a good proxy on wired 1980s networks but not on modern heterogeneous networks. A deeper problem is that loss-based algorithms fill router queues before detecting congestion, causing high latency before any loss occurs (bufferbloat). BBR's approach of directly estimating capacity represents a more fundamental departure: instead of asking 'did anything go wrong?', it asks 'how much capacity actually exists?'