Kathleen Nichols and the queue delay a fast link cannot hide

Summary

• Nichols co-designed Controlled Delay Active Queue Management, or CoDel, with Van Jacobson after a career spanning DiffServ, Cisco architecture, Packet Design and independent consulting through Pollere.
• CoDel measures packet sojourn time at dequeue and reacts when the recent minimum remains above a target for an interval, distinguishing transient bursts from persistent backlog.
• The design reduced ordinary per-link tuning, but target, interval, timestamp arithmetic, queue placement and service-rate variation still define where its assumptions hold.
• FQ-CoDel, Linux integration and later queue systems belong to wider author and maintainer communities; CoDel’s enduring contribution is the decision to control persistent time rather than occupancy alone.

CoDel made the queue measure the time it adds

CoDel makes its decisive measurement when a packet leaves a queue. The packet’s dequeue time is compared with its enqueue time, producing the sojourn delay that the queue itself added. Kathleen Nichols and Van Jacobson designed the controller around that local fact because a queue containing the same number of packets can be harmless on one link and intolerable on another.

The operational contradiction was familiar: an access connection could deliver its advertised throughput while voice, gaming or an interactive request stalled behind a standing backlog. Buffers are useful when they absorb a short burst and drain. They become harmful when every departing packet is replaced, turning waiting time into a permanent part of the round trip without creating more capacity.

CoDel tracks the minimum sojourn time over an interval. If even the best-observed packet continues to wait above a target, the controller treats the backlog as persistent and increases congestion signalling according to its control law. The design sought ordinary defaults that would travel across common internet links without asking every operator to derive queue thresholds from rate, buffer size and traffic mix.

The governing question is how far a time-based controller can turn low latency into an operational default. CoDel controls only the queue in which it runs. Hidden hardware buffers, variable service rates, unresponsive senders and incorrect placement can still dominate the path. Nichols’ contribution is best understood as a change in what the queue measures and what operators must verify: not a small packet count, but whether waiting remains persistently high under load.

DiffServ and product work separated classification from queue control

Kathleen M. Nichols’ public biography describes a career across research laboratories, technology companies and internet standards. Her technical roles included AT&T Bell Labs, Apple, Philips Research Laboratories, Com21 and Bay Networks. She later served as Cisco’s director of advanced internet architectures in the Office of the CTO, joined Packet Design’s founding team and became its vice president of network science, and founded Pollere LLC.

The available public record establishes that institutional sequence more clearly than it establishes every transition date. A responsible profile should not fill the gaps with a reconstructed corporate chronology. The sequence is enough to show a career repeatedly positioned between theory, equipment design and operator evidence.

Nichols holds a doctorate in electrical engineering and computer sciences from the University of California, Berkeley, and a bachelor’s degree in electrical engineering from the University of Pittsburgh. The engineering background is relevant because CoDel is more than a statistical classifier. It is a feedback controller embedded in a packet scheduler, with timing, state transitions and implementation arithmetic that have to work under load.

Her work before CoDel also involved internet quality of service. Nichols co-chaired the IETF Differentiated Services Working Group, which developed a scalable architecture for classifying traffic and applying different per-hop treatment. DiffServ addressed a real problem: an operator cannot maintain per-flow reservation state for every internet packet, yet may need classes for latency-sensitive, managed or best-effort traffic.

A class architecture, however, does not determine whether a queue inside that class remains full. Marking a packet for preferential treatment decides which queue or behaviour it receives. Scheduling determines how queues share service. Active queue management decides when a queue should signal congestion. Those are related control layers, not interchangeable labels.

That distinction helps locate CoDel within Nichols’ career. DiffServ asked how policy should be represented at scale. Packet Design worked in network intelligence and analysis. Cisco placed architecture inside a large equipment context. Pollere offered an independent vehicle for network and telecommunications consulting. CoDel addressed the point where traffic policy becomes the time a packet actually waits.

The public Pollere page identifies Nichols as founder and chief executive. The page remains available, but the available public record contains no recent appointment announcement or complete current business disclosure. The safest current description is that she founded Pollere and remains publicly associated with its consulting and research work, while the exact current officer status should be reconfirmed for a time-sensitive biography.

The institutional path matters because CoDel responded to a recurring deployment failure. Earlier active queue-management schemes could perform well in controlled studies and still be difficult to configure in products. An algorithm that required thresholds derived from link rate, buffer size and traffic mix asked every operator or vendor to become a queue-control specialist. Nichols and Jacobson aimed for a controller whose ordinary defaults travelled better.

Differentiated Services created a way to encode a traffic class in the IP header and define per-hop behaviours without building a global reservation system. A network could place packets into queues or scheduling classes according to policy. The architecture scaled because routers did not need detailed end-to-end state for every flow.

This work shaped the vocabulary around CoDel. Classification answers which treatment a packet should receive. Scheduling answers which queue should be served next. Shaping can set a controlled service rate. Active queue management decides when queued traffic should receive congestion feedback. A complete low-latency design may need all four.

