Making a fast connection behave like a bad one
The job is easy to say and awkward to do. Three quantities have to move independently: how much gets through, how long each packet waits, and how many never arrive.
The tools that do it sit at different layers of the path, and the layer decides what they can reach — one application, one machine, or every device on the segment. Underneath all of them is the reason a fast link can be unusable: the queue.
They work the same queues we do.
Organisations whose attention sits at the same bottleneck this site was built around.
Three dials, turned separately
Section 01 · Making a link worse →Added latency
A wait added to every packet, and it can differ in each direction.
Read added latency →Loss and reordering
The signal a sender was built to hear — and the one that only looks like it.
Read loss and reordering →Where the shaping happens
Section 02 →Inside the kernel
Reaches everything the machine sends. Nothing above it can opt out.
The settings panel
A named profile instead of a rule set — the whole machine, one setting at a time.
Through a proxy
Only what is routed through it. Precise, and partial.
At the link
Every device on the segment, including the forgotten ones.
Section 03 · Bufferbloat
Memory got cheap and the queue got long
Jim Gettys named the condition: equipment given buffers far larger than the paths it serves, queueing a packet for seconds rather than dropping it.
The wire is fast. The wait is in a queue.