At the link

The whole network, whether you remembered it or not

A shaper that runs on a laptop touches exactly the packets that laptop generates. Add a phone, a game console, a smart speaker, a work machine on the same Wi-Fi, and each of those runs its own traffic without passing through any software you have installed on any single device. The only point in the network where all of that traffic converges is the link between your local equipment and the outside world — which is to say, the router.

Shaping at the router or managed switch is categorically different from shaping on a single host. It is topological: the packets have no choice but to pass through, because the physical wiring and the routing table together leave no other path. This is why engineers testing how software behaves on a degraded connection increasingly reach for something upstream rather than something on the device under test. You want the impairment to be invisible to the application — not a layer inside it, not a loopback adapter it might detect, but a real link that happens to be slow, lossy or delayed.

What the router actually does to a packet

Every router contains at least one queue per interface, and that queue is where the interesting behaviour lives. When packets arrive faster than the outbound interface can send them, they wait. The depth of that wait, measured in bytes or in milliseconds, is a policy choice — one that network equipment manufacturers made largely without thinking about it, which is how the problem Jim Gettys named bufferbloat came to be understood. Gettys noticed around 2010 that consumer routers were being shipped with buffers far larger than any reasonable bandwidth-delay product would justify, with the result that a saturated link produced enormous, invisible latency rather than the packet loss that TCP congestion control was designed to react to.

The deeper point is that a queue is a policy. A router running a simple FIFO — first in, first out — with a very large buffer will treat every flow identically and delay everything equally when the link is full. A router running a smarter active queue management algorithm, like CoDel (Controlled Delay), developed by Kathleen Nichols and Van Jacobson and published around 2012, measures per-packet sojourn time inside the queue and drops or ECN-marks packets when that time exceeds a target threshold. The signal reaches the sending TCP stack and causes it to back off. The router is not just forwarding; it is participating in congestion control.

Van Jacobson's original congestion-control work, done at Lawrence Berkeley National Laboratory in Berkeley, California and described in the landmark 1988 paper he co-wrote with Michael Karels, established that TCP stacks needed to respond to loss as a congestion signal. What the CoDel work, and the earlier RED (Random Early Detection) work by Sally Floyd and Van Jacobson, added was the idea that the router itself could generate that signal more intelligently than a full buffer dropping everything at once. The 1993 Floyd–Jacobson paper on RED remains the foundational document for active queue management.

Fairness, and the flows nobody prioritised

A router shaping at the link also has to decide which packet to send next when the queue holds packets from many different flows simultaneously. The simplest answer — send whichever arrived first — is also the worst answer for interactive traffic. A large file transfer saturating the uplink will push a VoIP packet to the back of a long queue and introduce hundreds of milliseconds of jitter into a call. This is not a theoretical problem; it is the ordinary behaviour of most home routers under load.

Fq-CoDel, a discipline that combines fair queueing with CoDel's sojourn-time measurement, addresses this by hashing packets into flow buckets and serving those buckets in a round-robin fashion, so that no single flow can monopolise the queue. Dave Taht, working with others through Bufferbloat.net, was central to the practical deployment of fq-CoDel in consumer firmware, particularly through the CAKE (Common Applications Kept Enhanced) shaper, which adds further structure for handling the asymmetric bandwidth common in DSL and cable connections. Luigi Rizzo's earlier dummynet work, developed in Pisa, Italy and integrated into the BSD packet filter infrastructure, had already demonstrated that kernel-level queueing disciplines could be made general and composable; the later Linux work built on that intellectual foundation even where it did not share the code.

The Internet Engineering Task Force has documented many of these mechanisms through its working groups on transport and active queue management; the relevant RFCs are the specifications that implementations must conform to, and reading them is the shortest path to understanding what the kernel is actually supposed to do at each step.

The gap between the router and the test

For developers using a conditioned link to test software behaviour, shaping at the router introduces a subtlety that shaping on a single host does not. The router sees all traffic from all devices, which is exactly what you want — but it also means that background traffic from a phone or a streaming television affects the test environment unless the router's queuing discipline is sophisticated enough to isolate flows. A naive token-bucket shaper on the WAN interface will throttle everything equally, which means a software update downloading on another device degrades your test in ways that cannot be attributed to the shaper's settings.

This is one reason that controlled testbeds — isolated network segments where the only traffic is the traffic under examination — are the correct tool for reproducible measurement. Repeatability demands that the impairment be the only variable. A home router in a live household is a useful approximation, but it is not a controlled experiment.

That said, the approximation has real value. Observing how an application actually behaves when sharing a constrained link with real competing traffic is different from observing it in isolation, and sometimes the former is the test worth running. The router is the one place in the network where both experiments are possible, at different levels of rigour, because every packet must pass through.