SubnetLayer

Congestion Control

Slow start, fast retransmit, and why the whole Internet doesn't melt

Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.

What you'll be able to do

Before this lesson — it builds directly on:
Flow control protects the computer at the other end. But nothing so far protects the *network in between* — the routers whose queues fill up when everyone sends at once. In 1986 the early Internet discovered what happens without that protection: throughput collapsed to a fraction of capacity while traffic kept rising, because every lost packet was met with more sending. Congestion control is the fix: each sender keeps a private guess about how much the path can carry, raises it while things arrive, and cuts it hard when they don't.

✗ Common misunderstanding: Flow control and congestion control are two names for the same thing.

Why that's wrong: They protect different victims with different mechanisms. Flow control protects the RECEIVER's buffer using the advertised window; congestion control protects the NETWORK using the sender's private cwnd.

Correct model: Two independent brakes, always both active. The sender may have min(rwnd, cwnd) bytes in flight.

The packets prove it: In the rwnd-limited scenario cwnd is large but the 4 KB advertised window is the binding limit; in the congestion-collapse scenario the window is huge and the network is the problem.

Watch these fields in the lab: tcp.windowSize

rwnd — receive windowglossary
The receiver's advertised free buffer space. Visible in every packet.
cwnd — congestion windowglossary
The sender's private estimate of what the network can carry. Never transmitted.
Send limit
min(rwnd, cwnd) — the tighter of the two brakes wins, always.
FlightSize
Data sent but not yet cumulatively acknowledged. This is what the send limit constrains.
ssthreshglossary
The threshold where growth changes from exponential (slow start) to linear (congestion avoidance).
Effective send windowThe sender is limited by two independent things: the receiver's advertised window, which protects the receiver's buffer, and the congestion window, which is the sender's own estimate of what the network can carry. The amount that may be in flight is the smaller of the two.rwnd — receiver's advertised window64 KBprotects the receiver's buffer · sent in every packetcwnd — sender's congestion window14 KBprotects the network · never on the wireeffective limit = min(rwnd, cwnd)14 KBthe smaller one wins — here, congestion controlOnly rwnd is visible in a capture. cwnd is inferred from how much is actually in flight.
Two brakes, always both active. Flow control protects the RECEIVER; congestion control protects the NETWORK. The effective limit is min(rwnd, cwnd).

Watch these fields in the lab: tcp.windowSize

✓ Concept check — before you open the packets

These test the idea, not the trace. You should be able to answer them from the explanation above.

rwnd is 64 KB and cwnd is 8 KB. How much unacknowledged data may the sender have in flight?

Why does TCP react more gently to loss detected by three duplicate ACKs than to loss detected by a timeout?

Now that you understand the concept, observe how it appears in the packet exchange.

The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.