Suppose an operator creates a low-latency class and a bulk class. The class boundary can protect interactive traffic from some competition. It cannot guarantee that the low-latency queue is sized or managed correctly. If that queue is allowed to remain persistently full, the label promises priority while the implementation still adds delay.

The reverse problem also exists. An AQM can keep one aggregate queue’s delay under control while a bulk flow competes with a sparse interactive flow inside it. The aggregate delay may look acceptable, but the sparse flow can still wait behind a burst of packets. That limitation later became central to the distinction between standalone CoDel and FQ-CoDel.

Nichols’ DiffServ experience therefore should not be treated as an unrelated line on a résumé. It supplied an architectural discipline: separate the control functions and state exactly what each one can guarantee. CoDel is not a QoS system. It is one queue controller that can sit inside a larger traffic architecture.

Standards work also teaches caution about deployment claims. An RFC can define a mechanism and interoperable language. Vendors still have to implement it, operators have to enable it, and endpoints have to respond. CoDel’s later publication as an Experimental RFC preserved the algorithm and detailed pseudocode without declaring that every network should use it in every condition.

Queue length could not distinguish a burst from persistent harm

Many queue-management designs use occupancy. A queue above one threshold may begin dropping or marking, with more aggressive action as it grows. The apparent logic is straightforward: a fuller buffer means more congestion.

The measurement changes meaning with the link. Ten packets on a slow link can represent far more time than ten packets on a fast one. Byte counts improve the relationship and still require knowledge of service rate. A threshold suitable for one access speed may be too small after an upgrade or far too large when applied elsewhere.

Average queue length adds another layer. Smoothing can prevent a brief burst from triggering an excessive response, but the averaging constant and thresholds become parameters that interact with rate, round-trip time and traffic. A vendor can ship defaults. Those defaults may perform differently across the product’s many operating conditions.

Sojourn time asks a more direct question. A packet is timestamped when it enters the queue. When it reaches dequeue, the controller can calculate how long it waited. Five milliseconds has the same unit on a megabit link and a gigabit link, even though the number of bytes represented by that delay differs greatly.

Time is not automatically a perfect signal. Timestamp resolution and wraparound have to be handled correctly. The queue must know when the packet entered. Clock cost matters in a fast path. If the packet waits in another hidden queue after leaving the controlled one, CoDel cannot see that later delay.

The advantage is that the measured quantity corresponds to the queue’s contribution to latency. It allows the controller to describe its objective as tolerated persistent delay rather than a buffer occupancy chosen indirectly for one device.

That change of sensor also alters the operational conversation. Link capacity can change through rate adaptation, wireless conditions, shaping or service upgrades. A queue-length controller may need new thresholds. A time-based controller can continue asking whether packets are waiting too long, subject to the range of conditions for which its target and interval were designed.

CoDel’s claim of reduced tuning rests on this relationship. It does not rest on magic constants that always work. The algorithm is designed around a measurement that stays interpretable when the number of packets or bytes needed to keep a link busy changes.

The phrase “good queue, bad queue” is more than an educational shortcut. It identifies why a static occupancy threshold struggles. The same queue depth can represent useful absorption in one moment and persistent delay in another.

Consider an application that emits a brief burst after receiving a response. The arrival rate temporarily exceeds the link rate, so packets accumulate. If the sender then pauses and the queue drains, the buffer has smoothed the burst and kept the link busy. Removing all capacity to absorb that burst could create losses and underutilisation without improving the long-term delay.

Now consider a bulk sender whose congestion window continually maintains enough in-flight data to keep the buffer occupied. Each departing packet is replaced by another. The queue may settle around a level that produces reliable throughput and a large round-trip time. The buffer is no longer bridging a transient mismatch. It has become additional path length measured in milliseconds.

A packet-count threshold can see that both queues contain, for example, fifty packets. It cannot know whether the queue emptied between bursts. An average can describe occupancy over time and may still fail to distinguish one long backlog from several short bursts with similar mean size. The recent minimum of sojourn time asks the exact differentiating question: did any packet get through without enduring the standing wait?

This approach also reframes utilisation. Low delay does not require an empty queue at every instant. The link can remain busy while the minimum periodically falls below target. CoDel’s objective is not visual neatness in a buffer graph. It is to preserve evidence that service catches up with arrivals within the chosen interval.

The distinction becomes operational when traffic mixes change. A queue serving one long transfer may be stable. Add interactive traffic and the same standing backlog becomes visible as user delay. Add many short flows and the burst pattern changes. A controller based on time can continue evaluating the local consequence while an occupancy controller may need a different threshold for each mix.

There is still judgement in the target. Five milliseconds of standing delay may be small relative to one path and material to another. The point is that the judgement is expressed in the unit the user experiences. Network owners can debate the service objective directly instead of debating an indirect number of packets whose time meaning changes with rate.

