Specifications

Where the rules live

The machinery of network conditioning sits at the intersection of several overlapping standards bodies, but the Internet Engineering Task Force is where most of the foundational decisions were published. IETF output arrives as Requests for Comments — RFCs — and despite the modest name, a standards-track RFC carries real normative weight. When an implementation behaves unexpectedly, the first question is usually whether it is conforming to the RFC or departing from it.

The congestion-control rules that govern almost every TCP connection today descend from RFC 2581, which formalised slow start, congestion avoidance, fast retransmit and fast recovery. That document was itself a successor to Jon Postel's original TCP specification, RFC 793, published in 1981. Van Jacobson's algorithms — developed at Lawrence Berkeley National Laboratory and described in his landmark 1988 paper — are the mechanism behind those rules, though the paper preceded the RFC that standardised them. Reading RFC 2581 (and its successor, RFC 5681, published in 2009) explains precisely which behaviour a compliant sender must exhibit when it detects loss, and why a network conditioner that drops packets predictably will produce a reproducible sender response.

Queue management has its own specification history. Random Early Detection, developed by Sally Floyd and Van Jacobson and published in 1993, was documented in an RFC Informational track document rather than a standards-track one — a reminder that not every influential specification carries mandatory weight. The Differentiated Services architecture, described across RFC 2474 and RFC 2475, established the DSCP field that routers use to classify traffic into per-hop behaviours. These documents define what a compliant scheduler is supposed to do with marked packets; they do not guarantee that any given device does it.

What the documents actually settle

The practical value of reading specifications is precisely that they separate what a standard requires from what a vendor chose. Consider active queue management: RFC 7567, the IETF's 2015 guidance document on AQM, does not mandate CoDel or FQ-CoDel by name, but it does state clearly that large standing queues are harmful and that dropping packets only when a buffer is full is an inadequate strategy. Kathleen Nichols and Van Jacobson's CoDel algorithm, described in their 2012 ACM Queue article and later formalised in an IETF draft, targets a queue-sojourn time rather than a queue length — a design choice the RFC framework makes legible once you understand what the specification is trying to achieve.

Token-bucket rate limiting, the mechanism behind much of what a traffic shaper actually does, is defined in the context of the IETF's traffic-conditioning specifications. RFC 2697 specifies the single-rate three-colour marker; RFC 2698 specifies the two-rate variant. These documents define the parameters — committed rate, burst size, excess burst — and the marking behaviour that results. Any conditioner that claims to limit bandwidth to a target rate is implicitly implementing something in this family, and the RFC text is where the edge cases — what happens to a burst that arrives after a long silence, for instance — are worked out precisely.

dummynet, the BSD kernel shaper developed by Luigi Rizzo at the University of Pisa, has its own published specification in Rizzo's 1997 paper in ACM Computer Communication Review rather than an RFC, which reflects how much important infrastructure lives just outside the formal standards process. The paper defines the model — pipes, queues, delay, loss — with enough precision that it functions as a specification for the tool's behaviour, and subsequent implementations treat it as one.

Specifications as argument-settlers

The specifications matter for a practical reason: software tested against a simulated bad connection needs the simulation to be honest. If a conditioner claims to impose 200 ms of added latency and a one-percent loss rate, a reader who knows RFC 5681 can predict exactly how a conforming TCP sender should respond — reduced window, slower recovery, measurable throughput drop — and compare that prediction against what the software actually does. Divergence between prediction and measurement is information: either the conditioner is not doing what it claims, or the software under test is not conforming to the standard. The specification is the reference against which both are measured, and that is the whole point of having one.