5. NQB PHB Requirements

A node supporting the NQB PHB MUST provide a queue for NQB traffic separate from the Default queue. It SHOULD NOT rate limit or rate police the aggregate of NQB traffic separately from Default traffic, except for the non-DS-capable-domain case in Section 6.4.1.

The NQB queue SHOULD receive forwarding preference equivalent to Default. Schedulers such as equal-weight DRR, or Wi-Fi queues with equal EDCA parameters, are examples. Nodes with Default rate limits or guarantees SHOULD share those limits or guarantees equally with NQB traffic.

By default, a node SHOULD classify DSCP 45 into the NQB queue. It MUST support configuring the DSCP used for NQB classification and MAY support multiple DSCPs. The NQB queue MUST have a buffer significantly smaller than the Default buffer; an NQB buffer size of at most 10 ms at the shared NQB/Default egress rate is RECOMMENDED.

Nodes MUST provide statistics such as packet and drop counters so operators can detect abuse or mis-marking. Equipment serving multiple users SHOULD support per-user capacity and forwarding-resource provisioning, and SHOULD enforce per-user limits over the aggregate of NQB and QB traffic.

Traffic protection is a central safeguard. NQB PHB elements SHOULD support a function that identifies microflows or packets inconsistent with Section 4 and either reclassifies them to the QB queue or discards them. If reclassification is used, an implementation MAY also re-mark the traffic to Default or another local-use codepoint. The function SHOULD NOT base decisions on application-layer constructs; it should use actual microflow behavior. It MUST be designed so exhausting flow state does not crash or otherwise fail the node.

Link technologies that introduce burstiness, such as PON, Wi-Fi, LTE/5G, and DOCSIS, benefit from limiting bursts for NQB traffic. NQB network functions MUST treat packets marked with the NQB DSCP uniformly, regardless of ECN field value.