The recent minimum reveals whether the queue ever drains

Looking at one packet’s sojourn time would be too reactive. A short burst can make several packets wait above the target even when the queue drains immediately afterward. Dropping as soon as one packet crosses a threshold could punish useful burst absorption.

CoDel instead tracks the minimum sojourn time observed over an interval. The minimum asks whether the queue ever became nearly empty, not whether it was ever busy. If at least one packet experienced low waiting time, the backlog may be transient. If even the best-observed packet waited too long throughout the interval, the queue is standing.

This use of a local minimum is central to the design. Average delay can remain elevated after a burst and can hide whether the queue drained. Maximum delay is dominated by the worst packet. The minimum provides evidence that service caught up with arrivals at least once.

The interval has to be long enough to observe the feedback dynamics of ordinary internet traffic. RFC 8289 uses 100 milliseconds as the normal terrestrial design point and discusses environments where different values may be appropriate. The interval is not a measurement of every flow’s exact round-trip time. It is a timescale over which persistent backlog should reveal itself.

The target, commonly five milliseconds in the specification and implementations, represents tolerated standing delay at that queue. It is not a promise that end-to-end latency will be five milliseconds. Propagation, processing, radio scheduling and other queues remain. It is the controller’s local threshold for deciding that its own contribution has stayed too high.

These values are often repeated without their qualification. “Five and one hundred” are design defaults for normal internet conditions, not laws of networking. A very short data-centre path, a satellite system, an unusually low-rate link or a specialised service objective may require analysis. CoDel’s achievement is that ordinary operation was designed not to require every link owner to calculate new values.

The recent-minimum test also explains why a queue can be large without being continuously bad. A burst may momentarily occupy many packets. If it drains within the interval, the controller does not classify the condition as persistent solely because of the peak. The algorithm protects burst tolerance while treating time that never falls below the target as evidence of congestion.

Dequeue timing and the control law turn observation into a signal

Queue-management discussions often focus on arrival. A packet enters, the queue checks its length and decides whether to accept or drop it. CoDel’s principal observation occurs when packets leave, because dequeue is where actual sojourn time can be measured.

The packet carries or is associated with its enqueue timestamp. At dequeue, the controller subtracts that time from the current time. It updates the minimum for the interval and decides whether the queue has remained above the target long enough to enter its congestion-signalling state.

Acting at dequeue has a practical logic. The service process determines when a packet’s wait has ended. The controller can observe the queue under the exact rate at which it is being drained, including rate changes that would make a fixed occupancy threshold misleading.

The implementation still interacts with enqueue. The timestamp has to be recorded and preserved. A scheduler or queueing discipline must expose the packet state. Hardware offload can complicate the boundary if packets are handed to a device queue whose later delay is invisible to the software controller.

When CoDel concludes that delay has persisted, it drops or, for eligible traffic under appropriate policy, marks a packet with Explicit Congestion Notification. The signal asks responsive senders to reduce load. The queue then watches whether conditions improve.

The algorithm exits the dropping state when the queue becomes empty or delay falls sufficiently. It is not intended to remain permanently punitive. The objective is to restore a state in which the bottleneck can remain utilised without carrying a standing backlog.

This dequeue orientation is one reason implementation details cannot be dismissed as mere coding. Timestamp arithmetic, state transitions, empty-queue handling and the order in which a packet is marked or dropped determine whether the published control law is actually reproduced.

The Linux implementation involved Eric Dumazet and other kernel contributors, as well as wider review and integration. Nichols and Jacobson provided the CoDel design; the deployed qdisc is collective infrastructure. The distinction protects both kinds of credit. A design becomes useful only when maintainers translate it into a reliable packet path.

Once CoDel enters its congestion-signalling state, it does not use one fixed interval between drops or marks. The timing becomes progressively more aggressive according to an inverse-square-root relationship with the count of signalling events.

The control law reflects the dynamics of congestion-controlled traffic. Under persistent overload, one signal may be insufficient. Sending signals at a rate that increases with continued congestion can bring the queue down more quickly. The inverse-square-root form avoids requiring an operator to configure a drop probability for the specific link and load.

The mechanism should be described carefully. CoDel is not estimating an exact number of TCP flows and calculating their windows. It applies a control schedule designed to work with common congestion responses. The outcome depends on traffic that reacts to loss or ECN. A sender that ignores feedback can continue occupying capacity.

Implementing the schedule requires efficient arithmetic. Kernel packet paths cannot casually use expensive floating-point operations. Fixed-point or integer approximations, timer resolution and wrap behaviour matter. A small mathematical error can change the signal sequence under heavy load.

This is where Nichols’ control-oriented contribution becomes most visible. The estimator decides whether persistent delay exists. The target defines the desired region. The control law determines how the system responds when it remains outside that region. None of those parts alone is CoDel.

