Summary

  • RFC 9956 defines NQB as shallow-buffered best effort with forwarding preference comparable to Default; DSCP 45 reports an expected sending pattern, not application identity, priority or an end-to-end latency guarantee.
  • Traffic protection is an automated local policy decision. Classification, observed queue harm, the grouping of packets into a flow record and the choice to pass, reclassify, re-mark or discard are separate facts.
  • Operators need a privacy-bounded queue-protection decision trace that can reproduce representative actions without retaining payloads or permanent cleartext flow histories. This is editorial guidance, not an IETF or CableLabs requirement.

The mark makes a narrow claim

The most important sentence in RFC 9956 is not the assignment of decimal codepoint 45. It is the boundary around what that codepoint means. The Non-Queue-Building Per-Hop Behavior is a shallow-buffered, best-effort complement to Default best effort. A supporting node is not promising a data rate or a broad delay target. It is separating traffic whose own packet pattern should not materially build a queue from bursty or capacity-seeking traffic that needs different buffering.

That distinction matters because “low latency” is easily sold as a service tier. NQB is designed on another basis. RFC 9956 recommends equivalent forwarding preference for NQB and Default. The shallow queue can protect smooth, low-rate transactions from standing queues without granting them priority over everyone else. The sender obtains the benefit by meeting an observable behaviour condition; the network does not confer it merely because a bit pattern asks.

The mark therefore says less than several parties may wish to hear. It does not identify an application. It does not prove benign intent. It does not establish that an upstream radio, PON, Wi-Fi or cable link will avoid introducing a burst later. It does not prove that every domain will preserve the DSCP or implement NQB. It does not promise that a tunnel will carry a re-marking through decapsulation. And it does not make a latency result end-to-end.

This is a useful restraint. A narrow, testable claim can survive operational disagreement better than a grand promise. The public statement should be: “this microflow is expected to behave within the NQB sender envelope.” Everything after that must be observed locally.

Protection is not classification

RFC 9956 deliberately permits implementations to innovate in traffic protection. A node can observe traffic that was admitted to its NQB queue and act when the traffic is inconsistent with the sender requirements. Reclassification to Default is one option. Discard is another, with a recommendation for a higher threshold because loss is more damaging than the delay variation and reordering that reclassification can create.

This means the outcome cannot be reconstructed from the mark alone. First, a classifier decides which queue receives the packet using DSCP, ECN and possibly local fields. Second, the bottleneck sees a queue condition that the sender could not observe in advance. Third, an implementation groups packets into a behaviour record. Fourth, policy chooses the threshold and consequence. A dashboard that records only “NQB packet reclassified” compresses all four stages into a result without its reasons.

RFC 9957 is valuable because it exposes one concrete decision loop. It describes DOCSIS Queue Protection, or QProt, as a mechanism-policy split. The mechanism finds a flow record and accumulates a score related to the traffic’s contribution to queuing. Policy asks whether there is actual shared-queue harm and whether the score is high enough to act. In the described DOCSIS case, the packet is redirected from the Low-Latency queue to the Classic queue.

The document is equally valuable for what it refuses to conceal. RFC 9957 is an Independent Stream Informational document, not an IETF Standards Track specification. The normative QProt rules reside in CableLabs’ DOCSIS specifications. Its parameters can change. Its policy is more likely than its mechanism to evolve. A reader who treats the RFC pseudocode as a permanent global contract would erase the very version boundary an audit needs.

The flow is an assumption

Automated enforcement always contains a unit of judgment. For QProt, that unit is usually a Layer 4 five-tuple. Encapsulation may reduce it to a four- or three-tuple, or expose an IPsec Security Parameter Index. A bounded bucket table holds the resulting state.

RFC 9957 calls the grouping pragmatic and says there is no scientific basis for allocating responsibility per application flow. That candour should shape operations. One visible flow can contain media, control and data. A VPN can aggregate many applications behind the same tunnel endpoints. Two implementations can observe the same packets yet distribute their behaviour records differently because they recover different headers.

State pressure adds a second ambiguity. When the dedicated buckets cannot hold more live flows, traffic can share a default “dregs” bucket. Resource-exhaustion attacks can raise the chance that innocent, non-queue-building traffic is reclassified. The intended consequence is not catastrophic: affected packets move to the Classic queue rather than disappearing. Yet reordering and added delay remain real, and they can be operationally significant for a tunnel or real-time exchange.

