CUBIC and BBR: follow the packets

Exact packet evidence

Measure delivery, not just window size

Two senders run against separate, identically configured FIFO bottlenecks. They do not compete for the same queue. Each packet occupies the link for one divided by capacity seconds. A full waiting queue rejects a new packet; an accepted packet may encounter seeded independent path loss. Feedback returns after service plus the configured base round-trip delay. The screen separates sent, delivered, lost and outstanding packets. A larger congestion window is permission to have more packets in flight, not evidence that more packets reached the receiver. Compare delivery rate and delay together.

Control the network

Capacity chooses twenty through two hundred packets per second. Base RTT selects fifty through five hundred milliseconds of feedback delay before queueing and serialization are added. Waiting slots sets the queue limit from zero through one hundred packets; the packet currently in service is separate. Independent loss selects a zero through ten percent probability for each serviced packet. Seed makes those path-loss decisions repeatable; it does not alter a loss-free path. Halve capacity at ten seconds changes future packet service while preserving the scheduled completion of the packet already in service. Every network edit pauses and rebuilds both complete traces.

Inspect the two controller mechanisms

The CUBIC-core sender starts with ten packets, increases on acknowledgements during slow start and reduces its window by a factor of 0.7 on loss, at most once per measured recovery interval. Its subsequent target is a cubic curve around the previous maximum, with a Reno-friendly estimate. Pacing is window divided by smoothed measured RTT. The BBR-style sender estimates delivered packets per time interval and retains the maximum of ten recent samples. It combines that estimate with minimum observed RTT to size its flight allowance. Its startup, drain, bandwidth-probe and RTT-probe phases change pacing gain or the flight cap. The cards display the active phase and measured estimate rather than a preset winning label.

Try queueing and a changed bottleneck

Start at capacity one hundred, RTT one hundred, twenty waiting slots and zero independent loss. Show final result and compare both delivered counts with their mean RTT and queue histories. Then set waiting slots to zero and repeat: packet overlap can cause overflow even though there is no random path loss. Increase the queue to one hundred and inspect whether additional buffering improves delivery or mainly extends waiting. Enable the capacity step and scrub across ten seconds. The capacity changes immediately for new service starts, but senders learn through later feedback; their estimates must not read the configured capacity directly.

Try latency and repeatability

Increase base RTT to five hundred milliseconds while keeping capacity fixed. More packets are required in flight to keep the same link busy, and feedback takes longer. Set independent loss to five percent, choose seed forty-two and note each controller’s loss counts. Changing the seed changes the experiment; restoring it reproduces the same trace. Both paths use the same initial seed, but their different traffic schedules mean this is not paired loss on the same wall-clock packet. Do not infer universal superiority from one configuration. The graphs show a sixty-second inspection of twenty logical seconds, not a network speed test.

Playback and evidence

Play and Pause advance or hold the displayed state. Next sample moves one tenth of a logical second; Restart rewinds without changing inputs. Speed offers half, normal or double inspection pace. Inspect time scrubs the recorded trace, and Show final result jumps to its horizon. Restore defaults restores every network input. Window and queue plots show the inspected history; the comparison cards give delivered packets in the preceding logical second, recent mean RTT, cumulative losses and outstanding packets. Open Exact packet evidence for feedback timestamps, departure times and controller transitions. This evidence is generated by the same model as the scene.

What this teaching model leaves out

These are explicitly simplified CUBIC-core and BBR-style controllers, not a kernel TCP benchmark or an implementation of every current BBR version. The scheduler uses two-millisecond steps and caps windows at 512 packets. Loss notifications are a teaching oracle, including an overflow notification after base RTT; there are no duplicate ACKs, retransmissions, timeout recovery, receiver limits, delayed ACKs, ECN or competing flows. CUBIC fast convergence and HyStart++ are omitted. BBR delivery samples use fixed time windows rather than packet-round delivery-rate sampling, and its minimum RTT persists for this short run. All sends are new fixed-size packets, so delivery is not reliable TCP goodput. These limits matter when interpreting recovery or comparing algorithms.

Mechanism references: CUBIC specification and BBR authors’ paper.