A queue controller also cannot choose the service rate. If the true bottleneck is downstream of the configured qdisc, the qdisc may drain into a deeper device buffer and see little delay itself. Operators often pair AQM with shaping so that the controlled software queue becomes the effective bottleneck and can signal before a hidden queue fills.

The inverse-square-root schedule therefore belongs to an operational system. It is useful when the queue observes the bottleneck, timestamps are correct and senders respond. It is not a substitute for capacity, traffic isolation or policing of deliberately unresponsive flows.

Reduced tuning still depends on correct time

CoDel is frequently called parameterless. The shorthand captures an important ambition and can become false when stated literally. The algorithm has a target and an interval. Implementations contain constants, timing state and operational choices.

RFC 8289’s more precise formulation is that no configuration is required in normal internet deployments. Nichols and Jacobson sought values and a sensor that could span common terrestrial rates and round-trip times without the per-link tuning associated with earlier AQM approaches.

This distinction affects procurement and engineering. A vendor can reasonably claim that CoDel is designed to work with normal defaults. It should not claim that every network, from an on-chip interconnect to a satellite link, shares the same timing domain. Operators should understand when their environment falls outside the assumptions.

The data-centre case is instructive. Round-trip times can be much shorter than the normal internet interval. Queues may sit in switches with shallow but high-rate buffers, and workloads can produce incast. The same principle—detect persistent sojourn time—remains relevant, while the target and interval may need to reflect the environment.

Very low-rate links create another edge. Serialization time for a single large packet can exceed several milliseconds. The controller must distinguish unavoidable service time from standing queue. Shaping, maximum transmission units and packet scheduling affect the result.

Wireless links can vary rate rapidly and contain queues below the visible interface. A time-based sensor adapts better than a fixed packet count to rate changes, but it cannot control a firmware queue it does not own. Placement remains decisive.

Calling CoDel parameter-insensitive is therefore more defensible than calling it without parameters. The design reduced the number of network-specific values an ordinary operator needed to choose. It did not abolish the need to know where the bottleneck is and what time objective the service requires.

This qualification does not diminish the contribution. Operational simplicity is often produced by carefully chosen defaults and robust measurement, not by deleting every control. The relevant test is whether the system behaves acceptably across its intended range without requiring expert intervention.

CoDel’s sensor depends on subtracting an enqueue time from a dequeue time at packet-processing speed. The apparent simplicity hides choices about clock source, resolution, integer width and wraparound.

A clock that advances too coarsely can quantise short delays. A per-packet timestamp that is expensive can add overhead on the path the controller is meant to improve. A counter that wraps must still allow correct comparison across the target and interval. Implementations commonly use efficient integer representations and carefully defined time comparisons.

The control state has timing of its own. The interval window must reset correctly, and the next mark or drop time must follow the inverse-square-root schedule without overflow. Empty queues and re-entry into congestion state need defined behaviour so that stale state does not punish a later burst.

These details are why published pseudocode and open kernel code matter. An implementer can compare arithmetic and state transitions rather than imitate a verbal description. Tests can exercise wrap boundaries and queue transitions that a throughput benchmark may never reach.

Nichols and Jacobson supplied an algorithm designed for implementation. Kernel and device developers still own the correctness of each implementation. A product can advertise the CoDel name while differing in timestamp precision, ECN policy or queue placement enough to change the outcome.

The engineering lesson is consistent with the design’s central claim: measurement quality determines control quality. A queue cannot regulate persistent waiting time if its own representation of time is unreliable.

ECN can replace a drop only when the feedback path honours the mark

Packet loss is a forceful congestion signal. It also discards work that may need retransmission. Explicit Congestion Notification allows a capable queue to mark an eligible packet instead, preserving the packet while informing the endpoints that congestion has occurred.

CoDel can use ECN marking according to implementation and policy. The controller’s standing-delay detector remains the same. The action changes from destroying an eligible packet to setting a congestion indication.

The benefit depends on end-to-end semantics. The sender has to receive feedback and reduce its sending rate. Tunnels, middleboxes and endpoint implementations have to preserve or correctly translate the signal. A mark that no sender honours is not congestion control.

This boundary prevents an exaggerated claim that CoDel “eliminates packet loss.” It can mark eligible traffic where ECN is deployed and still drop traffic that cannot be marked or does not respond. Under severe overload, loss may remain necessary.

ECN also introduces policy choices. Classic ECN transports and newer low-latency approaches may interpret queue marking under different architectures. A queue should not apply semantics that endpoints do not expect. The AQM, scheduler and transport ecosystem have to be evaluated together.

Nichols’ broader work on traffic architecture makes the point clear. A bit in a header is useful only when every layer agrees on what it means and what action follows. Queue management supplies evidence and a signal. The transport closes the feedback loop.

Standalone CoDel and FQ-CoDel solve different parts of the queue