The honest record must therefore preserve the grouping rule and the state condition, not just the score. “Flow exceeded threshold” is incomplete if the flow was a tunnel, the identifier was reduced, or the score came from a shared bucket under pressure.

Visible congestion is part of legitimacy

QProt uses the same Native AQM probability that drives ECN marking to weight the queuing score. For responsive, ECN-capable traffic, that choice exposes part of the network’s evidence back to the sender. RFC 9957 argues that this visibility is necessary if an end system is to stay objectively on the safe side of the algorithm.

That is a strong governance design. The network does not need to reveal a subscriber, topology map or proprietary implementation to publish the basis on which compliant behaviour can be recognized. But external visibility is partial. Non-ECN traffic does not receive the same signal. The sender cannot see bucket collisions, local policy revisions or all link-induced burst formation. A public condition and a private implementation trace must meet somewhere if a disputed action is to be reproduced.

RFC 9956 already requires useful operator statistics, including counters that can reveal drops or abuse. Those counters answer “how much.” They may not answer “why this cohort, now.” The gap should be closed without turning queue management into surveillance.

A trace that preserves the decision, not the communication

A queue-protection decision trace should be event-triggered or sampled. Continuous packet capture is neither necessary nor proportionate. The trace should bind the observation window and logical bottleneck to the software or firmware build, NQB/Default scheduler, shallow-buffer configuration, policy revision and thresholds.

It should then record the decision chain:

  1. the observed DSCP and ECN state, plus any local classifier and tunnel model that affected admission;
  2. a rotating keyed representation of the grouping, with the declared basis—five-tuple, reduced tuple, SPI or shared bucket—rather than a permanent cleartext subscriber identifier;
  3. queue delay, the relevant AQM probability or equivalent congestion signal, the current behaviour score, aging rule and state-capacity pressure;
  4. the exact policy condition that fired and whether actual queue harm was present;
  5. the action—pass, packet reclassification, whole-flow action, re-mark or discard—and any hysteresis or idle timer;
  6. expected side effects, especially loss, delay variation and reordering;
  7. bounded cohort counters for conforming synthetic traffic, shared-bucket use, exhaustion and action rate;
  8. the retention window, access rule, replay trigger, accountable threshold owner and rollback authority.

The rotating linkage key should expire with the diagnostic need. Packet payloads should never enter the record. Public reporting can remain aggregate: action rate by build, direction and policy; false-action results from synthetic tests; queue-delay distribution; shared-bucket pressure; and whether a cohort was disabled or rolled back. More detailed traces should remain controlled and short-lived.

This is not a proposal for a new wire protocol. It is a way to stop three statements from collapsing into one: the packet made a behavioural claim; the node observed a local condition; the policy imposed a consequence.

Test the cases that can reverse the story

A meaningful acceptance test does not compare only smooth traffic with an obviously abusive sender. It runs the same corpus through every materially distinct build and threshold set. It includes a compliant low-rate stream, responsive scalable traffic, a high-rate capacity seeker and short bursts created both by the application and by an upstream discontinuous link.

It also changes what the node can see. Test an ordinary five-tuple, an encrypted tunnel, a reduced identifier and a deliberately exhausted state table. Compare packet-by-packet reclassification with hysteresis. Measure not only the action count but the resulting reordering, loss and delay. On lower-rate links, confirm that disabling NQB treatment carries the marked traffic as Default without needlessly erasing the DSCP.

The result is not a certificate that NQB “works.” It is a bounded statement: under this build, queue, link cohort and policy, these observed patterns produced these actions and side effects. That is the minimum claim evidence can carry.

Limits

No source in this packet measures present deployment, mis-marking, false reclassification or customer harm. No operator, vendor, access technology or application is accused of an error. “Entitlement” is a service-governance metaphor, not a legal right. RFC 9957’s example settings are not asserted to be current CableLabs defaults everywhere.

A decision trace cannot make an unsuitable algorithm fair. It cannot establish application intent from a port or address, and it cannot prove treatment at another hop. Its value is narrower: after short-lived state has vanished, it lets an operator say what this node saw, which policy acted and what consequence followed—without preserving the communication itself.

Sources