Summary

  • RFC 9332's DualQ framework uses separate L4S and Classic queues with coupled congestion signalling. ECT(1) and CE supply the L4S identifier, but the identifier is not a telemetry record of the queue a packet actually entered.
  • An operator may steer an L4S-identified packet away from the low-latency queue while preserving its end-to-end identifier, and may admit selected non-L4S traffic to the low-latency queue without turning it into L4S traffic.
  • Bob Briscoe's work, shared with Koen De Schepper and Greg White, is operationally useful because the Experimental RFC also names the missing witnesses: per-queue traffic, marks, drops, mean delay, 99th-percentile delay and overload episodes.

A label arrives without a travel diary

Picture a packet capture at the edge of a customer network. The ECN field contains ECT(1). A dashboard reads that bit pattern, finds the L4S definition and writes a green label: “low latency.”

The first observation is valid. The conclusion is not yet earned.

ECT(1) tells an L4S-aware network node how the packet identifies itself for the experimental L4S service. It can be a default input to classification. It does not contain a list of the queues the packet visited, the classifier rules that matched, the Active Queue Management decisions applied, the time spent waiting, or the bottleneck that dominated the journey. A two-bit field cannot be an end-to-end performance history.

RFC 9332 makes this boundary unusually visible. Published in January 2023 as an Experimental RFC, it defines a framework for a Dual-Queue Coupled AQM: an L queue for L4S treatment, a C queue for Classic traffic, an AQM for each and a coupling mechanism intended to let different congestion-control families share capacity. The scheduler must give L4S traffic priority, but the priority must be bounded so Classic traffic cannot be starved.

The document's ambition is real. Its abstract describes consistently very low queuing latency, very low congestion loss and scalable throughput. Yet the protocol design does not ask operators to infer those outcomes from the identifier. It asks an experimental implementation to measure the queues.

The identifier survives a local refusal

RFC 9331 defines ECT(1), together with CE in the relevant circumstances, as the L4S identifier. A sender that uses the identifier is expected to satisfy the L4S congestion-control requirements. An L4S node normally classifies ECT(1) for L4S treatment.

“Normally” does important work. RFC 9332 allows an operator, for policy reasons, to steer selected packets out of the L queue even when they identify themselves as L4S. The node must not erase or rewrite the end-to-end L4S identifier merely because local treatment differs. A downstream operator remains free to make its own classification decision.

This produces a state that a simple dashboard often cannot express:

ECT(1) observed; classified to C at node X under policy Y; identifier preserved.

Nothing about that state is internally inconsistent. The identifier records an endpoint-side protocol claim. The classifier records a local decision. Preserving both facts is more informative than forcing one to masquerade as the other.

The inverse is possible too. An operator may use other identifiers—selected addresses, Diffserv codepoints or protocols such as DNS—to place additional traffic in the L queue when doing so is judged not to harm the service. RFC 9331 and RFC 9332 do not permit the node to convert Not-ECT or ECT(0) into the L4S identifier merely because the packet received local low-latency treatment.

So queue membership does not manufacture L4S identity, and L4S identity does not prove queue membership at every hop. The join is many-to-many across operators and time. It has to be observed where the decision occurs.

Two queues are a control system, not two coloured lanes

The DualQ design is more than priority scheduling. Classic congestion controls need enough queued data to avoid underusing a link, while Scalable controls can respond to frequent ECN signals with much smaller rate variations. Mixing both behaviours in one queue creates an unfairness problem: a Scalable control can be far more aggressive than a Reno-friendly one.

DualQ separates their queueing delay but couples their congestion signals. In the explanatory design, the Classic AQM produces a base probability. Its squared form drives Classic drop or marking, while a scaled form becomes a coupled signal for L4S traffic. The L queue uses whichever is greater: its native signal derived from immediate L-queue delay or the coupled signal derived from pressure in the Classic queue.

This is why an ECN mark is not a latency sample. It is an instruction generated by a control system. The mark may reflect the L queue's own dynamics, congestion imported through the coupling, or an overload response. Its meaning is to make an endpoint adjust. The elapsed wait of a particular packet is a separate observation.

Classification mismatches reinforce the point. If an ECT(1) packet is placed in the Classic queue, RFC 9332 says the Classic AQM should mark it with the coupled probability. If ECT(0) appears in the L queue, the L AQM should use treatment appropriate to Classic congestion control and the L-queue delay target. For Not-ECT in the L queue, behaviour depends on whether another mechanism protects the queue from misbehaving flows.

The implementation therefore cannot be audited by counting ECT(1) packets alone. It needs to know which branch handled each unexpected combination and why.

Low latency has more than one clock

Even a correct L-queue receipt proves only one component of the user's experience.