CoDel controls persistent delay in one queue. It does not by itself divide traffic into separate flow queues. If a large transfer and a sparse interactive flow share the same FIFO, the sparse packet can wait behind a burst even when the aggregate controller keeps long-term delay bounded.

FQ-CoDel combines flow queueing and scheduling with CoDel applied within queues. Packets are classified, commonly through hashing, into flow queues. A scheduler shares service among active queues, while CoDel controls standing delay in each. Sparse flows can receive service without waiting behind the full burst of a bulk flow.

Authorship must remain precise. Nichols and Van Jacobson co-designed CoDel. RFC 8290, which documents FQ-CoDel, was authored by Toke Høiland-Jørgensen, Paul McKenney, Dave Taht, Jim Gettys and Eric Dumazet. Nichols’ work is foundational to the combined system; she is not an author of that RFC.

The distinction is technical as well as biographical. Flow isolation addresses competition. CoDel addresses persistent delay. A scheduler determines the order in which queues are served. Combining them can produce a more useful edge qdisc than deploying one aggregate CoDel queue.

Hashing is not perfect identity. Different flows can collide in one queue. Some applications open many flows. Traffic may be classified by more than the conventional tuple. The scheduler’s quantum and shaping context matter. FQ-CoDel is a practical architecture, not absolute per-user fairness.

Its operational adoption also should not be used as a direct measure of standalone CoDel deployment. Platforms may expose FQ-CoDel, ship it as a default, include it as an option or place another qdisc above hardware queues. Availability does not prove correct active use on the true bottleneck.

Later systems such as CAKE build on related ideas while adding shaping, richer fairness and policy. Newer low-latency architectures such as DualQ/L4S use different signalling assumptions. CoDel’s influence can persist inside descendants without making Nichols the author of every later queue design.

The controller must sit on the queue that is actually causing delay

An AQM sees only the queue in which it runs. This is the most important operational limit and one of the easiest to overlook in a software demonstration.

A Linux host can apply CoDel or FQ-CoDel to an interface and then hand packets to a network device with its own transmit ring and firmware buffer. A broadband modem may have another queue. A Wi-Fi system may schedule frames in firmware. The provider’s access network can add more buffering. If one of those later queues becomes the standing backlog, the software qdisc can report healthy delay while the user still waits.

Shaping can move the effective bottleneck into a controlled queue by setting a rate slightly below the downstream service. The software scheduler then accumulates packets before the hidden device queue does. This approach requires an accurate or conservative service estimate and can sacrifice some peak capacity when the link rate varies.

Receive direction is similarly complicated. An endpoint controls when it sends its own packets; it cannot directly schedule packets already arriving from the provider. Ingress shaping, intermediate functional blocks and endpoint feedback can help, but the placement and architecture differ from a simple egress queue.

Hardware offload adds another boundary. A driver may transfer many packets into a device. The operating system sees them as dequeued even if the NIC will transmit them later. Byte Queue Limits and related mechanisms can reduce hidden driver buffering, but queue ownership remains platform-specific.

The conclusion is not that CoDel fails outside a laboratory. It is that deployment has to identify the bottleneck and keep uncontrolled buffering below it from recreating the problem. A good controller on the wrong queue is observing the wrong system.

That is why user-visible testing matters. Operators should measure latency under load rather than inspect only qdisc configuration. Bidirectional tests, application performance and hardware counters can reveal delay beyond the software queue. The algorithm’s internal state is evidence about one layer, not the path’s whole truth.

Many access links do not have one fixed departure rate. Wireless modulation changes with signal conditions. Cable and passive optical systems share capacity. Mobile schedulers allocate radio resources over time. A home router may know only the nominal service tier, not the instantaneous bottleneck.

A fixed packet threshold performs especially poorly in this environment because the delay represented by a packet changes with the rate. Sojourn time retains its unit, which is one reason CoDel was attractive. The queue can observe that packets have begun waiting longer without first estimating the new number of bytes that corresponds to the target.

The controller still operates only where it is placed. If a variable-rate modem or radio holds a large queue after the host, software CoDel cannot observe the true departure schedule. A shaper set below the minimum expected rate can move the queue into software and can waste capacity when the link improves. A shaper that tracks the rate can perform better and requires reliable feedback from the access technology.

This trade-off explains why AQM is often inseparable from device integration. The algorithm may be general, while a high-quality product needs rate information, hardware queue limits and coordination with link scheduling. Open pseudocode lowers the barrier to implementation; it does not erase the vendor’s engineering responsibility.

Variable service also complicates interpretation of the interval. CoDel is designed to react to persistent delay over a timescale related to common round trips, not to chase every momentary rate fluctuation. Excessively rapid reaction could discard useful bursts when the radio briefly slows. Excessively slow reaction allows a backlog to become user-visible.

The design’s use of a recent minimum helps. If the queue drains when capacity returns, the minimum records that relief. If it never drains despite rate variation, the persistent condition remains visible. This is a more stable question than whether the instantaneous occupancy crossed a fixed threshold.

