dummynet

The pipe underneath everything

Most traffic-shaping tools on macOS and BSD systems present a clean interface — a slider, a profile, a configuration panel — but below that interface something else is doing the actual work. dummynet is that something else. It lives inside the kernel, wired into the packet filter, and it is the mechanism that other tools have been driving for decades without necessarily saying so.

dummynet was designed and built by Luigi Rizzo at the University of Pisa in the late 1990s. Rizzo's original paper, published in ACM SIGCOMMComputer Communication Review, described a system for introducing controlled impairments — bandwidth limits, delay, packet loss, queue length constraints — directly into the kernel's packet-processing path. The goal was not to degrade a network for its own sake but to give researchers a reproducible way to study how protocols behave under realistic, varied, and precisely specified conditions. Before dummynet, that kind of controlled experiment generally required physical hardware: a box on the wire running carefully tuned firmware. dummynet moved the whole apparatus into software, attached it to the operating system's existing filtering machinery, and made it available on a general-purpose machine.

The architecture is cleaner than the name suggests. dummynet introduces two abstractions: pipes and queues. A pipe is a single link emulation — it carries a specified bandwidth and a specified one-way delay, and it can be told to drop packets at a given rate, randomly or according to a pattern. A queue is a holding structure that can feed one or more pipes, and it is where fairness between flows gets decided. Traffic is steered into a pipe or queue by rules in the packet filter; the filter sees a packet, matches it against its rule set, and if a rule says "pass this through dummynet," the packet leaves the normal forwarding path, enters the shaping machinery, and rejoins the stack when the pipe is ready to release it.

The delay that dummynet adds is genuine network delay — not processing overhead, not a sleep call somewhere in an application, but a packet held in a kernel queue until the simulated propagation time has elapsed and the simulated link has capacity to carry it. That distinction matters enormously for developers testing anything that has a time-sensitive protocol layer: TCP congestion control, video streaming adaptive bitrate logic, retry timers. The impairment is injected at the correct level so the rest of the stack sees it and reacts as it would on a real congested or distant link.

Inside the pipe: what gets shaped and how

dummynet operates beneath the socket layer, which means it is not selective about applications in the way an application-level proxy would be. Every packet that passes through a matching rule gets shaped — regardless of which process generated it, which language it was written in, or whether it uses a high-level networking framework. Shaping in the operating system reaches everything that machine sends, and dummynet is the historical exemplar of that property on BSD-derived systems.

The bandwidth a pipe can be configured to simulate is not a cap on throughput in the ordinary sense. It is a model of a link with finite capacity: packets queue when they arrive faster than the pipe can drain them, and the queue itself has a finite depth. When the queue fills, packets are dropped — exactly as they would be on a saturated physical link. That drop behaviour is where bufferbloat becomes visible in a controlled setting. A developer can tune the queue depth and watch what happens to latency as the queue fills; lengthening the queue while holding bandwidth constant shows the latency penalty that cheap memory and long queue configurations impose in real equipment. The effect Jim Gettys documented in production routers and broadband equipment shows up cleanly in a dummynet pipe set to a long queue depth, because the mechanism is the same: packets waiting for a slow drain.

The packet filter integration is provided by ipfw on FreeBSD, and on macOS the same ipfw/dummynet combination was accessible for much of the life of that kernel lineage. Rules can match on source and destination address, port, protocol, interface, and direction. Traffic in both directions can be shaped simultaneously with separate pipes, so a simulation of an ADSL connection — with asymmetric upload and download limits and different delays in each direction — requires two pipes and two rule sets, each covering one direction. This asymmetry is something link-level emulation on physical hardware handles by construction; dummynet makes it explicit and configurable.

Packet loss in dummynet can be specified as a simple probability — each packet is dropped with some percentage chance — or the system can be configured to drop in bursts, modelling the correlated loss patterns that real radio links or congested WANs produce. That distinction matters to developers because TCP responds differently to random loss versus bursty loss: the congestion window behaviour, the retransmit timer logic, and the interaction with modern congestion controllers like CUBIC or BBR each produce different outcomes under the two loss regimes. A test environment that can only simulate random loss is missing something.

From research tool to platform machinery

The history of how dummynet moved from a research system into production operating systems is a case study in the way good kernel code accumulates users. FreeBSD integrated dummynet early, and because macOS inherited its kernel lineage from BSD by way of NeXTSTEP, dummynet came along. Apple's Network Link Conditioner — the developer-facing tool that ships in the hardware IO profile pane and in the additional developer tools package — drives dummynet under the surface, converting named profiles like "3G" or "Edge" into pipe configurations before handing control to the kernel.

Luigi Rizzo's original dummynet paper in the ACM Digital Library describes a design that has remained substantially recognisable across its lifetime. The data structures, the pipe abstraction, and the filter integration are all present in the 1997 publication, which is unusual longevity for systems software. Later work, including Rizzo's subsequent publications on the subject, extended the model to handle more sophisticated queue disciplines and multipath cases, but the core mechanism — a kernel queue with tunable bandwidth, delay, and loss, driven by filter rules — stayed intact.

What dummynet demonstrates, and what makes it worth understanding rather than simply using, is the principle that a shaper is not separate infrastructure bolted onto a network: it is a model of how a network behaves, inserted at the point where packets exist as discrete objects that can be held, counted, dropped, or delayed. Every higher-level tool in this space — the configuration panels, the proxy layers, the scripted test harnesses — is either driving this mechanism or building an equivalent. Knowing where the pipe is, and what it can actually reach, tells you what any tool built on top of it can and cannot do.