RFC 9332's monitoring language defines queue delay narrowly. It excludes serialization delay for the packet at the head of the queue and medium-acquisition delay. It also cannot include propagation, delay in other network nodes, transport recovery, server scheduling or application work. A packet can wait for microseconds in one DualQ and still experience a long end-to-end response.

The reverse can happen as well. A short Classic packet may traverse an empty queue quickly. It did not become an L4S flow merely because its observed delay was small.

This is why averages are not enough. The RFC says an experimental implementation should allow operators to derive mean and 99th-percentile queue delay for each queue and sample interval; it may also retain a maximum for diagnosis. An average can remain low while a small number of packets encounter a damaging tail. A maximum without a sample window can turn one old anomaly into a permanent status. The measurement needs the statistic, boundary, interval and denominator.

The same discipline applies to location. Deploying a DualQ at one access bottleneck may address an important source of queuing. It does not prove that a different bottleneck, Wi-Fi scheduler, tunnel endpoint or upstream interface treated the packet the same way. “L4S-capable path” is a claim about a chain of actors, not a property that one box can unilaterally certify.

Overload changes what the service can preserve

Under ordinary responsive load, the coupling is meant to let L4S traffic retain a shallow queue without starving Classic flows. Unexpected traffic and overload force harder choices.

The L queue's priority must be conditional. Otherwise a continuously busy L queue could briefly starve a small set of Classic packets, such as a DNS request or an initial window. RFC 9332 describes schedulers that can protect Classic traffic by sacrificing some L4S throughput or by allowing some delay to cross the boundary.

Persistent overload creates another limit. ECN marking can saturate at 100 percent; beyond that, a system cannot signal more strongly by adding another mark. The RFC requires a DualQ implementation that detects overload to introduce Classic drop to both kinds of ECN-capable traffic until the episode subsides. It also says the implementation should report the start and duration of overload, with hysteresis to avoid an event storm.

An ECT(1) counter cannot disclose this transition. A packet can retain the same identifier before, during and after overload while its queue, drop risk and observed delay change materially. A credible status page needs an overload state and a time window, not a timeless L4S badge.

Bob Briscoe's boundary is collective work

RFC 9332 names Koen De Schepper, Bob Briscoe and Greg White as authors, with Briscoe serving as editor. Its acknowledgements and contributors record a much wider technical community. The document does not support a story of a lone inventor, and this article does not assign Briscoe control over any operator's deployment.

The official IETF Datatracker captured for this article lists Briscoe's long record of congestion-control, ECN and transport work. His own site supplies a public biography and portrait. Those sources establish the person and the documentary record, not current market share or the behaviour of a named network.

His relevance here is the precision of the boundary. The specification gives one small shared identifier a stable end-to-end meaning while leaving operators room to make local classification choices. It then requires operational statistics that expose what the shared bit cannot say. This is close to Heng Lu's Minimum Initial Specification: standardize the smallest interoperable signal, leave future and local decisions with the actors that possess the relevant context, and do not confuse that delegation with absence of accountability.

Running-Code Primacy adds the audit rule. An RFC, a codepoint and a configuration prove that a mechanism is available. The implementation proves which branch ran. The queue proves where the packet waited. The measurement proves how long. Publication cannot supply those later receipts on the implementation's behalf.

The agency problem appears when the easiest fact receives the strongest label. A vendor can expose an ECT(1) count cheaply. An access provider bears more cost to export classifier versions, per-queue counters and tail delay. A customer bears the service risk. If procurement accepts “L4S enabled” without naming the runtime evidence, the actor that reports the cheapest metric controls the claim while other actors absorb the uncertainty.

Six receipts for an honest low-latency claim

The first receipt belongs to the sender. It records the transport, congestion-control implementation and version, the decision to set ECT(1), the flow or session boundary and the relevant time. It proves that the identifier was intentional, not that the path honoured it.

The second is a packet-boundary receipt. It records the observed ECN field, encapsulation context, interface, direction, timestamp and capture integrity. It proves what crossed one boundary. Tunnels and later CE marking make the observation point essential.

The third is the classifier receipt: device and software version, policy revision, matched rule, alternative identifiers and the resulting L or C placement. This is where local discretion becomes an auditable event.

The fourth is the queue receipt. It identifies the actual queue and AQM instance, enqueue and dequeue observations, scheduler choice and whether an unexpected ECN/queue combination invoked a special branch.

The fifth is the congestion receipt. It joins native and coupled signal state to CE marks, non-ECN drops, ECN drops, overload entry and exit, and the counts of packets arrived, presented to the AQM and forwarded. Those three packet counts separate tail discard from proactive AQM discard.

The sixth is the performance receipt. Per queue, it records utilization, mean delay, 99th percentile, optional maximum, sample interval and histogram definition. End-to-end RTT and application response time remain separate measurements with their own clocks and boundaries.

None of these receipts invalidates the L4S identifier. Together they let it carry exactly the authority the protocol gives it—and no more.

Sources