Newer access systems can add richer scheduling and per-station fairness. Those features may solve competition that standalone CoDel does not address. The algorithm remains one component whose sensor is useful precisely because the link’s byte capacity is not constant.

Non-responsive traffic and policy can overwhelm a delay controller

CoDel’s signals assume that enough traffic responds by reducing offered load. TCP and other congestion-controlled transports are designed to do so. Applications or attacks that ignore loss and ECN can continue sending at the same rate.

A queue cannot create capacity. If unresponsive traffic occupies the bottleneck, dropping or marking it more often may protect some responsive traffic, but policy and scheduling may be required. Per-flow queueing can isolate offenders. Policing can enforce a rate. Admission or application controls may be needed for managed services.

This limit is not unique to CoDel. Congestion control is a cooperative architecture enforced partly through endpoint behaviour and partly through network policy. RFC guidance on congestion responsibility exists because one unresponsive flow can impose delay and loss on others.

Traffic classes can help and can create another failure mode. A privileged class with no effective rate limit can starve best effort. A classification rule can be wrong or abused. AQM inside each queue manages delay; it does not decide whether the class allocation is legitimate.

The operational task is to align incentives. Responsive applications benefit when the queue signals early and competitors also reduce load. Unresponsive senders may benefit from taking more share until the network enforces a boundary. FQ-CoDel and related schedulers improve isolation, while they do not substitute for every abuse or service-policy control.

Nichols’ work is strongest when kept within this system view. CoDel improves the quality of local congestion evidence and the timing of feedback. It does not claim sovereign authority over every sender or every queue on the path.

Linux and the RFC turned the design into maintained infrastructure

The transition from a paper and pseudocode to a kernel queueing discipline required implementation, review, test and long-term maintenance. Linux support made CoDel available to a wide range of hosts, routers and products built on the kernel.

Eric Dumazet is among the contributors associated with Linux implementation, and later FQ-CoDel work involved a separate group of developers. Kernel source provides bounded evidence of specific changes. It does not turn every deployment into a personal project of any one contributor.

The qdisc must integrate with Linux traffic control, timestamps, packet metadata, ECN and scheduler conventions. User-space tools need to configure and display it. Distributions and device vendors decide whether the module is built, exposed and selected by default. Hardware paths determine how much buffering remains outside it.

This supply chain makes open implementation important. Researchers and operators can inspect the code, compare it with the RFC and test modifications. Bugs can still survive. Different kernels can backport fixes or carry vendor changes. An available source tree is an audit opportunity, not a guarantee that every appliance runs the same code.

RFC 8289, published in January 2018 as Experimental, preserved detailed pseudocode and design reasoning. The category matters. It records a mechanism intended for implementation and evaluation rather than imposing a Standards Track requirement. Widespread availability can coexist with Experimental status.

The RFC also fixes attribution more clearly than product marketing often does. Nichols and Jacobson are the CoDel designers, while the editors and implementation communities have their own roles. FQ-CoDel’s RFC names its different author team.

This layered authorship is common in infrastructure. A researcher defines a control law. Kernel developers make it safe and efficient. Distribution maintainers package it. Operators place it in a topology. Application users experience the result. The profile is more accurate when it follows that chain instead of looking for a sole inventor of low latency.

RFC 8289 is categorised Experimental. In public discussion, that label is sometimes read as a warning that the mechanism is unproven and sometimes ignored as though every RFC were an internet standard. Neither interpretation is adequate.

The IETF uses document categories to indicate status and intent. An Experimental RFC can provide a complete, reviewable specification for implementation and evaluation without creating a Standards Track requirement. CoDel’s RFC includes detailed reasoning and pseudocode because independent implementations need more than a high-level paper.

The category leaves deployment decisions with implementers and operators. A Linux qdisc, router firmware or access product can use the algorithm. The vendor should validate the implementation and state the environment. The RFC number does not certify the product, and Experimental status does not prohibit production use.

This status also protects against retrospective overclaim. The presence of CoDel or FQ-CoDel across open systems is evidence of influence and availability. There is no complete audited census of active configurations, bottleneck placement or performance. Package counts and product documentation cannot fill that gap.

Standards maturity and operational maturity can move at different rates. A mechanism may be deployed widely while remaining Experimental because the standards process has not changed its category. Another mechanism can be Standards Track and scarcely enabled. Reporting should describe both dimensions instead of allowing one label to stand for the other.

The RFC’s value is partly archival. It fixes the design assumptions, the meaning of target and interval, the control law and implementation notes against which code can be reviewed. Later kernel changes and platform adaptations can be compared with that baseline.

For Nichols’ profile, the status strengthens the evidence-led thesis. CoDel was offered as a practical controller with explicit assumptions and limits, not as a decree that low latency had been solved. Its reputation should continue to depend on measurements in real queues.

