RFC 9956
A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services
RFC 9956: A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services 💖
okay bestie, grab a drink because this one is SO good 🦋 It's an Internet Standards Track document from the IETF, written by G. White (CableLabs), T. Fossati (Linaro), and R. Geib (Deutsche Telekom) 🎀. It's dated May 2026, and it's an ISSN 2070-1721 doc, so you know it's official ✨. It updates RFC 8325 (that's the one about mapping Diffserv to IEEE 802.11 Wi-Fi), so this doc is literally changing the guidance over there 👑. Nothing in this title block says it obsoletes anything, so it's not replacing an older RFC, just tweaking one 🌸.
1. Introduction 🌈
okay so the big idea here is the NQB PHB, which stands for "Non-Queue-Building Per-Hop Behavior" 💅 It's a Diffserv PHB that isolates traffic microflows (app-to-app flows, see Section 1.2 of [RFC2475]) that have pretty low data rates and don't materially cause queuing delay or loss themselves 🍓 That isolation means these microflows dodge the delay and drops that other traffic would otherwise cause for them 😭
Think about who's in this group: interactive voice, game sync packets, certain machine-to-machine apps, DNS lookups, and some real-time IoT analytics data 🧚 These are all low-data-rate, application-limited microflows. They're totally different from bursty traffic and high-data-rate traffic that's managed by a classic congestion control algorithm, because those are the ones that cause queuing delay and loss 💀 The doc says "classic congestion control" is defined in [RFC9330] as congestion control that coexists with standard Reno congestion control [RFC5681] 🦋 And in this doc, "Queue-Building" (or "QB") is just the shorthand for microflows that cause queuing delay and loss 🫶
Now the whole problem is kinda relatable. Most packets on access networks are managed by end-to-end congestion control, like Reno [RFC5681], CUBIC [RFC9438], or BBR [BBR-CC] 🔥 These are built to find the path's available capacity (which is often the access link itself), so they overshoot, and a queue builds up at the bottleneck 💜 That queue gives everyone variable delay and packet loss, not just the greedy app 😭 And bottleneck links often have deep buffers (100 ms or more, see [Gettys2012], [Cardwell2017], [WikipediaBufferbloat], and [BBR-CC]) so these congestion controls can use the link well, but the delay gets even worse 🙈
Meanwhile there are low-data-rate apps that don't cause queuing at all, but they still get hit with it just because they share the same bottleneck 💔 A lot of them are sensitive to delay, jitter, and loss, so their QoE tanks 📉
AQM schemes made for single queues, like PIE [RFC8033], DOCSIS-PIE [RFC8034], PI2 [RFC9332], or CoDel [RFC8289], help delay-sensitive apps, but there's only so much they can do without hurting the throughput of capacity-seeking apps ✨ AQMs have to allow a pretty big amount of queue depth variation so Reno and CUBIC can work, and if they squeezed the queue way tighter, those apps wouldn't fill the link 😩 And flow-queuing systems like fq_codel [RFC8290] could isolate microflows from each other, but they're not right for every bottleneck, partly because they're complicated 🧩
So the NQB PHB is the glow-up 🌟 It lets the bottleneck tell these two classes of traffic apart and queue them separately, so BOTH classes get a good QoE 👑 The NQB PHB is a shallow-buffered, best-effort service that works alongside the Default deep-buffered, best-effort service from [RFC2474] 💖 It's designed mainly for broadband access links (where there's minimal aggregation of traffic), especially when buffers are deep (see Section 3.4) 🎀 If you're wondering about lower-rate links, Section 6.6 has you covered 🦋
Real talk though, the NQB PHB doesn't promise anyone a particular delay or data rate for NQB-marked microflows 🙅 The only real guarantee is the delay bound you get from the shallow buffer 🍓 The low delay and low loss actually come from how the NQB senders behave themselves 🫶 So the isolation only really covers traffic that acts in conformance with the behaviors in Section 3.1 ✨
Sections 6 and 7 are the operator guidance for forwarding traffic marked with the NQB DSCP 💅 They cover how to set up nodes that do support the NQB PHB, and how to handle nodes that don't, so NQB traffic can be forwarded in a way that matches what NQB is for and still works with other nodes and networks 🌸
2. Requirements Language 📜
okay this part is the rulebook for the capital letters 🎀 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 💜 So if you see them in lowercase, they're just regular words, no cap 🙈
3. Context 🧚
3.1. NQB Behavior 🦋
okay so some apps send traffic at relatively low data rates, or in a smooth, steady way, so they're unlikely to exceed the available capacity of the path, even on an inter-packet timescale 🌸 Some of these are transactional, so they might only send one packet (or a few) per RTT 🍓 These apps might only cause tiny, short-lived queues in network buffers, but they still get delay and jitter from sharing a buffer with apps that build big, standing queues 😭 They usually respond to congestion by stopping (or seriously slowing down) their sending, and they get hurt badly by too much delay and jitter 💀 These are the perfect candidates to be queued separately from the apps causing queue buildup, delay, and loss 👑
On the flip side, QB microflows are the ones that probe for link capacity and cause delay and loss as a result 🔥 Think microflows using CUBIC, Reno, or other TCP/QUIC congestion control algorithms in a capacity-seeking way 💅 Other QB microflows are the ones that send at a high burst rate even if their long-term average data rate is much lower 🫶
Part 1 of 11 done, bestie 💖 Sections 3.2 onward (plus the rest of the doc) are still coming, so stay tuned 🦋✨
3.2. Relationship to the Diffserv Architecture ✨
okay so the IETF came up with the Diffserv architecture [RFC2475] 💅 The whole point is that traffic gets marked so everyone can tell what performance it needs, either in a rough way or relative to other traffic (like "this one's priority" 👑). The architecture uses the DSCP field [RFC2474] for this, and loads of RFCs describe what the values mean (those are the Diffserv Codepoints [RFC2474]). They also cover the standard treatments (traffic conditioning and per-hop-behaviors [RFC2475]) you can build to actually meet the needs of traffic marked that way 🎀
Now, this architecture is super powerful and flexible 🦋 It can be set up to meet the needs of loads of different apps and traffic types, or to offer different levels of service. BUT, to meet an app's needs across the entire sender-to-receiver path, every network along that path has to agree on what those needs are and actually want to meet them 😭 It gets harder because these "requirements" aren't strict. Apps just get a bit worse as loss, delay, and/or delay-variation go up. So deciding whether it's worth meeting them for one app can come down to a judgment call: is it okay to let one app get a bit worse so another app gets better? 🙈
It also gets messy because Diffserv PHBs have historically meant ranking service classes against each other. That creates the zero-sum game I mentioned in the last bit 💀 To stop everyone from grabbing the high-priority lanes, you need stuff like access control, admission control, traffic conditioning, rate policing, and/or metering and billing for that traffic. Honestly, those tools can be really hard or straight-up impossible to run on the Internet 😩
Enter the NQB PHB ✨ It was designed to dodge a lot of these problems, which is why it could realistically be deployed across the Internet 🌈 The NQB DSCP is meant to signal behavior you can actually verify, so the sender can ask for differentiated treatment 🔍 NQB traffic also gets its own queue, with forwarding preference equal to Default traffic, and no reserved capacity beyond any minimum capacity it shares with Default traffic 🧚 So the NQB PHB doesn't try to meet specific application performance requirements. Its one and only goal is to keep NQB traffic away from other traffic that causes more loss, delay, and/or delay-variation, given that NQB traffic is itself only a tiny contributor to those problems 💖 The PHB is also built to make it less tempting for a sender to mis-mark its traffic, since there's no extra capacity or reserved capacity on offer 🙅♀️ Put together, these traits get rid of a lot of the trade-offs that come with differentiated service classes in the Diffserv architecture as it was defined before. They also make access control and admission control way simpler, basically just checking that the behavior is verified. Sections 4 and 5.2 go into this more 🫶
So the NQB PHB is for situations where app performance can't be guaranteed across the whole sender-to-receiver path. Which means apps can't really make demands on the network. Instead, lots of apps have learned to make the best of whatever network they're stuck with 🥹 In that context, the NQB PHB is there to give a better network environment to apps that send data at relatively low, non-bursty rates 🍓
Compared to the other standard PHBs in the Diffserv series, NQB is most similar to the Expedited Forwarding (EF) PHB [RFC3246], which also aims to enable services with low loss, low delay, and low delay-variation 🏎️ But unlike EF, NQB has no requirement for a guaranteed minimum rate, and no requirement to police incoming traffic to such a rate. NQB is expected to get the same forwarding preference as Default traffic 💅 Appendix B has a more detailed comparison of NQB and EF if you're nerdy like that 🤓
In nodes that support multiple Diffserv Service Classes, NQB traffic is meant to be handled as part of the Default treatment 🌸 Traffic in this class doesn't get better forwarding treatment (like prioritization) compared to other classes like AFxx, EF, and so on. Still, NQB-marked traffic could (just like other Default traffic) get better forwarding treatment compared to Lower-Effort (LE) [RFC8622]. For example, the NQB queue could be emptied in a priority sequence before the LE queue 🚀
3.3. Relationship to L4S 🦋
Here's the tea: the NQB DSCP and PHB were defined to work independently of the Low Latency, Low Loss, and Scalable throughput (L4S) architecture [RFC9330] 💜 That said, traffic marked with the NQB DSCP is meant to be compatible with L4S [RFC9330], which means NQB traffic and L4S traffic can share the low-latency queue in an L4S DualQ node [RFC9332] 🫧 A network node that complies with the DualQ Coupled AQM requirements (see Section 2.5 of [RFC9332]) is considered enough to support the NQB PHB requirement of fair allocation of capacity between the QB and NQB queues (Section 5). Also, these requirements in turn require compliance with all the requirements in Section 5 of [RFC9331] 📋
Apps that follow both the NQB sender requirements in Section 4 and the "Prague L4S requirements" in Section 4 of [RFC9331] can mark their packets with both the NQB DSCP and the ECT(1) value ✨
In nodes that support both the NQB PHB and L4S, the L4S network functions SHOULD treat packets marked with the NQB DSCP and ECT(1) or Congestion Experienced (CE) the same as packets marked with the Default DSCP and the same Explicit Congestion Notification (ECN) value 🎯 Here, "L4S network functions" means the L4S Network Node functions (see Section 5 of [RFC9331]), plus any mechanisms designed to protect the L4S queue (like the ones discussed in Section 8.2 of [RFC9330]). How an L4S node processes an ECT(0) packet that gets classified into the L queue (for example, because it was marked with an NQB DSCP) is specified in Section 5.4.1.1 of [RFC9331] and Section 2.5.1.1 of [RFC9332] 🧠
And one more thing: Section 5.4 sets requirements for how a node that supports the NQB PHB treats ECN-marked packets 💖
3.4. Applicability 🌈
This PHB is mainly applicable to high-speed broadband access network links, where there's minimal aggregation of traffic and deep buffers are common 🏠
On lots of other links, forwarding NQB-marked packets with the Default treatment might be enough to keep the loss, delay, and delay-variation performance for NQB traffic in good shape 👑 This is generally true on links that don't usually get congested (like plenty of backbone and core network links), and on highly aggregated links (links built to carry a huge number of simultaneous microflows). On those, the burstiness of individual microflows gets averaged out, so it's unlikely to cause much actual delay 😌 Section 6.2 has recommendations for configuring network nodes in those cases 🧚♀️
4. NQB Sender Requirements ✨
Okay bestie, so which microflows are even allowed to wear the NQB DSCP? 💅 Eligible microflows send non-bursty traffic at a low data rate compared to typical network path capacities 🦋. The app itself keeps the rate low, not the network. These microflows send at no more than about 1% of the "typical" network path capacity 🌸. On top of that, they are required to be sent in a smooth (paced) way 🫶, where the number of IP bytes sent in any time interval "T" is less than or equal to (R * T) + MTU, and "R" is the maximum rate from the sentence above, expressed in bytes-per-second 🎀.
For example, right now access network data rates on the Internet are typically around 50 Mbps or more (see Section 6.6 for when that isn't true 👀), and that works out to a 500 kbps upper limit 🧚.
Also, microflows are unidirectional, but app traffic is often bidirectional, so one app instance might have one or more microflows in each direction 🌈. That means some microflows from the same app can be eligible and others can't. For instance, an interactive video streaming app could have a high-bandwidth video stream (not eligible for NQB marking) going one way and a low-bandwidth control stream (eligible for NQB marking) going the other way 😭.
Microflows marked with the NQB DSCP are expected to follow the existing guidance for safe deployment on the Internet, including the stuff about responding to network congestion. Think the requirements in [RFC8085] and Section 2 of [RFC3551] (and peek at the circuit breaker limits in Section 4.3 of [RFC8083] and the inelastic pseudowires description in Section 4 of [RFC7893]) 📚. Just because a microflow's data rate is low compared to typical capacity doesn't guarantee there's enough capacity in any particular network 🙈. It's the application's job to detect and react appropriately if the network capacity isn't enough. To be clear, nothing in this document means apps making NQB-marked microflows are exempt from that responsibility 🚫. One way an NQB-marking app can handle this is by implementing a scalable congestion control mechanism as described in [RFC9331] 💜.
The DS field spec requires a recommended DSCP to be linked to each standardized PHB (see Section 5 of [RFC2474]) 🍓. So applications are RECOMMENDED to use the DSCP value 45 (decimal) to mark microflows as NQB 👑. Part of why 45 was picked is that it gets separate queuing in existing Wi-Fi networks (see Section 7.3), and part is that it keeps the PHB simpler to implement in network gear that can classify traffic by ranges of DSCP values (see Section 6.3 for more on that) ✨.
There are two main things an app weighs when deciding whether to mark its traffic NQB. One is the risk of getting hit by a traffic protection algorithm (see Section 5.2). The other is what happens if it overruns the NQB shallow buffer, which can occur if the traffic adds to a queue in a node that supports the PHB 🔥. In either case, the excess traffic could get discarded or queued separately as Default traffic, and that could mean it gets delivered out of order 💀. To dodge all that, if a microflow's traffic goes over the rate equation from the first paragraph of this section, the application MUST NOT mark that traffic with the NQB DSCP ⚠️. In that case, the app could instead consider a scalable congestion control mechanism as described in [RFC9331] 🦋.
Heads up: that MUST NOT is a big deal. If your traffic goes over the rate limit, don't slap the NQB mark on it.
All the sender requirements in this section relate to observable attributes of the packet stream 👀. That's what lets network elements (including nodes implementing the PHB) monitor for inappropriate DSCP usage and take action on traffic that doesn't comply, like discarding it or re-marking it 🧚. When this functionality is part of the PHB, it's described in Section 5.2 🫶.
5. NQB PHB Requirements ✨
For the NQB PHB to become widely deployed, incentives have to line up correctly 🌸. That means there's a benefit to the app for marking its packets correctly, and a disadvantage (or at least no benefit) for an app that intentionally mis-marks its traffic 💅. So a really useful property of nodes (network switches and routers) that support separate queues for NQB and QB microflows is that each queue tends to be the better pick for the traffic it's built for 🦋. The NQB queue is for microflows that match the NQB sender requirements in Section 4, and the QB queue is for the ones that don't 🎀. If everything follows these principles, there's basically little incentive for senders to mis-mark their traffic as NQB 🙈.
This incentive alignment keeps the system robust against the behavior of the large majority of people and organizations, who can be expected to act in their own interests (including app developers and service providers acting in their users' interests) 🫶. Malicious behavior isn't necessarily based on rational self-interest, though, so incentive alignment isn't a sufficient defense 😭. Luckily, the large majority of users don't act out of malice 🌈. Protection against malicious attacks (and accidents) is covered in Section 5.2 and summarized in Section 9 🔥. As mentioned previously, the NQB designation and marking is meant to convey verifiable traffic behavior, not just a wish for differentiated treatment ✨. Because of that, the network can identify any mis-marking 👑.
5.1. Primary Requirements ✨
Okay so this is where the NQB PHB gets its actual rules 💅 A node that supports the NQB PHB MUST provide a queue for NQB traffic that is separate from the queue used for Default traffic. Separate lanes, no mixing 🎀
A node that supports the NQB PHB SHOULD NOT rate limit or rate police the aggregate of NQB traffic separately from Default traffic. Lowkey, the whole NQB lane shouldn't get singled out for throttling 🙈 There's one exception for traffic sent toward a non-DS-capable domain, which is covered in Section 6.4.1. Also check out Section 5.2 for possible uses of per-microflow (instead of aggregate) rate policing ✨
The NQB queue SHOULD be given equivalent forwarding preference compared to the Default queue. The node SHOULD also provide a scheduler that lets NQB and Default traffic share the link in a way that treats the two classes equally. For example, that could be a Deficit Round-Robin (DRR) scheduler with equal weights, or two Wireless Multimedia Access Categories with the same Enhanced Distributed Channel Access (EDCA) parameters. Equal DRR weights are just a reasonable example, though, not the only allowed setup. Other scheduling weights are fine (more on that below) 🌸
A node that provides rate limits or rate guarantees for Default traffic SHOULD make sure those limits and/or guarantees are shared with NQB traffic in a way that treats the two classes equally. One way to do this is a hierarchical scheduler, where the limits and guarantees sit on a parent class and the Default and NQB queues are its children, getting equal access to the capacity configured for the parent (for example, with equal DRR scheduling) 🧚
Compliance with these recommendations reduces the incentive for QB traffic to get mis-marked as NQB. This matters most at nodes that are likely bottlenecks, because if a node deviates from them, mis-marked traffic could get a discernible benefit at everyone else's expense 😭 At network nodes that are rarely bottlenecks, these recommendations are less critical.
About that DRR example: equal scheduling weights are only an example. Ideally, the DRR weight would match the highest fraction of capacity that NQB-compliant flows are likely to use on a particular network segment. NQB-compliant flows are not capacity seeking (unlike QB flows, which can be), and DRR lets unused capacity in one class be used by traffic in the other. So a higher-than-needed NQB scheduler weight could be considered less problematic than the reverse. That said, a higher-than-needed NQB scheduler weight does increase the chance that a non-compliant microflow mis-marked as NQB can use more than its fair share of network capacity. NQB microflows are expected to each consume no more than 1% of the link capacity, and in low stat-mux environments (like the edge of the network) they would be unlikely to add up to 50% of the link capacity in aggregate. So 50% seems like a reasonable upper bound on the weight for the NQB PHB in those environments 💖
By default, a node supporting the NQB PHB SHOULD classify packets marked with DSCP value 45 (decimal) into the queue for NQB traffic. Per the requirement in Section 3 of [RFC2474], a node supporting the NQB PHB MUST support the ability to configure the DSCP used to classify packets into the queue for NQB traffic. A node supporting the NQB PHB MAY also support the ability to configure multiple DSCPs for that classification ✨
NQB PHB support is a big win at bottleneck nodes 🔥 Many bottleneck nodes have a relatively deep buffer for Default traffic (roughly equal to the base RTT of the expected connections, which could be tens or hundreds of milliseconds). Giving the NQB queue a similarly deep buffer would be at cross purposes to very low queueing delay, and it would erode the incentive for QB traffic to be marked correctly at such a bottleneck node. So the NQB queue MUST have a buffer size that is 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.
Operators need to be able to monitor NQB PHB usage and, in particular, watch for potential mis-marking of QB traffic. So a node supporting the NQB PHB MUST provide statistics that the network operator can use to detect whether abuse is occurring (for example, packet and drop counters). Those counters let operators track how much packet drop is happening because traffic is overrunning the shallow buffer, and then take action if they believe the PHB is causing more issues than it's solving in their environment. Those actions could include disabling the PHB, dealing with the sources of malicious traffic directly, enabling traffic protection (Section 5.2) if it's available, or requesting a feature from the equipment manufacturer to add a traffic protection function if one isn't currently available 😤
To stop degradation of NQB service caused by potential mis-marking of QB traffic from spreading to other users, network equipment that supports this PHB and handles traffic for multiple users SHOULD support provisioning capacity and related forwarding resources on a per-user basis. It SHOULD also support enforcing the resulting per-user limits on the aggregate of NQB and QB traffic for each user. Here, "user" should be read as meaning an entity the equipment is designed to serve more-or-less independently: a subscriber in the case of access network equipment, a station (STA) in the case of a Wi-Fi Access Point (AP) that implements per-STA queuing and airtime fairness, or an end user in the case of a networking co-op that serves a set of end users. This functionality is commonly available in the class of network equipment this PHB is primarily for (see Section 3.4). How provisioning works, and whether and how to enforce the resulting limits, may vary by network operator 🫶
While not fully described in this document, it may be possible for network equipment to implement a separate QB/NQB pair of queues for additional service classes beyond the Default PHB / NQB PHB pair ✨
Some network equipment has already been deployed that cannot readily be upgraded or configured to support the PHB requirements. However, that equipment might be capable of loosely supporting an NQB service. See Section 7.3.1 for details and an example where this is particularly important. A similar approach might prove useful in other network environments 🌈
5.2. Traffic Protection 🛡️💅
okay so bestie, this part is lowkey the drama of the whole NQB story 😭 because a QB microflow could end up mis-marked as NQB, whether that's an implementation error, a misconfiguration, or a literal bad actor trying to cause chaos 💀. a low-data-rate microflow that isn't marked as NQB and ends up in the QB queue only hurts itself, so it's kinda less of a concern 🫶. but a QB microflow that's mis-marked as NQB can totally build up a queue at a network node, and then everyone else sharing the NQB queue gets queuing delay and/or loss. not iconic 💔.
so to stop this from wrecking the microflows that follow the requirements in Section 4, network elements that support the NQB PHB SHOULD support a "traffic protection" function 🦋. it identifies microflows or packets that don't match the sender requirements in Section 4, and then it either reclassifies them to the QB queue or discards the offending traffic 🚫. if the algorithm reclassifies, the implementation MAY also give you an option to re-mark that traffic to Default (or maybe another local use codepoint) so later hops can use the decision 🧚. this could give a limited layer of protection when downstream nodes support separate NQB queuing but don't have traffic protection 🌸.
if traffic protection isn't supported or isn't working well at stopping queue formation and growth in the NQB queue, then mis-marked QB traffic can form a queue that overflows the shallow NQB buffer 😱. the excess packets then get redirected to the QB queue or dropped, and both of those hurt the mis-marked traffic AND the correctly marked NQB traffic 💀. this will likely cause a significant degradation of service for NQB traffic. even if the mis-marked traffic doesn't overflow the buffer, it still gets the reduced loss and delay benefits of NQB while adding queuing delay for everyone else in that queue 🙈. these increased abilities for QB traffic to damage NQB service need to be considered, and this is the reason for the "SHOULD" requirement to support traffic protection above. an NQB PHB implementation without traffic protection risks only being deployable where traffic protection is potentially not necessary 🍓. one example is a controlled environment like an enterprise LAN, where a network administrator is expected to manage DSCP usage 👑.
traffic protection is different from Traffic Conditioning in other Diffserv contexts ✨. Traffic Conditioning usually happens at the edge of a DS domain (ingress or egress, depending on the Traffic Conditioning Agreements (TCAs) in place). traffic protection, on the other hand, is meant to live in the nodes that implement the PHB 🎀. that way the node can watch the actual NQB queue and only act if a queue starts to form 👀. putting it at the bottleneck nodes matters most, because those are the ones that would show the biggest queue buildup when QB traffic is mis-marked as NQB 🔥.
this spec does not mandate one particular traffic protection algorithm 🌈. that's on purpose, because this will probably be an area where implementers get creative 💜. the specifics might need to differ between network equipment and network contexts, so instead this spec gives guidelines and some example algorithms 🧁.
The traffic protection function SHOULD NOT base its decisions on application-layer constructs (such as the port number used by the application or the source/destination IP address) 🙅♀️. instead, it ought to base its decisions on the actual behavior of each microflow (i.e., the pattern of packet arrivals) 📈.
a conventional traffic protection algorithm is a per-microflow rate policer 💖. it identifies microflows that exceed the bound provided in Section 4, where R is set to 1% of the egress link capacity available for NQB traffic 🧮. another option is an algorithm that bases decisions on detecting actual queuing (by monitoring the queuing delay packets experience in the NQB queue) in correlation with each microflow's packet arrivals 🔍. a per-microflow rate policer is conceptually simpler and based directly on the NQB sender requirements 🤓, but it can end up stricter than necessary, like policing a flow that exceeds the rate equation even when the link is underutilized 😬. one example of a traffic protection algorithm based on detecting actual queuing is in [RFC9957] 📚. it keeps per-microflow state for a certain number of simultaneous QB microflows (e.g., 32), and shared state for any microflows beyond that number 🫧.
if the algorithm reclassifies offending traffic, there are different levels of hysteresis to think about 🌀. the reclassify decision could be made packet by packet, but that can cause big out-of-order delivery, since some of a microflow's packets stay in the NQB queue while others get reclassified to the Default queue 😵💫. alternatively, the function could use some hysteresis so borderline microflows aren't reclassified capriciously, which means less potential for out-of-order delivery 🧘. a third option is to act on all future packets of the microflow, though there needs to be enough logic to make sure a future microflow (e.g., with the same 5-tuple) isn't mistaken for the current offending one 🕵️♀️.
if the algorithm discards offending traffic, similar hysteresis levels can be considered 💅. in this case it is RECOMMENDED that the decision thresholds be set higher than for reclassifying designs, because dropping a packet hurts communication more than out-of-order delivery does 🥺.
the traffic protection function described here might require the network element to keep microflow state 📝. the traffic protection function MUST be designed so the node implementing the NQB PHB does not fail (e.g., crash) when that microflow state runs out 🛑. this might be as simple as controlling or limiting the resources used for tracking misbehaving flows 💪.
some networks might prefer a Traffic Conditioning approach that polices the NQB DSCP at the ingress edge, so per-hop traffic protection isn't needed 🌐. this could use a per-microflow rate policer that polices microflows at 1% of the minimum link capacity of the network 📉. this approach would generally be expected to be inferior to per-hop traffic protection, because:
- on one hand, it would be hard for edge nodes to guarantee there would never be more than 100 NQB flows sharing a single internal bottleneck, and
- on the other hand, there could be internal links with much greater capacity than the minimum 🙃.
so Traffic Conditioning at the edge could be too lenient and too strict at the same time 😭🫠.
5.3. Limiting Packet Bursts from Links 💥
some link technologies get bursty because they briefly store packets before forwarding them 🫧. a common cause is link discontinuity (where the link isn't always available for the device to transmit), like time-division-duplex links or time-division-multiple-access (TDMA) links ⏳. examples in this category are Passive Optical Networks (PONs), Wi-Fi, LTE/5G, and Data-Over-Cable Service Interface Specification (DOCSIS) 📡.
so NQB senders need to limit packet bursts (see Section 4), and traffic designated for the NQB PHB would also benefit from configuring these link technologies to limit the burstiness they add 🎀. there are three reasons:
- burstiness, whether it comes from the sender or from a link on the path, can cause queuing delay at downstream bottlenecks, which degrades QoE 📉.
- burstiness on links usually means packets get delayed by variable amounts 🎢. packets aggregated while waiting for a transmission opportunity: some arrive just after the last opportunity and wait the longest, while others arrive just in time for the next one and wait the least. this shows up as delay variation, which can also degrade QoE for apps that want NQB treatment 💔.
- a downstream bottleneck implementing the NQB PHB could have a traffic protection mechanism (Section 5.2) that responds to queuing delay by re-marking, reclassifying, or dropping packets 🚨. bursty arrivals from an upstream link can add queuing delay in the NQB queue, and those packets are more likely to get hit by traffic protection effects 😬.
this document does not set any quantified requirements for links to limit bursts, mainly because link technologies are outside the remit of Diffserv specifications 🙅♀️. still, it would not seem necessary to limit bursts lower than roughly 10% of the minimum base RTT expected in the typical deployment scenario (e.g., 250 µs burst duration for links within the public Internet) ⏱️. this observation aligns with a similar one in Section 5.5 of [RFC9331] 🤝.
5.4. Treatment of the Explicit Congestion Notification Field 🚦
NQB network functions MUST treat packets marked with the NQB DSCP uniformly, regardless of the value of the ECN field 🫶. here, "NQB network functions" means the traffic protection function (defined in Section 5.2) and any re-marking or traffic policing function designed to protect unmanaged networks (as described in Section 6.4.1) 🧠.
6. Operational Considerations 🛠️✨
this section covers what network operators need to think about for identifying, marking, and handling NQB traffic 🍓. it outlines aggregation behaviors and special considerations in unmanaged and inter-network scenarios 🌍. Section 6.2 also has configuration recommendations for nodes that don't support the NQB PHB 💜, and Section 6.4.1 has configuration recommendations for networks that interconnect with non-DS-capable domains 🧚.
6.1. NQB Traffic Identification
Okay so, bestie, remember how Section 5 says nodes doing the NQB PHB have to let people set up classifiers 💅✨ That's so they can tell apart QB and NQB traffic of equal importance 🎀 And the NQB DSCP value (45 decimal) is recommended as the default classifier to spot NQB traffic vs. Default (DSCP 0) traffic 🦋 (see Sections 4 and 5.1). It's giving clean and simple 💖
6.2. Aggregation of the NQB DSCP into Another Diffserv PHB
Okay, this part is about what happens when a network or node doesn't support the NQB PHB at all 🥺 It is RECOMMENDED that those networks and nodes get configured to treat NQB-marked traffic the same as Default DSCP traffic 🌸 This covers stuff like MPLS and nodes that bundle service classes together, as talked about in [RFC5127] and [RFC8100] 🧚 So in practice, this recommendation means NQB-marked traffic gets lumped into the Elastic Treatment Aggregate (for networks as described in [RFC5127]) or the Default / Elastic Treatment Aggregate (for networks as described in [RFC8100]) 💜
Networks and nodes that don't support the NQB PHB ought to only classify packets with the NQB DSCP value into the right treatment aggregate, or encapsulate them so they get aggregated 🫶 They SHOULD NOT re-mark them with a different DSCP though 😭 Keeping the NQB DSCP value intact is what lets hops further down the path still provide the NQB PHB successfully 🔥 This lines up with what [RFC5127] recommends 👑
In nodes that don't usually get congested (like a lot of backbone and core network switches) 🌈, forwarding NQB-marked packets with the Default treatment might be enough to keep the loss, delay, and delay-variation performance for NQB traffic in good shape ✨
In nodes that DO get congested 💀, forwarding NQB-marked packets with the Default treatment could make the loss, delay, and delay-variation performance worse 😭 But it still keeps the incentives described in Section 5 alive 🎀
Aggregating NQB-marked traffic into a PHB built for real-time, delay-sensitive traffic (like the Real-Time Treatment Aggregate [RFC5127] or the Bulk Real-Time Treatment Aggregate [RFC8100]) might do a better job of protecting loss, delay, and delay-variation performance when things get congested 🦋 Just know it has to be done with care, because it could create an incentive for non-compliant traffic to get mis-marked as NQB 🙈
6.3. Aggregation of Other DSCPs into the NQB PHB
The Diffserv model gives operators lots of flexibility in how they aggregate traffic marked with a specific DSCP 💅 Operators of nodes that support the NQB PHB could choose to fold other service classes into the NQB queue 🌸 This is super useful when specialized PHBs for those other service classes weren't set up at a potential bottleneck, maybe because managing traffic contracts and conditioning was too complicated 😩 Good candidates for this are service classes that carry low-data-rate inelastic traffic with low to very-low tolerance for loss, delay, and/or delay variation 💖 Operators need to use their own judgment, based on the actual traffic characteristics in their networks, to decide whether or not to aggregate other service classes / DSCPs with NQB 🧠 For networks that use the service class definitions from [RFC4594], this could include Telephony (EF/VA), Signaling (CS5), and possibly Real-Time Interactive (CS4) (depending on data rate) 📞 In that sentence, "VA" and "CSx" refer to VOICE-ADMIT ([RFC5865]) and Class Selector ([RFC2474]), respectively 🎀 Some networks have equipment limitations that might force them to aggregate a whole range of DSCPs (e.g., traffic marked with DSCPs 40-47 (decimal), i.e., those whose three most significant bits are 0b101) 🧚 As noted in Section 4, the choice of DSCP value 45 (decimal) is partly motivated by wanting this aggregation to be simpler in network equipment that can classify packets by comparing the DSCP value to a range of configured values 👑
A node with only an NQB queue and a Default queue may get NQB performance similar to EF, for example as described in Appendix A.3.1 of [RFC2598] 🦋 There are some caveats and differences, which are discussed in Appendix B 🌈
6.4. Cross-Domain Usage and DSCP Re-marking
Okay so here's the thing 🌍 Some existing standard PHBs are typically only used within a DS domain (like an Autonomous System (AS) or an enterprise network) 🏢 But this PHB is expected to be used across the Internet, wherever suitable operator agreements apply ✨ Under the model described in [RFC2474], that means the corresponding DSCP has to be recognized and mapped across network boundaries accordingly 💜
If NQB support gets extended across a DS domain boundary, the interconnected networks that agree to support NQB SHOULD use DSCP value 45 (decimal) for NQB at network interconnection 🫶 The exception is if a different DSCP is explicitly documented in the TCA (see [RFC2475]) for that interconnection 📜 If a Diffserv-Intercon Interconnection Class (see Section 4 of [RFC8100]) is running between interconnected domains, the receiving domain may prefer a different DSCP for NQB traffic that allows for DSCP range-based classification for the Default / Elastic Treatment Aggregate 🎀 Just like with DSCPs for other PHBs (and as discussed in [RFC2475]), networks can re-mark NQB traffic to a DSCP value other than 45 (decimal) for internal usage 🔥 To keep NQB PHB treatment reliable across the entire path, the appropriate NQB DSCP needs to be restored when forwarding to another network 🙌
6.4.1. Interoperability with Non-DS-Capable Domains
Okay, this is a big one, bestie 😭 Sometimes a network operator that supports Diffserv delivers traffic to another network domain (like one outside their administrative control) 🌐 Either they understand the downstream domain doesn't support Diffserv, or they don't know what traffic management the downstream domain can do, and there's no agreement in place 🙈 In those cases, Section 4 of [RFC2475] suggests the upstream domain opportunistically re-marks traffic with a Class Selector Codepoint or DSCP 0 (Default), on the assumption that the downstream domain will handle traffic marked that way predictably 🧚
Same concerns apply to a network that supports the NQB PHB and carries traffic marked with the recommended DSCP value 45 (decimal) 💅 Here's why it matters: the recommended NQB DSCP value 45 (decimal) could get high priority in some non-DS-compliant network equipment (like legacy Wi-Fi APs described in Section 7.3.1) 😱 So it is RECOMMENDED that the operator of the upstream domain implement one of the following safeguards before delivering traffic into a non-DS-capable domain 🫶
- One option is to re-mark NQB traffic to DSCP 0 (Default) (or another Class Selector DSCP) before delivering it into a non-DS-capable domain, following the suggestion in Section 4 of [RFC2475] 🌸 Network equipment built for these environments SHOULD, by default, re-mark NQB traffic to DSCP 0 (Default) and SHOULD support the ability to change and disable this re-marking 🔧 Re-marking NQB traffic to DSCP 0 (Default) could be considered the "safest" approach, since the upstream domain can make sure NQB traffic doesn't get inappropriate treatment in the non-DS-capable domain 🛡️ That said, it comes with a downside: the re-marking ruins any chance of NQB isolation in any further downstream domain (not just the immediate neighbor) 💀
- As an alternative to re-marking all NQB traffic, such an operator could deploy a traffic protection (see Section 5.2) or a shaping/policing function on NQB-marked traffic 🎀 That minimizes the potential for negative impacts on Default traffic, in case the downstream domain treats NQB-marked traffic as high priority 👑
In the case that a traffic protection function is used, it MUST either re-mark offending traffic to DSCP 0 (or another Class Selector DSCP) or discard it 🚫 Note that a traffic protection function, as defined in this document, might only protect against issues occurring in subsequent network hops if the device implementing it is the bottleneck link on the path 🧐 So it might not be a solution for every situation 🤷♀️
In the case that a traffic policing function or a rate-shaping function is applied to the aggregate of NQB traffic destined for such a downstream 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 💖 Excess traffic gets re-marked and classified for Default forwarding (or dropped, as a last resort) 😩 A traffic policing function SHOULD allow approximately 100 ms of burst tolerance (e.g., a token bucket depth equal to 100 ms multiplied by the policer rate) ✨ A traffic-shaping function SHOULD allow approximately 10 ms of burst tolerance and no more than 50 ms of buffering 🌊 These burst tolerance values are meant to reduce the degradation that could hit delay- and loss-sensitive NQB traffic, without seriously degrading Default traffic 🍓 They can be adjusted based on local network policy 🎀 Increasing the burst tolerance would further reduce the potential for degradation (more loss or more delay) of NQB traffic, but it would come at the cost of a higher risk of degradation (more loss or more delay) of Default traffic 😬
The recommendation to limit NQB traffic to 5% is based on an assumption that internal links in the downstream domain could have data rates as low as one tenth of the interconnect rate 🧮 In that case, if the entire NQB aggregate traversed a single instance of such a link, the aggregate would consume no more than 50% of that link's capacity 🫧 The limit for NQB traffic SHOULD be adjusted based on any knowledge of the local network environment that is available 🌸
6.5. The NQB DSCP and Tunnels 🎀
Okay so [RFC2983] is the one that talks about tunnel models for Diffserv, and it's giving two main vibes 💅. The first is the "uniform model", where the inner DSCP gets copied to the outer header when you encapsulate, and the outer DSCP gets copied back to the inner header when you decapsulate. The second is the "pipe model", where the outer DSCP does NOT get copied back to the inner header at decapsulation. Both of these can totally be used together with the NQB PHB ✨. With the pipe model, any DSCP re-marking of the outer header by intermediate nodes gets thrown out at the tunnel egress 🙈. Sometimes that actually helps NQB treatment in later nodes, and sometimes it hurts, like if the re-marking was specifically designed to keep NQB treatment alive in downstream domains. Plot twist, right? 😭
As [RFC2983] explains, tunnel protocols that care about reordering (like IPsec [RFC4301] or Layer 2 Tunneling Protocol (L2TP) [RFC2661]) can get messy if multiple DSCP PHBs are signaled for traffic inside one tunnel instance. That's true for tunnels mixing QB and NQB traffic 🫶. And it gets worse, bestie: networks running the NQB PHB could use a traffic protection mechanism (see Section 5.2) and/or respond to NQB buffer overrun in ways that cause out-of-order delivery for NQB-marked traffic. So even a tunnel that's ONLY NQB traffic could have problems if it's reordering-sensitive AND the outer header keeps the NQB DSCP 💀. Lowkey chaotic.
So the bottom line: if you're carrying NQB traffic, or a mix of QB and NQB traffic, through a reordering-sensitive tunnel protocol, the outer tunnel header MUST be re-marked with a non-NQB DSCP (for example, Default). In that case, the "pipe" model is the preferable one, because it keeps the marking differentiation intact at tunnel decapsulation 👑.
6.6. Guidance for Lower-Rate Links 🌸
The NQB sender requirements in Section 4 put the responsibility on the application developer to figure out how likely their app's sending behavior is to cause a queue to form along the path. These requirements assume developers have a solid sense of the network context their app will be deployed in 🧚. Even so, there are definitely going to be networks with links whose data rate is below the lower end of what's considered "typical". Some of these links could even be slower than the instantaneous sending rate of some NQB-marked applications 😭.
To soften the blow of this situation, operators of networks with lower-rate links SHOULD consider using a traffic protection function on those links that is more tolerant of burstiness (meaning, a temporary queue) 🦋. This lets a bigger set of NQB-marked microflows stay in the NQB queue, but the tradeoff is a greater potential for delay variation. In implementations that support [RFC9957], the burst tolerance can be configured via the CRITICALqLSCORE_us input parameter 🔥.
Or, operators of networks with lower-rate links MAY choose to turn off NQB support on those links (which means traffic marked with the NQB DSCP gets lumped in with Default traffic) 🍓. For links whose data rate is less than 10% of "typical" path rates, it is RECOMMENDED that the NQB PHB be disabled, and that NQB-marked traffic is therefore carried using the Default PHB (without being re-marked to the Default DSCP (0)) 💜.
- Mapping NQB to Standards of Other SDOs 🌈
This section gives recommendations for supporting the NQB PHB in certain use cases. It is not exhaustive, so there's more out there 👀.
7.1. DOCSIS Access Networks 🦋
Residential cable broadband services are commonly set up with a single bottleneck link (the access network link) where the service definition gets applied. That service definition, which is usually an upstream/downstream data rate pair, is implemented as a configured pair of rate shapers applied to the user's traffic. In these networks, the QoS each application gets, and therefore the QoE the user experiences, is shaped by the characteristics of that access network link ✨.
To support the NQB PHB, cable broadband services would need a separate queue for NQB-marked traffic 🫶. That NQB queue would need to share the service's rate-shaped capacity with the queue for QB traffic. More discussion about NQB support in DOCSIS networks can be found in [LOW_LATENCY_DOCSIS] 💅.
7.2. Mobile Networks 📱
Historically, 3GPP mobile networks have used "bearers" to carry each user's user plane traffic through the radio access and core networks 🎀. Bearers also have a QoS that determines how packets get prioritized at queues and radio schedulers. In LTE networks these are Evolved Packet System (EPS) bearers, which are part of the EPS, the core and access network architecture 🌸. Typically, an LTE operator provides a dedicated EPS bearer for IP Multimedia Subsystem (IMS) Voice over LTE (VoLTE) traffic, to meet regulatory obligations for call completion rates, plus a best-effort default EPS bearer for Internet traffic. That default EPS bearer is typically non-Guaranteed Bit Rate (non-GBR), gives no guarantees, and its buffering characteristics are generally not compatible with low-latency traffic 🙈. In 5G networks, similar functionality is provided using QoS flows within a PDU Session in the core network, which map to Data Radio Bearers (DRBs) on the radio network. 5G systems offer more flexibility in QoS handling, letting traffic be treated by type (e.g., loss-tolerant, low-latency), so they support more suitable treatment of Internet real-time microflows 🚀.
To support the NQB PHB, an LTE network could be set up to give the User Equipment (UE, the subscriber's device) a dedicated low-latency, non-GBR EPS bearer, in addition to the default EPS bearer 💖. For example, this dedicated EPS bearer could use QCI 7 (QoS Class Identifier 7), which is typically used for low-latency, non-GBR services. Or, in a 5G system, a Data Radio Bearer (DRB) with 5QI 7 (5G QoS Identifier 7, also used for low-latency traffic) could be provisioned (see Table 5.7.4-1: Standardized 5QI to QoS characteristics mapping in [SA-5G]) 🧚.
A packet carrying the NQB DSCP could then be routed through this dedicated low-latency path, while packets without the NQB marking would go through the default bearer 🦋.
7.3. Wi-Fi Networks 📶
Wi-Fi networking equipment compliant with 802.11e/n/ac/ax [IEEE802-11] generally supports either four or eight transmit queues, plus four sets of associated EDCA parameters (matching the four Wi-Fi Multimedia (WMM) Access Categories) that enable differentiated medium access characteristics 💜. The four WMM Access Categories are Voice Access Category (AC_VO), Video Access Category (AC_VI), Best Effort Access Category (AC_BE), and Background Access Category (AC_BK), and they give four levels of prioritized access to the wireless medium. As discussed in [RFC8325], it's been common practice for Wi-Fi implementations to use a default DSCP to User Priority (UP) mapping that uses the most significant three bits of the DSCP field to select "User Priority", which then maps to the four WMM Access Categories 🌈. [RFC8325] also provides an alternative mapping that lines up more closely with the DSCP recommendations from the IETF ✨. For some managed Wi-Fi equipment, the operator can control this mapping, for example via TR-369 [TR-369] 🫶.
On top of the requirements in the other sections of this document, Wi-Fi equipment (including equipment compliant with [RFC8325]) SHOULD map the DSCP value 45 (decimal) into a separate queue in the same Access Category as the queue carrying Default traffic (i.e., the Best Effort Access Category) 💅. It is RECOMMENDED that Wi-Fi equipment provide a separate queue in UP 0 and map the DSCP value 45 (decimal) to that queue 👑. If a separate queue in UP 0 cannot be provided (due to hardware limitations, etc.), a Wi-Fi device MAY map the DSCP value 45 (decimal) to UP 3 🔥.
7.3.1. Interoperability with Existing Wi-Fi Networks ✨
okay so some existing Wi-Fi gear can totally do the NQB PHB stuff (sometimes after a firmware update) 🆙, but tons of devices already out there just can't be configured that way 🥲. So this section is about playing nice with those existing Wi-Fi networks, not about PHB compliance 🫶.
Since this gear is everywhere, and the Wi-Fi link can become a bottleneck 🚧, how NQB-marked traffic performs across those links could seriously affect whether the NQB DSCP and PHB actually catch on 💅. Depending on which DSCP marks the NQB traffic, existing Wi-Fi equipment that uses the default mapping of DSCPs to Access Categories (see Section 2.3 of [RFC8325]) and the default EDCA parameters will support either (but not both) of these:
- the NQB PHB requirement for separate queuing of NQB traffic from Default traffic (Section 5.1)
- the recommendation to treat NQB traffic with forwarding preference equal to that used for Default traffic (Section 5.1)
So the DSCP value 45 (decimal) is recommended for NQB (see Section 4) 🎀. That maps NQB to UP 5 using the default mapping, which lands it in the Video Access Category. Choosing this DSCP lets these Wi-Fi systems support the NQB PHB requirement for separate queuing 🙌, but existing Wi-Fi devices usually have EDCA parameters that give the Video Access Category statistical priority over the Best Effort Access Category 👀. This equipment also doesn't support the remaining NQB PHB recommendations in Section 5 😭. The reasoning behind DSCP value 45 (decimal), plus its ramifications and the remedies for its limitations, is covered further below 👇.
Choosing separated queuing instead of equal forwarding preference in existing Wi-Fi networks came down to these vibes:
- Separate queuing is necessary in order to provide a benefit for traffic marked with the NQB DSCP.
- The arrangement of queues in Wi-Fi equipment is typically fixed, whereas the relative priority of the Access Category queues is configurable. Most Wi-Fi equipment has hardware support (albeit generally not exposed for user control), which could be used to adjust the EDCA parameters in order to meet the equal forwarding preference recommendation. This is discussed further below 🔧.
- Traffic that is compliant with the NQB sender requirements in Section 4 is expected to cause minimal degradation to traffic in lower priority Access Categories. In any case, it would be unlikely to cause more degradation to lower priority Access Categories than the existing recommended Video Access Category traffic types: Broadcast Video, Multimedia Streaming, Multimedia Conferencing from [RFC8325], and AudioVideo, ExcellentEffort from [QOS_TRAFFIC_TYPE] 🌈.
- Several existing client applications that are compatible with the NQB sender requirements already select the Video Access Category, so they wouldn't see a performance drop by transitioning to the NQB DSCP, no matter whether the network supported the PHB 💜.
- Application instances on Wi-Fi client devices are already free to choose any Access Category they want, regardless of their sending behavior, and nobody polices it 🙃. So using DSCP value 45 (decimal) for NQB creates no new avenues for non-NQB-compliant client applications to exploit the prioritization function in Wi-Fi.
- For application traffic that originates outside of the Wi-Fi network, and is therefore transmitted by the Access Point, DSCP value 45 (decimal) does create a potential for abuse by non-compliant applications 😬. BUT there are opportunities in the network components upstream of the Wi-Fi Access Point to police the usage of the NQB DSCP and potentially re-mark traffic that is considered non-compliant, as is recommended in Section 6.4.1 🛡️. Plus, it's reasonable to expect that ISPs already manage the DSCPs on traffic destined to their customers' networks and will keep doing so whether or not they support NQB. That includes the practice in residential broadband networks of re-marking the DSCP field to zero on all traffic. Any change to these practices made so the NQB DSCP can pass through could be done alongside implementing the recommendations in Section 6.4.1 ✨.
Okay, now the Video vs. Voice vs. Background choice 🧐. The Video Access Category was picked over the Voice Access Category to minimize the potential for degradation of Best Effort Access Category traffic. The Video Access Category was picked over the Background Access Category because the vast majority of traffic in most Wi-Fi networks uses the Best Effort Access Category, and NQB traffic would be much more at risk of degradation from that traffic 😤.
As stated above, using DSCP value 45 (decimal) for NQB is not expected to create incentives for abuse by non-compliant applications in the Wi-Fi uplink direction 🙅♀️. The NQB DSCP does bring the potential for degradation to non-compliant applications (traffic protection and/or a shallow queue resulting in reordering and/or packet loss at some hop along the path). Add in the multiple other DSCP values that don't carry that risk and could easily be used to get prioritization (AC_VI or even AC_VO), and the conclusion is that NQB non-compliant applications seeking prioritization in the Wi-Fi uplink would be better off picking one of those other DSCPs 💅. This conclusion is not expected to be disturbed by network support for NQB making DSCP value 45 (decimal) traffic more likely to cross network boundaries without a DSCP change. That increase in boundary crossings is balanced out by NQB traffic running into the traffic-limiting aspects of NQB support, traffic protection, and shallow buffers, which limit the potential for abuse 🛑.
For traffic originating outside of the Wi-Fi network, prioritizing NQB-marked traffic via the Video Access Category (if left unchanged) could potentially erode the principle of alignment of incentives discussed in Section 5 😩. To keep the incentives principle intact for NQB, Wi-Fi systems MAY be configured so the EDCA parameters for the Video Access Category match those of the Best Effort Access Category. That means AC_VI sits at the same priority level as AC_BE 🎯. These changes might not be possible on all Access Points, though, and in any case the requirements and recommendations in Section 6.4.1 would apply in this situation 🫶.
Systems that utilize [RFC8325] but cannot provide a separate AC_BE queue for NQB traffic SHOULD map the DSCP value 45 (decimal) (or the locally determined alternative) to UP 5 in the Video Access Category as well (see Section 7.3.2) 🌸.
7.3.2. The Updates to RFC 8325
bestie, this part is the update paperwork for RFC 8325 📝. Section 4.2.9 of [RFC8325] describes the recommendation for handling Standard service class traffic that carries the Default DSCP. This update changes the title of Section 4.2.9 of [RFC8325] from "Standard" to "Standard and Non-Queue-Building". It also adds a paragraph at the end of Section 4.2.9 of [RFC8325], and here's the exact text (no edits, the wording matters 🤍):
RFC 9956 defines a shallow-buffered, best-effort service for traffic described as Non-Queue-Building and recommends the following treatment in Wi-Fi equipment. It is RECOMMENDED that Wi-Fi equipment map Non-Queue-Building traffic into a separate queue in the same Access Category as the queue that carries Default traffic (i.e., the Best Effort Access Category). It is RECOMMENDED that Wi-Fi equipment provide a separate queue in UP 0 and map Non-Queue-Building traffic to that queue. If a separate queue in UP 0 cannot be provided (due to hardware limitations, etc.), a Wi-Fi device MAY map Non-Queue-Building traffic to UP 3. If neither of these options provides a separate queue from Default traffic, it is RECOMMENDED that Wi-Fi equipment map Non-Queue- Building traffic to UP 5 (which corresponds to the default mapping described in Section 2.3). RFC 9956 provides additional recommendations and requirements for support of the NQB PHB that aren't available in the QoS model described in Section 6 but nonetheless could be supported in implementations.
Another update to [RFC8325] adds a new row for "Non-Queue-Building" traffic between the existing "Low-Latency Data" and "OAM" rows in Figure 1 of [RFC8325] 📊. Here's the updated figure, table and all:
+===============+======+==========+==================================+
| IETF Diffserv | PHB |Reference | IEEE 802.11 |
| Service Class | | RFC |User Priority| Access Category |
|===============+======+==========+=============+====================|
| ... | ... | ... | ... | ... |
+---------------+------+----------+-------------+--------------------+
| Low- | AF21 | | | |
| Latency | AF22 | RFC 2597 | 3 | AC_BE (Best Effort)|
| Data | AF23 | | | |
+---------------+------+----------+-------------+--------------------+
| Non- | | | 0, 3 | AC_BE (Best Effort)|
| Queue- | NQB | RFC 9956 | OR |
| Building | | | 5 | AC_VI (Video) |
| | | | See Section 4.2.9 |
+---------------+------+----------+-------------+--------------------+
| OAM | CS2 | RFC 2474 | 0 | AC_BE (Best Effort)|
+---------------+------+----------+-------------+--------------------+A third update adds one sentence to the end of the first paragraph in Section 5.3 of [RFC8325] 🌟:
An exception to this is the NQB DSCP value 45 (decimal), which encodes for best-effort service.
8. IANA Considerations 🦋
IANA has assigned the Differentiated Services Field Codepoint (DSCP) 45 from the "Differentiated Services Field Codepoints (DSCP)" registry (https://www.iana.org/assignments/dscp-registry/) ("DSCP Pool 3 Codepoints", Codepoint Space xxxx01, Standards Action ([RFC8126]) for NQB behavior. Ta-da 💖.
IANA has updated this registry as follows:
Name: NQB
Value (Binary): 101101
Value (Decimal): 45
Reference: RFC 99569. Security Considerations ✨
okay bestie, this section is the serious one 🫶 but I'm still gonna make it fun. The main worry is about the capacity and delay that other flows on a shared bottleneck can lose when traffic is marked with the recommended NQB DSCP. 💅
Full support for the NQB PHB in bottleneck links takes away most of the reason for a QB application to mis-mark its packets as NQB 🙈, especially in implementations that support traffic protection. If a QB microflow tried to sneak in as NQB, it wouldn't gain anything, and it would usually get a worse experience. That's very different from mis-marking for a higher-priority PHB, like the EF PHB [RFC3246], which would be the obvious move for a cheater 👀. How bad the degradation gets depends on how the PHB is implemented, including how it responds to an NQB buffer overflow and whether a traffic protection function is there at all 🌸. It could mean excessive packet loss, excessive delay variation, and/or excessive out-of-order delivery 💀. On the flip side, if an NQB microflow forgets to mark its packets as NQB, it can end up with the delay and loss you get from sharing a queue with capacity-seeking traffic 😭.
To keep low-delay performance for NQB traffic, networks that support the NQB PHB will need mechanisms in place that stop malicious NQB-marked traffic from causing excessive queue delay 🔥. Section 5.2 recommends a traffic protection mechanism to get this done ✨. The traffic protection recommendations in this document assume that some kind of "flow" state is kept, so the network can tell apart the microflows that are causing queuing delay from the ones that aren't 🧚. That flow state is probably finite, which opens the door to flow-state exhaustion attacks 😬. This document does require that traffic protection mechanisms be designed with that possibility in mind, but what actually happens during flow-state exhaustion depends on the implementation 🎀.
If traffic protection isn't implemented, or can't stop a queue from forming in the NQB shallow buffer, the buffer is small enough that a growing queue will overrun it. That causes negative effects (for example, reforwarding as Default, or discarding) that can hit multiple NQB-marked microflows, even ones that didn't contribute to the queue 💔. As discussed elsewhere in this document, those negative effects help discourage misuse and abuse of NQB by QB traffic 👑. But the side effects still land on NQB traffic that's using NQB (and its shallow buffer) the way it's meant to be used, so the document motivates per-user provisioning limits that keep a queue overrun from spilling onto other users (see Section 5.1) 🫶.
That said, the choice of DSCP for NQB does let existing Wi-Fi networks readily (and by default) support some of the PHB requirements 🦋. But there's no traffic protection function there, and when left in the default state, NQB traffic gets higher priority than QB traffic. This is not considered a compliant implementation of the PHB 🙅♀️. Those existing Wi-Fi networks already give priority to half of the DSCP space, whether or not DSCP value 45 (decimal) is assigned to the NQB DSCP 🌈. DSCP value 45 (decimal) could also be abused to gain priority on such links, but the traffic protection functions that may exist in other hops along the path (which likely act on DSCP value 45 (decimal) alone) would make that abuse less attractive than using any of the other 31 DSCP values that get priority ⭐.
This document talks about the possible use of the NQB DSCP and NQB PHB in network technologies standardized by other SDOs. Any security considerations that come up only from deploying and operating NQB in specific network technologies aren't discussed here 🍓.
NQB uses the DS field 💖. Diffserv doesn't include integrity protection for the DSCP, so an on-path attacker can change it. The NQB PHB and its DSCP don't change that 😵. Re-marking DSCPs is allowed for various reasons (some are covered in this document, others in [RFC2474] and [RFC2475]) 📚, but if it's done maliciously, it might hurt the QoS of the tampered microflow 😤. Still, an on-path attacker can also change other mutable fields in the IP header (like the TTL), which can cause way more chaos than just messing with QoS treatment 🌪️.
10. References 📚
10.1. Normative References 🎀
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
- [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.
- [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
- [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
- [RFC8325] Szigeti, T., Henry, J., and F. Baker, "Mapping Diffserv to IEEE 802.11", RFC 8325, DOI 10.17487/RFC8325, February 2018, <https://www.rfc-editor.org/info/rfc8325>.
10.2. Informative References ✨
okay bestie, this is the receipts section 📚 these are the extra reads that back up everything we've been talking about, and I've copied every single one exactly so nothing gets lost 💅
[Barik] Barik, R., Welzl, M., Elmokashfi, A., Dreibholz, T., and
S. Gjessing, "Can WebRTC QoS Work? A DSCP Measurement
Study", 30th International Teletraffic Congress (ITC 30),
DOI 10.1109/ITC30.2018.00034, September 2018,
<https://gitlab2.informatik.uni-wuerzburg.de/itc-
conference/itc-publications-public/-/raw/master/itc30/
Barik18ITC30.pdf?inline=true>.
[BBR-CC] Cardwell, N., Ed., Swett, I., Ed., and J. Beshay, Ed.,
"BBR Congestion Control", Work in Progress, Internet-
Draft, draft-ietf-ccwg-bbr-05, 2 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-ccwg-
bbr-04>.
[Cardwell2017]
Cardwell, N., Cheng, Y., Gunn, C. S., Yeganeh, S. H., and
V. Jacobson, "BBR: Congestion-Based Congestion Control",
Communications of the ACM, vol. 60, no. 2, pp. 58-66,
DOI 10.1145/3009824, February 2017,
<https://doi.org/10.1145/3009824>.
[Custura] Custura, A., Venne, A., and G. Fairhurst, "Exploring DSCP
modification pathologies in mobile edge networks", Network
Traffic Measurement and Analysis Conference (TMA), 2017,
<https://tma.ifip.org/wp-content/uploads/sites/7/2017/06/
mnm2017_paper13.pdf>.
[Gettys2012]
Gettys, J. and K. Nichols, "Bufferbloat: Dark Buffers in
the Internet", Communications of the ACM, vol. 55, no. 1,
pp. 57-65, DOI 10.1145/2063176.2063196, January 2012,
<https://doi.org/10.1145/2063176.2063196>.
[IEEE802-11]
IEEE, "IEEE Standard for Information Technology --
Telecommunications and Information Exchange between
Systems - Local and Metropolitan Area Networks -- Specific
Requirements - Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications", IEEE
Std 802.11-2024, DOI 10.1109/IEEESTD.2025.10979691, April
2025, <https://ieeexplore.ieee.org/document/10979691>.
[LOW_LATENCY_DOCSIS]
CableLabs, "Low Latency DOCSIS: Technology Overview",
February 2019, <https://cablela.bs/low-latency-docsis-
technology-overview-february-2019>.
[QOS_TRAFFIC_TYPE]
Microsoft, Corporation, "QOS_TRAFFIC_TYPE enumeration
(qos2.h)", January 2022, <https://learn.microsoft.com/en-
us/windows/win32/api/qos2/ne-qos2-qos_traffic_type>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/info/rfc2475>.
[RFC2598] Jacobson, V., Nichols, K., and K. Poduri, "An Expedited
Forwarding PHB", RFC 2598, DOI 10.17487/RFC2598, June
1999, <https://www.rfc-editor.org/info/rfc2598>.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, DOI 10.17487/RFC2661, August 1999,
<https://www.rfc-editor.org/info/rfc2661>.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, DOI 10.17487/RFC2914, September 2000,
<https://www.rfc-editor.org/info/rfc2914>.
[RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, DOI 10.17487/RFC2983, October 2000,
<https://www.rfc-editor.org/info/rfc2983>.
[RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le
Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,
<https://www.rfc-editor.org/info/rfc3246>.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
DOI 10.17487/RFC3551, July 2003,
<https://www.rfc-editor.org/info/rfc3551>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594,
DOI 10.17487/RFC4594, August 2006,
<https://www.rfc-editor.org/info/rfc4594>.
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of
Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127,
February 2008, <https://www.rfc-editor.org/info/rfc5127>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<https://www.rfc-editor.org/info/rfc5681>.
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated
Services Code Point (DSCP) for Capacity-Admitted Traffic",
RFC 5865, DOI 10.17487/RFC5865, May 2010,
<https://www.rfc-editor.org/info/rfc5865>.
[RFC7893] Stein, Y., Black, D., and B. Briscoe, "Pseudowire
Congestion Considerations", RFC 7893,
DOI 10.17487/RFC7893, June 2016,
<https://www.rfc-editor.org/info/rfc7893>.
[RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White,
"Proportional Integral Controller Enhanced (PIE): A
Lightweight Control Scheme to Address the Bufferbloat
Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017,
<https://www.rfc-editor.org/info/rfc8033>.
[RFC8034] White, G. and R. Pan, "Active Queue Management (AQM) Based
on Proportional Integral Controller Enhanced (PIE) for
Data-Over-Cable Service Interface Specifications (DOCSIS)
Cable Modems", RFC 8034, DOI 10.17487/RFC8034, February
2017, <https://www.rfc-editor.org/info/rfc8034>.
[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions", RFC 8083,
DOI 10.17487/RFC8083, March 2017,
<https://www.rfc-editor.org/info/rfc8083>.
[RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection
Classes and Practice", RFC 8100, DOI 10.17487/RFC8100,
March 2017, <https://www.rfc-editor.org/info/rfc8100>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8289] Nichols, K., Jacobson, V., McGregor, A., Ed., and J.
Iyengar, Ed., "Controlled Delay Active Queue Management",
RFC 8289, DOI 10.17487/RFC8289, January 2018,
<https://www.rfc-editor.org/info/rfc8289>.
[RFC8290] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys,
J., and E. Dumazet, "The Flow Queue CoDel Packet Scheduler
and Active Queue Management Algorithm", RFC 8290,
DOI 10.17487/RFC8290, January 2018,
<https://www.rfc-editor.org/info/rfc8290>.
[RFC8622] Bless, R., "A Lower-Effort Per-Hop Behavior (LE PHB) for
Differentiated Services", RFC 8622, DOI 10.17487/RFC8622,
June 2019, <https://www.rfc-editor.org/info/rfc8622>.
[RFC9330] Briscoe, B., Ed., De Schepper, K., Bagnulo, M., and G.
White, "Low Latency, Low Loss, and Scalable Throughput
(L4S) Internet Service: Architecture", RFC 9330,
DOI 10.17487/RFC9330, January 2023,
<https://www.rfc-editor.org/info/rfc9330>.
[RFC9331] De Schepper, K. and B. Briscoe, Ed., "The Explicit
Congestion Notification (ECN) Protocol for Low Latency,
Low Loss, and Scalable Throughput (L4S)", RFC 9331,
DOI 10.17487/RFC9331, January 2023,
<https://www.rfc-editor.org/info/rfc9331>.
[RFC9332] De Schepper, K., Briscoe, B., Ed., and G. White, "Dual-
Queue Coupled Active Queue Management (AQM) for Low
Latency, Low Loss, and Scalable Throughput (L4S)",
RFC 9332, DOI 10.17487/RFC9332, January 2023,
<https://www.rfc-editor.org/info/rfc9332>.
[RFC9435] Custura, A., Fairhurst, G., and R. Secchi, "Considerations
for Assigning a New Recommended Differentiated Services
Code Point (DSCP)", RFC 9435, DOI 10.17487/RFC9435, July
2023, <https://www.rfc-editor.org/info/rfc9435>.
[RFC9438] Xu, L., Ha, S., Rhee, I., Goel, V., and L. Eggert, Ed.,
"CUBIC for Fast and Long-Distance Networks", RFC 9438,
DOI 10.17487/RFC9438, August 2023,
<https://www.rfc-editor.org/info/rfc9438>.
[RFC9957] Briscoe, B., Ed. and G. White, "The DOCSIS Queue
Protection Algorithm to Preserve Low Latency", RFC 9957,
DOI 10.17487/RFC9957, May 2026,
<https://www.rfc-editor.org/info/rfc9957>.
[SA-5G] 3GPP, "System Architecture for the 5G System (5GS)",
Version 20.1.0, Release 20, 3GPP TS 23.501, March 2026,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3144>.
[TR-369] Broadband Forum, "The User Services Platform", Issue: 1
Amendment 4 Corrigendum 2, July 2025,
<https://usp.technology/specification/index.html>.
[WikipediaBufferbloat]
Wikipedia, "Bufferbloat", May 2025,
<https://en.wikipedia.org/w/
index.php?title=Bufferbloat&oldid=1292250296>.more parts coming, so don't go anywhere 🫶🌸
Appendix A. DSCP Re-marking Policies 🎀
okay so some network operators totally bleach (zero out) the DSCP field on ingress into their network (see [RFC9435], [Custura], and [Barik]) and, in some cases, slap on their own DSCP for internal use 💅 Bleaching DSCP value 45 (decimal) is not expected to cause harm to Default traffic, but it will severely limit the ability to provide NQB treatment 🥺 Reports on existing deployments of DSCP manipulation (see [Custura] and [Barik]) sort the re-marking behaviors into these policies: bleach all traffic (set DSCP to zero); set the top three bits (the former Precedence bits) on all traffic to 0b000, 0b001, or 0b010; set the low three bits on all traffic to 0b000; or re-mark all traffic to a particular (non-zero) DSCP value 🌸
Okay the DSCP value 45 (decimal) part is lowkey the tea ☕ There were no observations of DSCP manipulation where traffic got marked with DSCP value 45 (decimal) by any of these policies 🙈 So these re-marking policies would be unlikely to result in QB traffic being marked as NQB ✨ As for the fate of traffic marked with DSCP value 45 (decimal) that gets hit by one of these policies, it would be indistinguishable from some subset (possibly all) of other traffic 🦋 In the policies where all traffic is re-marked using the same (zero or non-zero) DSCP value, the ability for a later network hop to tell NQB traffic apart via DSCP would be completely gone 💀
Now the top-three-bits policy is giving main character energy 👑 Here the DSCP value 45 (decimal) gets the same marking as the currently unassigned Pool 3 DSCP values (5, 13, 21, 29, 37, 53, and 61), and all of those get re-marked to DSCP value = 5, 13, or 21 (depending on the overwrite value used) 🧚 See Section 4.2 of [RFC9435] for that. None of the DSCP values in those lists are currently assigned by IANA, and they're all reserved for Standards Action, so they're believed to not be widely used right now 🌈 Though this could vary based on local usage and could change in the future 🫶 If networks where this kind of re-marking happens, or networks downstream, classify the resulting DSCP (i.e., 5, 13, or 21) to the NQB PHB or re-mark that traffic with DSCP value 45 (decimal), they risk giving NQB treatment to other traffic that was never marked as NQB 😭 Also, as Section 6 of [RFC9435] describes, future assignments of these 0bxxx101 DSCPs would need to be made with consideration of the potential that they all get treated as NQB in some networks 🔥
For the policy where the low three bits are set to 0b000, the DSCP value 45 (decimal) would be re-marked to CS5 and be indistinguishable from CS5, VA, and EF (and the currently unassigned DSCP values 41, 42, and 43) 💜 Traffic using the existing standardized DSCPs in this list is likely to share the same general vibe as NQB traffic (non-capacity-seeking and very low data rate, relatively low data rate, and consistent data rate) ✨ Similarly, any future recommended usage for DSCP values 41, 42, 43 would likely be somewhat compatible with NQB treatment, assuming that IP Precedence compatibility (see Section 1.5.4 of [RFC4594]) is maintained in the future 🍓 So here there might be an opportunity for a node to give the NQB PHB or the CS5 PHB to CS5-marked traffic and still keep some of the benefits of NQB marking 🎀 This could be another motivation to classify CS5-marked traffic into the NQB queue (as discussed in Section 6.3) 💖
Appendix B. Comparison with Expedited Forwarding 🦋
Okay so the EF definition [RFC3246] gives this text to describe the EF PHB forwarding behavior:
This specification defines a PHB in which EF packets are guaranteed to receive service at or above a configured rate
and
the rate at which EF traffic is served at a given output interface should be at least the configured rate R, over a suitably defined interval, independent of the offered load of non-EF traffic to that interface.
Notably, this description is true of any class of traffic that's configured with a guaranteed minimum rate, including the Default PHB if it's configured per the guidelines in Section 1.5.1 of [RFC4594] 💅 [RFC3246] goes on to formalize the definition of EF by requiring that an EF node be characterizable in terms of the fidelity with which it is able to provide a guaranteed rate 🤓
While the NQB PHB is not required to be configured with a guaranteed minimum rate, [RFC2474] and [RFC4594] recommend assigning some minimum resources for the Default PHB, in particular, some dedicated capacity 🌸 If such a guaranteed minimum rate is configured for the Default PHB, it is recommended (Section 5) that NQB traffic share and be given equal access to that rate 🫶 In that case, the NQB PHB could effectively receive a rate guarantee of (for example) 50% of the rate guaranteed to the combined NQB/Default PHBs, so it technically complies with the PHB forwarding behavior defined for EF ✨
However, EF is meant to be a managed service and requires that traffic be policed so the arriving rate of traffic into the EF PHB doesn't exceed the guaranteed forwarding rate configured for the PHB 🔒 This is what makes sure low delay and low-delay variation are provided 💜 NQB is meant to be a best effort service, so the aggregate of traffic arriving at the NQB PHB queue could exceed the forwarding rate available to the PHB 🙈 Section 5.2 talks about the recommended mechanism for handling excess traffic in NQB 🍓 While EF relies on rate policing and dropping of excess traffic at the domain border, that's only one option for NQB 🦋 NQB mainly recommends traffic protection located at each potential bottleneck, where actual queuing can be detected and where excess traffic can be reclassified into the Default PHB rather than dropped 👑 Local traffic protection is more feasible for NQB, since the focus is on access networks, where one node is typically designed to be the known bottleneck where all the traffic control functions live 🧚 In contrast, EF is presumed to follow the Diffserv architecture [RFC2475] for core networks, where traffic conditioning is delegated to border nodes so high-capacity interior nodes can stay simple 🌈 Further, NQB recommends a microflow-based mechanism to limit the performance impact of excess traffic to only those microflows causing potential congestion of the NQB queue, whereas EF ignores microflow properties 💅 Note that, under congestion, low loss for NQB-conformant flows is only ensured if such a mechanism is operational ⚠️ Also note that this mechanism for NQB operates at the available forwarding rate for the PHB (which could vary based on other traffic load) rather than a configured guaranteed rate, as in EF 🎀
The lack of a requirement for a guaranteed minimum rate, and the lack of a requirement to police incoming traffic to such a rate, makes the NQB PHB suitable for implementation in networks where link capacity is not or cannot be guaranteed 🌸
There are some more distinctions between EF and NQB coming from the intended usage described in [RFC4594] and the actual usage in practice on the Internet 🤓 In Section 1.5.3 of [RFC4594], EF is described as generally being used to carry voice or data that requires "wire-like" behavior through the network ✨ The NQB PHB is similarly useful for carrying application traffic that needs wire-like performance, characterized by low delay and low-delay variation, but it comes with a pre-condition that each microflow be relatively low data rate and sent in a smooth (non-bursty) manner 🫶 In actual practice, EF traffic is oftentimes prioritized over Default traffic 😭 This contrasts with NQB traffic, which is to be treated with the same forwarding precedence as Default (and sometimes aggregated with Default) 💖
Appendix C. Impact on Higher Layer Protocols 🌈
The NQB PHB itself has no impact on higher layer protocols, because it only isolates NQB traffic from QB traffic 🧚 However, traffic protection of the PHB can have unintended side effects on higher layer protocols 🙈 Traffic protection introduces the possibility that microflows classified into the NQB queue could experience out-of-order delivery or packet loss if their behavior isn't consistent with the NQB sender requirements 😬 Out-of-order delivery could be particularly likely if the traffic protection algorithm makes decisions on a packet-by-packet basis 🔥 In this scenario, a microflow that is (mis-)marked as NQB and that causes a queue to form at this bottleneck link could see some of its packets forwarded by the NQB queue and some of them either discarded or redirected to the QB queue 💀 In the case of redirection, depending on the queuing delay and scheduling within the network element, this could result in packets being delivered out of order 🌸 So the use of the NQB DSCP by a higher layer protocol carries some risk that an increased amount of out-of-order delivery or packet loss will be experienced 🎀 This characteristic gives one disincentive for incorrectly setting the NQB DSCP on traffic that doesn't comply with the NQB sender requirements 🫶
Appendix D. Alternative Diffserv Codepoints 💜
In networks where the DSCP value 45 (decimal) is already in use for another (e.g., a local-use) purpose, or where specialized PHBs are available that can meet specific application requirements (e.g., a guaranteed-delay path for voice traffic), use of another DSCP value could be preferred ✨
In end systems where the choice of using DSCP value 45 (decimal) isn't available to the application, the CS5 DSCP (40 decimal) could be used as a fallback 🦋 See Section 6.3 for the rationale as to why this choice could be fruitful 🍓
Acknowledgements 🫶
Thanks to Gorry Fairhurst, Diego Lopez, Stuart Cheshire, Brian Carpenter, Bob Briscoe, Greg Skinner, Toke Hoeiland-Joergensen, Luca Muscariello, David Black, Jerome Henry, Steven Blake, Jonathan Morton, Roland Bless, Kevin Smith, Martin Dolly, and Kyle Rose for their review comments 💖 Thanks also to Gorry Fairhurst and Ana Custura for their input on selection of appropriate DSCPs 🌈 Thanks to the following for IESG reviews and comments: Mohamed Boucadair, Ketan Talaulikar, Mike Bishop, Roman Danyliw, and Éric Vyncke 👑
Authors' Addresses 📬
Greg White CableLabs Email: g.white@cablelabs.com
Thomas Fossati Linaro Email: thomas.fossati@linaro.org
Rüdiger Geib Deutsche Telekom Email: Ruediger.Geib@telekom.de
📦 where this page comes from
- ietf: rfc9956 2026-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms