Congestion Collapse

RFC 896 · the prophecy: a network drowning in its own retries

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

▸Watch a burst overflow a router queue — congestion loss with no villain
▸See an impatient timer resend data that wasn't lost, only slow
▸Follow duplicates crowding out fresh data: rising traffic, falling delivery
▸Name the two modern defences this trace is missing

Before this lesson — it builds directly on:

Reliability and congestion pull in opposite directions. A sender that loses a packet responds by sending it again — which is exactly right for that connection, and exactly wrong for a network that is dropping packets because it is already overloaded. If every sender does the correct thing, the offered load rises just as capacity is exhausted, causing more loss, causing more retransmission. The network ends up busy carrying copies of data it has already carried, and useful throughput falls toward zero. This isn't a hardware fault or a bug; it's a system of correct components producing a broken whole.

✗ 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.

✗ Common misunderstanding: A duplicate ACK always means a packet was lost.

Why that's wrong: It means data arrived OUT OF ORDER. Reordering on the path produces the same signal, which is why TCP waits for three duplicates before concluding loss.

Correct model: One or two duplicate ACKs mean 'something arrived early'. Three mean 'it's probably genuinely gone'.

The packets prove it: The three-duplicate threshold in the congestion-control lesson exists precisely because one or two are not trustworthy evidence.

Throughput: How many bytes per second the link carries — including retransmitted copies of data that already crossed it once, and including packets that are about to be dropped.
Goodput: How many bytes per second of USEFUL, non-duplicate application data actually reach the far end. This is the number users experience, and it is the one that collapses.
Queue: The buffer inside a router where packets wait for a busy link. Small queues absorb bursts, which is good. Persistently full queues add delay to everything and drop what doesn't fit — and a full queue is what turns one host's aggression into everyone's loss.
Congestion collapse: The stable state where high throughput coexists with near-zero goodput, because most of what the network carries is retransmissions of data it already dropped.

✓ 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.

During congestion collapse, a monitoring dashboard shows the link at 100% utilisation. Why is that reading misleading?

Every host in the collapsed network is implementing TCP correctly by 1981 standards. What was actually missing?

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.