Summary

  • NQB is not a fast-lane coupon. RFC 9956 gives smooth, low-rate microflows a shallow best-effort queue because their packet pattern can be observed and tested.
  • Queue protection can reclassify or discard traffic that builds the protected queue; L4S separately requires scalable congestion control, ECT(1) signalling and compatible network marking.
  • The useful product measure is loaded end-to-end latency across the sender, access link, gateway and Wi-Fi, with evidence of marking, fallback and reclassification.

Start with a broadband line sold at one gigabit per second. A laptop begins a backup. The line is nowhere near its monthly allowance and the interactive application uses little bandwidth, yet its small packets wait behind a burst at the narrowest queue. An unloaded speed test remains immaculate. The user experiences delay.

That is the problem the IETF’s new Non-Queue-Building treatment addresses. RFC 9956, published as a Proposed Standard in May 2026, defines a shallow-buffered best-effort service for smooth, low-rate, application-limited microflows. Voice, game-state updates, DNS and some machine-to-machine traffic can qualify. A capacity-seeking transfer should not.

The distinction is more important than the label. NQB does not mean “important application”. It means the packet stream claims it will not materially build the queue. The RFC says this claim is observable. A sender whose traffic exceeds the defined behavioural bound must not apply the NQB DSCP. A supporting node must put NQB traffic in a queue separate from Default traffic and should protect that queue from flows that do not behave as claimed.

This is best effort with a burden of proof, not a paid priority lane. The shallow queue gives compliant packets less waiting time precisely because it is not allowed to become another deep queue.

A mark can be revoked by behaviour

The protection boundary is unusually concrete. RFC 9956 recommends that a network element detect packet patterns inconsistent with NQB and either move the offending traffic back to the ordinary queue or discard it. It advises judging the actual arrival behaviour rather than application names, port numbers or addresses. The most useful observer is the bottleneck itself: that is where queue growth becomes visible.

RFC 9957, also published in May 2026, explains one DOCSIS Queue Protection algorithm. It is Informational, not an Internet Standards Track specification. The mechanism measures delay in the low-latency queue, maintains a per-flow queuing score and sanctions packets when both queue delay and that flow’s contribution cross thresholds. Reclassification to the Classic queue is the normal action.

The economic implication is easy to miss. The application may choose the mark, but the access device decides whether the observed behaviour still earns the treatment. Equipment software, thresholds, counters and upgrade support become part of the service contract. Two broadband products can advertise the same line rate and process the same marked packet differently.

L4S is a parallel contract, not a synonym

NQB can share a low-latency queue with L4S traffic, but the contracts differ. The L4S architecture joins three things: a scalable congestion controller at the sender, fine-grained congestion marking at the bottleneck and a protocol between them. RFC 9331 uses ECT(1) in the IP ECN field to identify traffic claiming the required scalable response. RFC 9332 describes a Dual-Queue Coupled AQM that isolates low delay while coupling congestion signals so Classic and L4S traffic continue to draw from shared capacity.

That coupling matters. A strict priority queue would invite every application to ask for the front. DualQ instead tries to isolate waiting time without granting unbounded bandwidth preference. NQB relies on an application-limited pattern; L4S relies on a sender that reacts frequently and proportionally to congestion marks. Both can fail if the label survives but the claimed behaviour does not.

RFC 9331 therefore preserves a way back. A sender must monitor coexistence with Classic ECN behaviour and, when a coexistence problem is detected and the network has not repaired it, revert to Classic congestion control. “L4S enabled” is not a lifetime entitlement for every path.

The modem is not the end of the path

An access operator can deploy the correct queue and still lose the result inside the home. CableLabs’ Wi-Fi work says Wi-Fi is frequently an end-to-end bottleneck. Media-access delay joins ordinary buffering, and performance changes with distance, contention, access-point implementation and client mix. CableLabs published an experimental NS-3 model and describes simulations plus field tests with a Nokia access point. These are useful reproducible and bounded tests, not a global performance baseline.

The IP header can also lose its meaning in transit. Apple’s implementation guidance warns operators not to erase or alter ECN accidentally while clearing DSCP, because the fields share the traffic-class byte. Apple says iOS 17 and iPadOS 17 support L4S for some users in their QUIC and TCP stacks. That statement proves a platform capability boundary; it does not prove that the user’s access link, gateway and Wi-Fi preserve it.

The commercial rollout is no longer hypothetical. Comcast said in January 2025 that it was rolling out Low Latency DOCSIS/L4S with application collaborators, and that application marking was voluntary, carried no special cost and required no proprietary API. This is evidence of one operator’s design and product claim. It is not evidence of universal coverage, one fixed improvement or identical behaviour on every home network.

What would disprove the thesis

The claim should be tested with the line loaded, not admired from a standards diagram. Compare p50, p95 and p99 round-trip delay and loss for eligible flows with the low-latency treatment on and off. Introduce a deliberately mis-marked, queue-building flow. Repeat across wired access and Wi-Fi, with ECN preserved and bleached, and with different gateway software.

The behavioural-contract thesis is weakened if separate queueing does not change loaded delay, if a mis-marked bulk flow cannot damage the shallow queue even without protection, if preservation across Wi-Fi and the traffic-class byte does not alter the result, and if implementation choices do not change reclassification or fallback. The present sources do not establish global NQB share, typical sanction rates or a universal customer gain. They establish a mechanism that operators can falsify.