Inside the kernel

Every packet from this machine, nothing from the next

Shaping that lives inside the operating system sits at a position that is both powerful and precise: it touches every packet the machine generates, regardless of which application sent it, which port it used, or which protocol it speaks. That coverage is the kernel's main advantage. It is also the boundary of what it can reach. Traffic from another device on the same network — a phone, a second laptop, a printer — crosses the wire without any of it being seen.

Understanding why requires a short trip through the stack. When an application calls a write function, the data descends through a series of software layers: the transport layer adds headers, the network layer decides the route, and eventually the packet arrives at the network interface queue, the final waiting room before bits leave the machine. Shaping disciplines are attached at that queue. Everything upstream of the interface, everything that originates on this host, passes through them. Everything arriving from outside, and everything that was never here, does not.

The queue and what it holds

A queue, in this context, is not a metaphor. It is a data structure in kernel memory, holding packets in some order, draining at the rate the physical link can absorb them. The simplest implementation is a FIFO — first in, first out — which imposes no preference among packets and no rate limit beyond the link's own capacity. The interesting work begins when the kernel replaces or supplements that structure with something that knows more.

A token bucket is one of the oldest such mechanisms. It models a bucket that fills with tokens at a fixed rate; each packet that leaves must spend tokens proportional to its size. When the bucket is empty, packets wait. The rate at which tokens arrive determines the maximum average throughput the queue will permit, and the bucket's depth determines how large a burst can pass before the discipline intervenes. The token bucket does not reduce the link's real capacity; it regulates how quickly the queue feeds into it, producing a smoother, metered flow.

Rate control alone does not solve everything. A machine with a deep buffer and a rate limiter set to match the link's capacity can still accumulate packets in a queue that grows without bound whenever traffic arrives in bursts — which is almost always. The latency penalty of draining that queue can reach hundreds of milliseconds even when the link is not congested in any meaningful sense. This is the condition Jim Gettys identified and named bufferbloat, the subject of sustained work at Bufferbloat.net and a significant driver of queue management research in the years that followed.

Active queue management at the kernel level

The response to bufferbloat was a family of techniques called active queue management, which act not by waiting for a queue to overflow but by intervening earlier — dropping or marking packets to signal congestion while there is still room. The goal is to keep the queue short enough that latency stays low, while still using the link efficiently.

The Controlled Delay algorithm, known as CoDel, was designed by Kathleen Nichols and Van Jacobson and published in 2012. Its central insight is that the metric to watch is not queue length but the time a packet spends waiting — the sojourn time. A queue can be short in bytes and still keep packets waiting too long if the drain rate is slow; conversely, a long queue that drains quickly may be entirely acceptable. CoDel targets a minimum sojourn time and begins dropping when that target is exceeded persistently. Because it is measuring time rather than occupancy, it adapts naturally to links of very different speeds without manual tuning.

FQ-CoDel, which pairs CoDel with fair queuing, goes further. It maintains a separate sub-queue for each flow — each distinct connection identified by source and destination addresses and ports — and serves those sub-queues in a way that prevents any single heavy transfer from monopolising the link. A large file download and a DNS lookup, arriving simultaneously, are given separate queues. The DNS packet is not held behind the download's backlog; it is pulled from its own queue and sent almost immediately. This is stochastic fair queuing combined with active management, and the latency reduction for interactive traffic during a bulk transfer can be dramatic.

Luigi Rizzo, working in Pisa, designed dummynet, a kernel-level traffic shaper and conditioner that takes a different angle: it is primarily a tool for imposing specific network conditions rather than optimising production traffic. Dummynet can add delay, loss and bandwidth limits, and it does so by sitting inside the packet filter path, intercepting packets before they reach the output queue. Its architecture made it a natural basis for network emulation tools, and its influence on later work in this space is substantial.

What kernel placement does and does not give you

The accuracy of kernel shaping is high by the standards of userspace tools because the kernel controls the clock and the scheduler. A userspace program asking to send data at a fixed rate is subject to scheduling jitter — the operating system may not wake it at exactly the moment it requested, and the deviation accumulates. The kernel, acting on packets directly, can enforce timing far closer to the intended schedule. This matters when the goal is repeatable test conditions, where a simulated link that behaves differently on each run is not a useful simulation.

There are limits the kernel cannot cross. It cannot shape traffic that was never routed through the host. It cannot inspect the inside of an encrypted connection at the application layer to make decisions based on content — shaping at this level operates on packets, not on HTTP requests or video streams. And because the kernel's queue sits at the outbound side of the local machine, it has no visibility into what is queued on a remote router or at the far end of a cable modem. The congestion that matters most in a real household network is often precisely there, past the boundary of anything the local kernel can reach.

What the kernel can do is enforce conditions consistently, close to the hardware, with low overhead and no dependency on the cooperation of the applications above it. That combination — coverage of everything local, precision at the queue, and freedom from application-layer constraints — makes kernel shaping the right mechanism when the machine itself is what you want to control, and a different problem entirely when the network is what needs changing.