A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services
updates
- rfc-8325 — Mapping Diffserv to IEEE 802.11
Extracted elements (29)
DSCP value 45 (decimal, binary 101101) was chosen because its three most significant bits (101) cause existing Wi-Fi equipment using the default DSCP-to-UP mapping to classify it into the Video Access Category (AC_VI), achieving separate queuing from Default traffic even on non-upgraded equipment. It also simplifies range-based aggregation in network equipment (DSCPs 40–47 share the MSBs 0b101).
The NQB PHB differs from Expedited Forwarding (EF, RFC 3246) in that NQB has no guaranteed minimum rate requirement and no requirement to police incoming traffic to such a rate. NQB traffic is given the same forwarding preference as Default traffic, whereas EF is a premium service with rate guarantees and associated policing requirements.
The NQB PHB is designed without prioritization and without reserved capacity relative to Default traffic, giving NQB and Default traffic equal forwarding preference. This incentive-alignment design means mis-marking QB traffic as NQB provides no capacity benefit and typically causes degradation (shallow buffer loss, out-of-order delivery), eliminating the need for access control or admission control mechanisms that complicate traditional Diffserv deployments.
Traffic protection is placed at PHB nodes (not just domain ingress edges) so it can monitor the actual NQB queue and act only when a queue begins to form. Edge-only policing is simultaneously too lenient (cannot guarantee ≤100 NQB flows per internal bottleneck) and too strict (would police based on minimum link capacity, not actual bottleneck capacity).
Existing Wi-Fi equipment using the default DSCP-to-UP mapping (RFC 8325, Section 2.3) maps DSCP 45 to UP 5, placing it in the Video Access Category (AC_VI), which provides statistical prioritization over Best Effort (AC_BE). This achieves separate queuing from Default traffic but violates the equal-forwarding-preference recommendation. Wi-Fi equipment SHOULD map DSCP 45 to a separate queue in UP 0 (AC_BE); if unavailable, MAY map to UP 3.
Reordering-sensitive tunnel protocols (e.g., IPsec, L2TP) carrying a mix of QB and NQB traffic must use a non-NQB DSCP on the outer tunnel header (e.g., Default), because NQB traffic protection and shallow buffer overrun responses can introduce out-of-order delivery. The 'pipe' tunnel model is preferable in this case as it preserves inner DSCP differentiation at decapsulation.
The NQB DSCP and PHB are defined to operate independently of L4S (RFC 9330), but NQB traffic is intended to be compatible with L4S such that NQB-marked traffic and L4S traffic can share the low-latency queue in an L4S DualQ node. Applications complying with both NQB sender requirements and Prague L4S requirements may mark packets with both NQB DSCP and ECT(1).
This document updates RFC 8325 by adding 'Non-Queue-Building' traffic to Section 4.2.9 and inserting a new row in the DSCP-to-802.11 mapping table: NQB (RFC 9956) maps to UP 0 or 3 in AC_BE (Best Effort), or UP 5 in AC_VI (Video) if a separate AC_BE queue cannot be provided.
A node supporting the NQB PHB MUST provide statistics (e.g., packet and drop counters) enabling network operators to detect whether abuse or mis-marking is occurring in the NQB queue.
A node supporting the NQB PHB SHOULD NOT rate limit or rate police the aggregate of NQB traffic separately from Default traffic. The NQB queue SHOULD be given equivalent forwarding preference to the Default queue, e.g., via a Deficit Round-Robin (DRR) scheduler with equal weights.
Applications are RECOMMENDED to use DSCP value 45 (decimal) to mark microflows as NQB. This value was chosen partly to achieve separate queuing in existing Wi-Fi networks and to simplify range-based DSCP classification in network equipment.
Applications MUST NOT mark traffic with the NQB DSCP if the microflow's traffic exceeds the rate equation (bytes ≤ R*T + MTU, where R is 1% of typical path capacity). Exceeding this rate risks traffic protection penalties or shallow buffer overflow causing packet loss or out-of-order delivery.
By default, a node supporting the NQB PHB SHOULD classify packets marked with DSCP value 45 (decimal) into the NQB queue. A node MUST support the ability to configure the DSCP used to classify packets into the NQB queue, and MAY support multiple configurable DSCPs for this purpose.
For links with data rates less than 10% of typical path rates, it is RECOMMENDED that the NQB PHB be disabled and that traffic marked with the NQB DSCP be carried using the Default PHB (without being re-marked to DSCP 0), since NQB sender rate assumptions may not hold.
For traffic protection algorithms that discard offending traffic, it is RECOMMENDED that decision thresholds be set higher than for reclassify-based designs, because packet discard causes greater communication degradation than out-of-order delivery.
In nodes supporting both the NQB PHB and L4S, L4S network functions SHOULD treat packets marked with the NQB DSCP and ECT(1) or CE the same as packets marked with the Default DSCP and the same ECN value, enabling NQB and L4S traffic to share the low-latency queue in a DualQ node.
Network elements that support the NQB PHB SHOULD support a traffic protection function to identify and reclassify or discard microflows inconsistent with NQB sender requirements. The traffic protection function MUST NOT base its decisions on application-layer constructs (port numbers, IP addresses); it MUST be designed such that the node does not fail if per-microflow state is exhausted.
Networks and nodes that do not support the NQB PHB are RECOMMENDED to treat traffic marked with the NQB DSCP the same as Default DSCP traffic, and SHOULD NOT re-mark NQB-marked packets with a different DSCP, so that downstream hops can still provide NQB PHB treatment.
NQB network functions (traffic protection and re-marking/policing for non-DS-capable domains) MUST treat packets marked with the NQB DSCP uniformly, regardless of the value of the ECN field.
The NQB queue MUST have a buffer size significantly smaller than the buffer provided for Default traffic; it is RECOMMENDED to configure an NQB buffer size less than or equal to 10 ms at the shared NQB/Default egress rate. A similarly deep NQB buffer would undermine the low-latency goal and erode incentives for correct marking.
When a traffic policing or rate-shaping function is applied to NQB traffic destined to a non-DS-capable domain, the policer/shaper rate SHOULD be set to either 5% of the interconnection data rate or 5% of the typical rate for such interconnections (whichever is greater), with excess traffic re-marked for Default forwarding or dropped. Burst tolerance SHOULD be approximately 100 ms for policing, 10 ms for shaping (with no more than 50 ms of buffering).
When delivering traffic into a non-DS-capable domain, network equipment SHOULD by default re-mark NQB traffic to DSCP 0 (Default) and SHOULD support the ability to change or disable this re-marking. Alternatively, a traffic protection or policing function MAY be used; if traffic protection is used, it MUST re-mark or discard offending traffic to DSCP 0.
NQB sender eligibility requires that a microflow send non-bursty traffic at a data rate no more than approximately 1% of the typical network path capacity (e.g., 500 kbps when access network rates are ~50 Mbps), transmitted in a smooth (paced) manner where IP bytes in any interval T satisfy: bytes ≤ (R * T) + MTU. Microflows are unidirectional; an application may have some NQB-eligible and some non-eligible microflows.
The Non-Queue-Building Per-Hop Behavior (NQB PHB) provides a shallow-buffered, best-effort service as a complement to the Default deep-buffered, best-effort service. It isolates low-data-rate, application-limited microflows (e.g., interactive voice, game sync, DNS) from bursty, capacity-seeking traffic to reduce delay and loss for those flows. The PHB is implemented without prioritization and can be implemented without rate policing.
The traffic protection function is a per-node mechanism that identifies microflows inconsistent with NQB sender requirements (Section 4) and either reclassifies them to the QB (Default) queue or discards offending traffic. It SHOULD base decisions on actual microflow behavior (packet arrival patterns and observed queuing delay), not application-layer constructs such as port numbers or IP addresses. Implementations may optionally re-mark offending traffic to Default DSCP to propagate the decision downstream.
IANA has assigned DSCP value 45 (decimal), binary 101101, with name 'NQB' from DSCP Pool 3 Codepoints (Codepoint Space xxxx01) in the 'Differentiated Services Field Codepoints (DSCP)' registry, under Standards Action, referencing RFC 9956.
A QB microflow mis-marked as NQB can contribute to NQB queue formation, causing queuing delay and/or loss for all other microflows sharing the NQB queue. Full NQB PHB support with traffic protection limits incentives for this mis-marking, since mis-marked QB traffic typically experiences degradation (excessive packet loss, delay variation, out-of-order delivery) rather than benefit. If traffic protection is absent, a mis-marked QB flow can degrade all NQB traffic sharing the shallow buffer.
The Diffserv DS field has no integrity protection; an on-path attacker can re-mark the DSCP. Malicious re-marking of NQB traffic could negatively affect QoS for tampered microflows, though this is a general Diffserv limitation and not specific to NQB. On-path attackers can cause greater harm by modifying other mutable IP header fields (e.g., TTL).
Traffic protection mechanisms that maintain per-microflow state are vulnerable to flow-state exhaustion attacks. This document requires that traffic protection be designed such that the node does not fail (e.g., crash) if microflow state is exhausted, for example by limiting resources dedicated to tracking misbehaving flows.