Pollere placed independent expertise between standards and products

Pollere LLC gave Nichols an institutional vehicle outside a large equipment vendor or conventional research laboratory. Its public description centres on network and telecommunications consulting. The available evidence does not disclose a complete client list, revenue, headcount or current engagement volume.

That absence limits the business profile and clarifies the relevant point. Pollere allowed technical work and advice to continue without treating CoDel as a proprietary product owned by a startup. The algorithm was published, implemented openly and specified through the IETF.

Independent consulting can connect operator problems with research agendas. It can also make project funding and time allocation opaque. A public RFC may be globally used while the underlying design work was supported through consulting, employer time, research collaboration or unpaid contribution in proportions not visible to readers.

The economics differ from a vendor selling an appliance. Pollere’s value is expertise: architecture, analysis and advice. CoDel’s value is an open mechanism that vendors and operators can implement. Revenue from products using CoDel does not become Pollere revenue, and product adoption does not establish a commercial relationship with Nichols.

This separation protects the article from two common errors. The first is to describe an open algorithm as though it were a company product. The second is to infer commercial scale from technical influence. Nichols’ work can shape queues across many systems without creating a disclosed recurring business attached to each installation.

The current-role caveat belongs here. Pollere’s public page identifies her as founder and chief executive, but it is not accompanied by a recent dated leadership announcement. The role can be reported as the company’s public description with that limitation rather than silently converted into a freshly verified appointment.

CoDel followed RED without erasing the value of earlier AQM

CoDel belongs to an active queue-management lineage that includes Sally Floyd and Van Jacobson’s Random Early Detection. RED proposed signalling congestion before overflow by tracking average queue size and probabilistically dropping or marking as the average crossed configured thresholds. It was a foundational move away from tail drop.

RED also exposed an operational problem. Thresholds, averaging and drop probability interact with capacity, round-trip times and traffic. A carefully configured deployment can behave well. A generic device default can be too timid, too aggressive or effectively inactive. The difficulty contributed to uneven adoption and to later efforts to design more self-adjusting controllers.

Nichols’ work should not be narrated as a correction by one generation that rendered Floyd’s work obsolete. RED established the case for active queue management and early congestion signalling. CoDel changed the observed variable and the way signalling intensity was controlled. Both designs were collaborative and arose from the same broad concern: waiting for buffer overflow is a poor way to govern a feedback network.

The comparison clarifies CoDel’s contribution. RED estimates congestion from average occupancy. CoDel estimates persistent queue delay from the recent minimum sojourn time. RED typically requires configured minimum and maximum thresholds and a maximum marking or drop probability. CoDel uses a target, interval and stateful control law intended to work under normal defaults.

Neither algorithm can overcome a missing feedback loop. Both depend on responsive traffic or complementary scheduling and policing. Both can be placed on the wrong queue. Both can be misrepresented by a benchmark that changes several system variables at once.

The historical connection also requires precise personal attribution. Jacobson collaborated with Floyd on RED and with Nichols on CoDel. That shared collaborator does not make the two algorithms one project or transfer authorship between the researchers. Floyd’s wider work on ECN, congestion principles and evaluation helped shape the architecture in which CoDel later operated. Nichols’ design addressed a specific controller and deployment problem.

A senior-journalist account gains more by preserving that continuity than by declaring a winner. Infrastructure evolves through mechanisms that expose the limitations of earlier mechanisms. RED made early signalling legitimate. CoDel made persistent waiting time the sensor. FQ-CoDel later combined that controller with flow isolation. Each layer answered a different operational question.

Loaded-latency tests changed what operators could demand

A queue-management algorithm is difficult to evaluate through idle measurements. When no traffic competes for a bottleneck, almost any queue appears low latency. The useful test creates sustained load and observes how much additional delay appears while throughput remains active.

This loaded-latency perspective connected bufferbloat research with user experience. It made visible the difference between a link’s propagation time and the time added by a queue under pressure. An access product could no longer defend poor interactivity solely by pointing to its speed-test throughput.

The measurement has to be designed carefully. A single ping stream may receive special treatment or may not represent application traffic. One-direction loading can miss the effect of acknowledgements and reverse-path queues. Short tests may not reveal controller convergence. A nearby test server says little about long-path propagation, while it can isolate access queueing more clearly.

Operators should separate several quantities: baseline round-trip time, additional delay during upload, additional delay during download, loss or ECN marking, achieved throughput and recovery after the load stops. A good result is not the minimum possible value in one dimension. It is a defensible balance for the service objective.

CoDel’s internal sojourn measurements and external loaded-latency tests answer different questions. The internal controller knows the wait in one queue. The external test observes the sum of queues and path effects. When the qdisc reports low delay and the external test reports high delay, the discrepancy is evidence of another bottleneck or hidden buffer.

This comparison can guide deployment. An operator can shape at a controlled rate, enable FQ-CoDel, repeat the loaded test and inspect where the delay changed. The process is stronger than assuming that a named algorithm has solved the path simply because the configuration command succeeded.

Product claims need the same discipline. “Supports CoDel” establishes an option. “Uses CoDel by default” establishes a configuration. Neither establishes low latency under the customer’s access technology. The result depends on rate detection, offload, Wi-Fi, firmware, provider scheduling and endpoint behaviour.

Its broader significance of Nichols’ work is that it made a local control objective compatible with an external service metric. A queue can be asked to keep its persistent contribution below a target, and the network can be tested under load to see whether that local success reaches the user.

Low latency is a multi-metric result with an exit path

An AQM can reduce standing delay and still be unsuitable if it wastes capacity, penalises some flows or becomes unstable when conditions change. Evaluating CoDel requires several measurements whose trade-offs should remain visible.

Throughput establishes whether the bottleneck stays usefully occupied. Delay should be measured as a distribution, including loaded and tail values rather than only an average. Loss and ECN marking show the cost and form of feedback. Queue occupancy can help explain the mechanism even though it is not CoDel’s principal sensor.

Fairness has several definitions. Flow fairness asks whether concurrent flows obtain comparable shares. User fairness recognises that one application can open many flows. RTT fairness examines whether shorter paths gain an advantage. A sparse interactive flow and a sustained bulk transfer value service differently, which is why flow queueing can matter more than one aggregate delay statistic.

Convergence and recovery deserve separate tests. A controller should respond when load rises and should stop signalling when the queue improves. Variable-rate links, sudden capacity loss and short bursts can expose oscillation or sluggishness hidden in a steady-state benchmark.

The comparison has to hold the rest of the system constant. Replacing tail drop with FQ-CoDel changes both queue management and scheduling. Adding a shaper moves the bottleneck. Disabling offload changes packet representation and CPU cost. Those interventions may be correct, but the report should not attribute the whole result to CoDel alone.

Workload diversity matters as well. Long TCP flows reveal steady feedback. Web-like short transfers emphasise startup and queueing. Real-time traffic tests sparse packets. Unresponsive UDP reveals the need for isolation or policing. Mixed RTTs and bidirectional load expose interactions absent from a single-flow test.

Nichols’ contribution encourages this discipline because the algorithm begins from a measurable objective. The same discipline must be applied to claims about success. Lower local sojourn time is strong evidence about the controlled queue. A useful product result connects that evidence with throughput, fairness and end-to-end experience under stated conditions.

Queue policy can fail through a kernel regression, an inappropriate default or an unexpected interaction with hardware. Operators should be able to compare the new qdisc with the previous state, roll back without losing management access and preserve evidence from the failing period.

The rollback is not simply a command. Replacing a qdisc changes queued packets and can cause a transient loss or burst. A shaper may have moved the bottleneck, so removing it can refill a hidden modem queue and make latency worse even though the earlier configuration has been restored.

A controlled deployment records kernel, driver, offload, target, interval, shaping rate and traffic mix. It measures before and after under load and keeps the same test after software upgrades. That evidence distinguishes an algorithm problem from a changed link or device path.

CoDel was designed to reduce routine tuning. Operational discipline remains necessary because the queue is an active control point on live traffic.

CoDel’s legacy is the decision to control time rather than occupancy

Queue management continues to evolve. PIE uses another delay-oriented controller. FQ-CoDel combines flow scheduling with CoDel. CAKE adds shaping and fairness policy. L4S and DualQ pursue low-latency service through different ECN semantics and transport expectations. Hardware vendors implement proprietary queue systems whose details may be less visible.

CoDel’s durable contribution is not proof that one algorithm won every comparison. It changed the variable around which many engineers framed the problem. The user experiences time. A queue that remains occupied is harmful because of the delay it creates and the feedback it postpones, not because a particular packet count is morally too large.

The recent-minimum estimator supplied a practical test for whether the queue drains. The control law supplied a response that did not require an operator to set a drop probability. The common defaults sought to make deployment possible without link-by-link expertise.

Those ideas survive even when later systems add flow isolation, richer shaping or different signalling. They also expose their own limits. A controller cannot see a hidden queue. It cannot force an unresponsive sender to cooperate. It cannot decide class policy. It cannot guarantee end-to-end latency.

Nichols’ career gives the mechanism a wider context. DiffServ separated traffic treatment into scalable behaviours. Vendor and startup roles connected architecture to products. Pollere preserved an independent base. CoDel focused that experience on one measurable failure: packets waiting persistently where waiting bought no additional throughput.

A restrained assessment is stronger than a heroic one. Nichols did not single-handedly solve bufferbloat, create FQ-CoDel or define all modern AQM. She co-designed a controller whose measurement and operating ambition altered the field’s practical vocabulary.

The most useful sentence an operator can take from the work is also the most demanding: find the real bottleneck, measure the time packets spend there and signal before the queue becomes a permanent part of the path.