[auth48] Re: AUTH48: RFC-to-be 9956 <draft-ietf-tsvwg-nqb-33> for your review

[Greg White <[e-mail]>]

Hello Megan and Alice,

Thank you for your thorough review of this RFC-to-be!

Please see below, my [GW] responses to these numbered items.  To my coauthors, please review these responses and chime in if you have any disagreement. 

Ruediger, could you specifically look at #18 below to see if you have any suggestions?

Thomas, could you specifically look at #21 below to see if my changes make sense?

In addition, I have included an updated XML ... with two apologies.  The first apology is that I see now your instructions clearly say to submit response inline -OR- via XML, whereas I've done both (some done in the XML, all noted in line below). The second apology is that I re-wrapped many of the paragraphs to make the XML easier to grep, though this may cause problems if you try to run a diff directly.   Please let me know if you want me to do anything differently.

Best Regards,
Greg




On 4/6/26, 11:45 PM, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>> wrote:


Authors,


While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file.


1) <!--[rfced] Please note that we have updated the short title of the
document (that appears in the running header of the PDF output
version) as follows to more closely match the full title. Please
let us know any objections.


Original:
Non-Queue-Building PHB


Current:
NQB PHB for Diffserv
-->

[GW] Ok.


2) <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search <https://www.rfc-editor.org/search>. -->

[GW] I've added:

<keyword>DS</keyword>
<keyword>DSCP</keyword>
<keyword>L4S</keyword>
<keyword>delay</keyword>
<keyword>jitter</keyword>
<keyword>delay variation</keyword>
<keyword>Queuing Delay</keyword>
<keyword>One Way Delay</keyword>
<keyword>Round-Trip Time</keyword>
<keyword>RTT</keyword>
<keyword>Quality of Service</keyword>
<keyword>QoS</keyword>
<keyword>Quality of Experience</keyword>
<keyword>QoE</keyword>


3) <!--[rfced] This sentence is long and employs a lot of hyphenation.
Could we reword as follows to break things up a bit?


Original:
The purpose of this NQB PHB is to provide a separate queue that
enables smooth (i.e. non-bursty), low-data-rate, application-limited
traffic microflows, which would ordinarily share a queue with bursty
and capacity-seeking traffic, to avoid the delay, delay variation and
loss caused by such traffic.


Perhaps:
The purpose of this NQB PHB is to provide a separate queue 
enabling smooth (i.e., non-bursty) traffic microflows that have low data
rates and limited applications to avoid the delay, delay variation,
and loss caused by sharing a queue with bursty, capacity-seeking
traffic (which they ordinarily would have done).
-->

[GW] Your suggestion isn't directly usable, but here is an alternative for consideration.  I've left the XML untouched for now. 

The purpose of this NQB PHB is to provide a separate queue
enabling traffic microflows that are smooth (i.e. non-bursty), 
low-data-rate, and application-limited to avoid the delay, delay variation and
loss that would ordinarily be caused by sharing a queue with bursty, capacity-seeking traffic.


4) <!--[rfced] We had a few questions about this sentence:


a) Does this mean "are discussed in this document"? Or is there
another way to update for clarity?

[GW] It means "are discussed in this document".

b) Are "mobile network radio" and "core segments" two separate entries
in the list?

Original:
In particular, the application of NQB PHB to cable broadband links,
Wi-Fi links, and mobile network radio and core segments are discussed.

Perhaps:
In particular, the application of NQB PHB to cable broadband links,
Wi-Fi links, mobile network radio, and core segments are discussed in
this document.
-->
[GW] it was intended to refer to mobile network radio links and mobile network core segments. These are covered in aggregate in section 7.2.   I've updated the XML to read:
In particular, the application of NQB PHB to cable broadband links,
Wi-Fi links, and mobile network radio/core segments are discussed in this document.



5) <!--[rfced] We had a few questions related the following sentence.


a) This sentence is long. May we break it up as follows?


b) There is an inconsistency in capping for Differentiated Services
with how it was used in the Abstract. We suggest simply using the
abbreviation (as it already appears in the Abstract).


c) We have updated to "have relatively low data rates". Please review
that this captures your intended meaning.


d) We have made a few other punctuation changes. Please review this
text carefully.


Original:
This document defines a Differentiated Services per-hop behavior
(PHB) called the "Non-Queue-Building Per-Hop Behavior" (NQB PHB),
which isolates traffic microflows (application-to-application flows,
see Section 1.2 of [RFC2475]) that are relatively low data rate and
that do not themselves materially contribute to queuing delay and
loss, allowing them to avoid the queuing delay and losses caused by
other traffic.


Perhaps:
This document defines a Diffserv PHB called the "Non-Queue-Building
Per-Hop Behavior" (or "NQB PHB"). The NQB PHB isolates traffic
microflows (application-to-application flows, see Section 1.2 of
[RFC2475]) that have relatively low data rates and that do not,
themselves, materially contribute to queuing delay and loss. This
isolation allows these traffic microflows to avoid the queuing
delay and losses caused by other traffic.
-->

[GW] Yes, fine & done.


6) <!--[rfced] We have attempted to break up the following sentence and
clarify its intended meaning. Please review and confirm that this
rewording maintains what you are trying to say (and if not,
please submit a new rewording).


Original:
Such Non-Queue-Building microflows (for example:
interactive voice, game sync packets, certain machine-to-machine
applications, DNS lookups, and some real-time IoT analytics data) are
low-data-rate application-limited microflows that are distinguished
from bursty traffic microflows and high-data-rate traffic microflows
managed by a classic congestion control algorithm, both of which
cause queuing delay and loss.


Current:
Non-Queue-Building microflows such as interactive voice, game sync
packets, certain machine-to-machine applications, DNS lookups, and
some real-time Internet of Things (IoT) analytics data are
low-data-rate, application-limited microflows. These can be
distinguished from bursty traffic microflows and high-data-rate
traffic microflows managed by a classic congestion control algorithm
(both of which cause queuing delay and loss).
-->

[GW] Yes, fine.


7) <!--[rfced] We had a few questions related to the example commonly
deployed congestion control algorithms:


a) We note that RFC 9438 uses "CUBIC" (not "Cubic"). Should this text
be updated (along with other mentions throughout the text and the
mentions in draft-briscoe-docsis-q-protection-07)?


Original:
...such as Reno [RFC5681], Cubic [RFC9438] or BBR
[I-D.ietf-ccwg-bbr],...


Perhaps:
...such as Reno [RFC5681], CUBIC [RFC9438] or BBR [BBR-CC],...


b) We note that RFC 5681 does not mention the word "Reno" in the body
of the document. We do see it point to some Informative Reference
entries on the topic (RFC 3782 and
ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z.) Please review and let us
know if the pointer to RFC 5681 should be updated to something else.


Original:
...congestion control algorithms, such as Reno [RFC5681],
Cubic...
-->

[GW] Yes, on "CUBIC".  RFC5681 is correct (other RFCs have used, for example (from 9438):
"classical Reno congestion control [RFC5681]." ).


8) <!--[rfced] We have broken up this sentence and removed "in
particular" as we were uncertain which part of the sentence it
applied to. Please review to ensure we have maintained your
intended meaning.


Original:
In contrast to applications that frequently cause queuing delay,
there are a variety of relatively low data rate applications that do
not materially contribute to queuing delay and loss but are
nonetheless subjected to it by sharing the same bottleneck link in
the access network, in particular.


Current:
In contrast to applications that frequently cause queuing delay, there
are a variety of relatively low data rate applications that do not
materially contribute to queuing delay and loss; nonetheless, they are
subjected to it by sharing the same bottleneck link in the access
network.
-->

[GW] The "in particular" was referring to the phrase "in the access network".  For reference, the Abstract states: "The NQB PHB has been developed primarily for use by access network segments, where queuing delay and queuing loss caused by Queue-Building protocols are manifested, but its use is not limited to such segments."  If we need to delete the words "in particular", I would then also delete the words "in the access network". 




9) <!-- [rfced] We note that Section 6.6 appears to use the term
"lower-rate" rather than "lower-speed" as indicated in the text
below. Please let us know if/how to update.


Original:
The applicability of this PHB to lower-speed links is discussed in
Section 6.6.
-->

[GW] lower-rate is fine.


10) <!--[rfced] May we remove "and" from this sentence? That is, is 
PHB designed for broadband access network links that have buffers
that are deep? Or is the last clause applicable to "minimal
aggregation of traffic"?


Original:
This PHB is designed for broadband access network links, where there
is minimal aggregation of traffic, and especially when buffers are
deep (see Section 3.4).


Perhaps A:
This PHB is designed for broadband access network links, where there
is minimal aggregation of traffic, especially when buffers are
deep (see Section 3.4).


Perhaps B:
This PHB is designed for broadband access network links, where there
is minimal aggregation of traffic (especially when buffers are
deep (see Section 3.4)).
-->

[GW] I think it would be better as:  
This PHB is designed for broadband access network links (where there
is minimal aggregation of traffic), especially when buffers are
deep (see Section 3.4).


11) <!-- [rfced] We see that [RFC2474] uses "DS" rather than "Diffserv"
for "Differentiated Services". It also uses "codepoint" rather
than "code point". Please review and let us know if/how to
update uses in this document.


Original:
The architecture defines the use of the Diffserv field [RFC2474] for
this purpose, and numerous RFCs have been written that describe
recommended interpretations of the values (Diffserv Code Points
[RFC2474]) of the field, and standardized treatments (traffic
conditioning and per-hop-behaviors [RFC2475]) that can be implemented
to satisfy the performance requirements of traffic so marked.
-->

[GW] Please align the terminology with RFC2474:  "DS" instead of "Diffserv", "codepoint" instead of "code point".




12) <!--[rfced] Is there a way to avoid saying "treated..as treatment"?


Original:
In nodes that support multiple DiffServ Service Classes, NQB traffic
is intended to be treated as a part of the Default treatment.


Perhaps:
In nodes that support multiple Diffserv Service Classes, NQB traffic
is intended to be handled as a part of the Default treatment.
-->

[GW] Yes, fine & done.



13) <!--[rfced] Is there a way to rephrase to avoid so many uses of variants of
"require"?


Original:
Note that these requirements in turn require compliance with all the
requirements in Section 5 of [RFC9331].
-->

[GW] Instead of "require", maybe "necessitate", "imply", "call for", or "involve"?


14) <!-- [rfced] We note that Section 4 of [RFC9331] uses the term
"'Prague L4S Requirements'" rather than "L4S 'Prague'
requirements". Please review and let us know if/how to update.


Original:
Applications that comply with both the NQB sender requirements in
Section 4 and the L4S "Prague" requirements in Section 4 of [RFC9331]
could mark their packets both with the NQB DSCP and with the ECT(1)
value.
-->

[GW] Changed to "Prague L4S Requirements"



15) <!--[rfced] Does "around" mean "related to" in this text? 


Original:


Microflows marked with the NQB DSCP are expected to comply with
existing guidance for safe deployment on the Internet, including the
guidance around response to network congestion, for example the
requirements in [RFC8085] and Section 2 of [RFC3551] (also see the
circuit breaker limits in Section 4.3 of [RFC8083] and the
description of inelastic pseudowires in Section 4 of [RFC7893]).


Perhaps:


Microflows marked with the NQB DSCP are expected to comply with
existing guidance for safe deployment on the Internet, including the
guidance related to responses to network congestion, for example the
requirements in [RFC8085] and Section 2 of [RFC3551] (also see the
circuit breaker limits in Section 4.3 of [RFC8083] and the
description of inelastic pseudowires in Section 4 of [RFC7893]).
-->

[GW] Yes, fine & done.


16) <!--[rfced] Might breaking this text into a list be easier for the
reader?


Original:
Thus, a useful property of nodes (i.e. network switches and
routers) that support separate queues for NQB and QB microflows is
that for microflows consistent with the NQB sender requirements in
Section 4, the NQB queue would likely be a better choice than the QB
queue; and for microflows inconsistent with those requirements, the QB
queue would likely be a better choice than the NQB queue.


Perhaps:
Thus, a useful property for nodes (i.e., network switches and routers)
that support separate queues for NQB and QB microflows would be to
behave as follows:


* for microflows consistent with the NQB sender requirements in 
Section 4, the NQB queue would likely be a better choice than 
the QB queue and


* for microflows inconsistent with the requirements in Section 4,
the QB queue would likely be a better choice than the NQB queue.
-->

[GW] I personally prefer the original. 



16.5) <!-- We note that [RFC5685] uses "VOICE-ADMIT" rather than
     "Voice-Admit". Please review and let us know if/how to update.

Original:
   In the preceding sentence, "VA" and "CSx" refer to Voice-Admit
   ([RFC5865]) and Class Selector ([RFC2474]) respectively.
-->

[GW] Changed to "VOICE-ADMIT"



17) <!--[rfced] Section 6.3: We thank you for the note at the end of this
section about citing an obsoleted RFC. Is the note meant to
remain in the document at publication? If so, may we put it in
the <aside> element?


Original:
[NOTE: this section references the obsoleted RFC2598 instead of its
replacement RFC3246, because the former contains the description of
EF performance.]
-->


[GW] I think it is unnecessary to keep the NOTE.



18) <!--[rfced] Perhaps it would be helpful to the reader to describe 
what part of RFC 8100 is being used here?


Original:
If [RFC8100] is operational between interconnected domains, the
receiving domain may prefer a different DSCP for NQB traffic that
allows for a DSCP range-based classification for the Default / Elastic
Treatment Aggregate.
-->

[GW] I will defer to Ruediger on this one.  


19) <!-- [rfced] We note that Section 4 of [RFC2475] uses "Class Selector
codepoint" rather than "Class Selector Codepoint". Please review
and let us know if/how to update.


Original:
In such cases, Section 4 of [RFC2475] suggests that the upstream
domain opportunistically re-mark traffic with a Class Selector
codepoint or DSCP 0 (Default) under the assumption that traffic so
marked would be handled in a predictable way by the downstream domain.
-->

[GW] "Codepoint" is fine, done.


20) <!--[rfced] Note that we have changed IPSec to IPsec to match the
following from RFC 4301:


The spelling "IPsec" is preferred and used throughout this and all
related IPsec standards. All other capitalizations of IPsec (e.g.,
IPSEC, IPSec, ipsec) are deprecated.
-->


[GW] fine.


21) <!--[rfced] May we update as follows for the ease of the reader?
Please review carefully to ensure we've maintained your intended
meaning.


Original:
To support the NQB PHB, the mobile network could be configured to
give User Equipment (UE, the mobile device used by the subscriber) a
dedicated, low-latency, non-GBR (non-Guaranteed Bit Rate), EPS
(Evolved Packet System, the core and access network architecture used
in LTE) bearer, e.g., one with QCI 7 (QoS Class Identifier 7, which
is typically used for low-latency, non-GBR services), in addition to
the default EPS bearer.


Perhaps:
In addition to the default EPS bearer and to support the NQB PHB,
the mobile network could be configured to give User Equipment (UE)
(the mobile device used by the subscriber) a bearer that is
a dedicated, low-latency, non-Guaranteed Bit Rate (non-GBR) Evolved
Packet System (EPS) (the core and access network architecture used
in LTE). For example, it could give a bearer with QCI 7 (QoS Class
Identifier 7), which is typically used for low-latency, non-GBR
services.


-->

[GW] I agree that this sentence isn't an easy read.  I also note your comment 30a below relating to the term "bearer".  I've done a pass through this (with some help from AI) to rearrange the wording to see if we can clean it up.  I would appreciate review by Thomas that this text is concise and accurate. 

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
7.2 Mobile Networks
Historically, 3GPP mobile networks have utilized "bearers" to encapsulate each user's user plane traffic through the radio access and core networks. Bearers are also associated with a Quality of Service (QoS) that determines how packets are prioritized at queues and radio schedulers. In LTE networks, these are EPS bearers, part of the Evolved Packet System (EPS), which comprises 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, and a best-effort default EPS bearer for Internet traffic. This default EPS bearer is typically non-Guaranteed Bit Rate (non-GBR) and provides no guarantees; its buffering characteristics generally are 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 are mapped to Data Radio Bearers (DRBs) on the radio network. 5G systems offer more flexibility in QoS handling, allowing traffic to be treated according to type (e.g., loss-tolerant, low-latency); hence, they support more suitable treatment of Internet real-time microflows.

To support the NQB PHB, an LTE network could be configured to provide the User Equipment (UE, the subscriber's device) with 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. Alternatively, 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 be routed through the default bearer.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


22) <!-- [rfced] Figure 1 in RFC 8325 has header information that might be
helpful to the reader to include in the update in this document. 
Would you like us to add the header to the figure?


Perhaps:
+===============+======+==========+==================================+
| IETF Diffserv | PHB |Reference | IEEE 802.11 |
| Service Class | | RFC |User Priority| Access Category |
|===============+======+==========+=============+====================|
-->

[GW] Sure.


23) <!-- [rfced] FYI, for the [Custura] reference, we found a PDF for this
article from the TMA website and added it. Please let us know if you
have any objections.
-->

[GW] Yes, fine.


24) <!-- [rfced] FYI, for the [Barik] reference, we found a PDF for 
this article from the International Teletraffic Congress (ITC) website
(https://itc-conference.org/itc-library/itc30.html <https://itc-conference.org/itc-library/itc30.html>) and added it.
-->

[GW] ok.




25) <!--[rfced] Please review the [SA-5G] reference entry. According to
the URL, the most current version is 20.0.0. Should the
reference entry be updated to point to that version? -->

[GW] Only if Table 5.7.4-1 is still:  Standardized 5QI to QoS characteristics mapping



26) <!-- [rfced] Please review reference entry [IEEE802-11]. This
reference points to a superseded version of IEEE Std 802.11 from
2020. The most current version is IEEE Std 802.11-2024. Would you
like this reference to point to the most current version? -->

[GW] Yes, that’s fine.


27) <!-- [rfced] The date for the [TR-369] reference is January 2022;
however, the URL for this reference points to a Broadband Forum
specification with an issue date of July 2025.


We have updated this reference to match the information provided at
the URL. Please let us know if you have any objections.
-->

[GW] Yes, that is fine.



28) <!-- [rfced] The [Gettys2021] reference points to an article from
the "Communications of the ACM"; however, the DOI provided for this
reference (https://doi.org/10.1145/2063166.2071893 <https://doi.org/10.1145/2063166.2071893>) points
to an article from "ACM Queue" with a different publication date.


We updated this reference to point to the DOI for the "Communications
of the ACM" version of this article (note that this version is also
free access): https://dl.acm.org/doi/10.1145/2063176.2063196 <https://dl.acm.org/doi/10.1145/2063176.2063196>.
-->

[GW] Yes, that is fine.


29) <!-- [rfced] Please review reference [Cardwell2017]. The author
information provided for this reference did not match in the
information at the URL. We have updated this reference to match
what was available at the URL.


Original:
[Cardwell2017]
Cardwell, N., Cheng, Y., Jacobson, V., Iyengar, J., Swett,
I., and B. Yan, "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> <https://doi.org/10.1145/3009824&gt;>.
Current:
[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> <https://doi.org/10.1145/3009824&gt;>.
-->

[GW] Yes, that is fine.


30) <!--[rfced] We had the following questions related to terminology used
throughout the document:


a) Please review how terms with bearer are treated in the Mobile
Networks section. For instance, we see:


"bearer"
"dedicated bearer"
"best effort" bearer
"best effort" default bearer
default EPS bearer
Data Radio Bearer


Should these be made more similar in terms of quotation and
capitalization? If so, please let us know which forms are preferred.

[GW] See #21 above. 

b) Please review the use of the following similar values:


i) DSCP value 45 (decimal) vs. DSCP 45 (decimal) vs. DSCP 45


May these be made consistently:


DSCP value 45 (decimal)


ii) NQB DSCP 45 (decimal) vs. NQB DSCP (45 decimal) vs. NQB (45)
vs. NQB DSCP (45) vs. NQB (45) value


May these be made consistently:


NQB DSCP 45 (decimal)


iii) 45 (decimal)


Can you review these uses and let us know if they refer to i or ii above?


[GW] These all refer to the same concept, and many (though not all) of them could be normalized. I found 31 instances, here is the accounting:

  10 NQB DSCP 45 (decimal)
   6 DSCP value 45 (decimal)
   5 DSCP 45 (decimal)
   2 45 (decimal)
   2 DSCP 45
   1 NQB DSCP (45 decimal)
   1 NQB DSCP (45)
   1 NQB DSCP value 45
   1 NQB (45)
   1 Diffserv Code Point (DSCP) 45 (decimal)
   1 DSCP value other than 45 (decimal)

Do you prefer "DSCP value 45 (decimal)" when that fits?

Here are the 31 occurences: 

In accordance with this, applications are <bcp14>RECOMMENDED</bcp14> to use the Diffserv Code Point (DSCP) 45 (decimal) to mark microflows as NQB.

The choice of the DSCP value 45 (decimal) is motivated, in part, by the desire to achieve separate queuing in existing Wi-Fi networks (see <xref target="wifi"/>) and by the desire to make implementation of the PHB simpler in network equipment that has the ability to classify traffic based on ranges of DSCP values (see <xref target="aggregation2"/> for further discussion). </t>

<t>By default, a node supporting the NQB PHB <bcp14>SHOULD</bcp14> by classify packets marked with the NQB DSCP 45 (decimal) into the queue for Non-Queue-Building traffic.

The assigned NQB DSCP (45 decimal) is recommended for use as the default classifier to distinguish NQB traffic from traffic classified as Default (DSCP 0) (see Sections <xref target="sender" format="counter"/> and <xref target="primary" format="counter"/>).</t>

As noted in <xref target="sender"/>, the choice of the DSCP value 45 (decimal) is motivated in part by the desire to make this aggregation simpler in network equipment that can classify packets via comparing the DSCP value to a range of configured values.</t>

<t>If NQB support is extended across a DiffServ domain boundary, the interconnected networks agreeing to support NQB <bcp14>SHOULD</bcp14> use the DSCP value 45 (decimal) for NQB at network interconnection, unless a different DSCP is explicitly documented in the TCA (Traffic Conditioning Agreement, see <xref target="RFC2475"/>) for that interconnection.

Similar to the handling of DSCPs for other PHBs (and as discussed in <xref target="RFC2475"/>), networks can re-mark NQB traffic to a DSCP value other than 45 (decimal) for internal usage.

<t>In addition to the requirements provided in other sections of this document, to support the NQB PHB, Wi-Fi equipment (including equipment compliant with <xref target="RFC8325"/>) <bcp14>SHOULD</bcp14> map the NQB DSCP 45 (decimal) 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 <bcp14>RECOMMENDED</bcp14> that Wi-Fi equipment provide a separate queue in UP 0 and map the NQB DSCP 45 (decimal) to that queue.

If a separate queue in UP 0 cannot be provided (due to hardware limitations, etc.), a Wi-Fi device <bcp14>MAY</bcp14> map the NQB DSCP 45 (decimal) to UP 3.</t>

<t>The DSCP value 45 (decimal) is recommended for NQB (see <xref target="sender"/>).

The rationale for the choice of DSCP 45 (decimal) as well as its ramifications and remedies for its limitations are discussed further below.</t>

<li>Application instances on Wi-Fi client devices are already free to choose any Access Category that they wish, regardless of their sending behavior, without any policing of usage. So, the choice of using DSCP 45 (decimal) for NQB creates no new avenues for non-NQB-compliant client applications to exploit the prioritization function in Wi-Fi. </li>

<li>For application traffic that originates outside of the Wi-Fi network, and, thus, is transmitted by the Access Point, the choice of DSCP 45 does create a potential for abuse by non-compliant applications.  However, opportunities exist 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 <xref target="unmanaged"/>. 

<t>As stated above, the use of DSCP 45 (decimal) for NQB is not expected to create incentives for abuse by non-compliant applications in the Wi-Fi uplink direction.

This conclusion is not expected to be disturbed by network support for NQB increasing the likelihood of DSCP 45 traffic traversing network boundaries without change to the DSCP, as that likelihood of increased network boundary traversal is balanced by a likelihood of NQB traffic encountering the traffic-limiting aspects of NQB support, traffic protection, and shallow buffers, which limit the potential for abuse.</t>

<t>Systems that utilize <xref target="RFC8325"/> but cannot provide a separate AC_BE queue for NQB traffic <bcp14>SHOULD</bcp14> map the NQB DSCP 45 (decimal) (or the locally determined alternative) to UP 5 in the "Video" Access Category as well (see <xref target="updates_to_8325"/>).</t>

<blockquote>RFC 9956 defines a shallow-buffered, best-effort service for traffic marked with the NQB DSCP 45 (decimal) and recommends the following treatment in Wi-Fi equipment. 

It is <bcp14>RECOMMENDED</bcp14> that Wi-Fi equipment map the NQB DSCP 45 (decimal) 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 <bcp14>RECOMMENDED</bcp14> that Wi-Fi equipment provide a separate queue in UP 0 and map the NQB DSCP 45 (decimal) to that queue. 

If a separate queue in UP 0 cannot be provided (due to hardware limitations, etc.), a Wi-Fi device <bcp14>MAY</bcp14> map the NQB DSCP 45 (decimal) to UP 3. If neither of these options provides a separate queue from Default traffic, it is <bcp14>RECOMMENDED</bcp14> that Wi-Fi equipment map the NQB DSCP 45 (decimal) to UP 5 

<blockquote>An exception to this is the NQB DSCP 45 (decimal), which encodes for best-effort service.</blockquote>

<t>IANA has assigned the Differentiated Services Field Codepoint (DSCP) 45 from the "Differentiated Services Field Codepoints (DSCP)" registry (<eref target="https://www.iana.org/assignments/dscp-registry/"/>) ("DSCP Pool 3 Codepoints", Codepoint Space xxxx01, Standards Action (<xref target="RFC8126" format="default"/>) for Non-Queue-Building behavior.</t>

These existing Wi-Fi networks currently provide priority to half of the DSCP space, whether or not 45 (decimal) is assigned to the NQB DSCP.

<t>Regarding the DSCP value 45 (decimal), there were no observations of DSCP manipulation reported in which traffic was marked 45 (decimal) by any of these policies.

Thus, it appears that these re-marking policies would be unlikely to result in QB traffic being marked as NQB (45).

<t>In the policies where the top three bits are overwritten (see <xref target="RFC9435" section="4.2"/>), the NQB DSCP (45) would receive the same marking as would the currently unassigned Pool 3 DSCPs (5, 13, 21, 29, 37, 53, and 61), with all of these DSCPs getting re-marked to DSCP = 5, 13, or 21 (depending on the overwrite value used).

If networks in which this sort of re-marking occurs or networks downstream classify the resulting DSCP (i.e., 5, 13, or 21) to the NQB PHB or re-mark such traffic as 45 (decimal), they risk giving NQB treatment to other traffic that was not originally marked as NQB.

<t>For the policy in which the low three bits are set to 0b000, the NQB DSCP value 45 (decimal) would be re-marked to CS5 and would be indistinguishable from CS5, VA, and EF (and the currently unassigned DSCPs 41, 42, and 43).

<t>In networks where the DSCP 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.</t>

<t>In end systems where the choice of using DSCP 45 (decimal) is not available to the application, the CS5 DSCP (40 decimal) could be used as a fallback.

[GW] I've made no changes on this yet. If you can confirm the preferred terminology, I will review each instance and check whether it works. 


iv) May we treat other DSCP numbers similarly? Some examples:


Current:
...DSCPs 41, 42, 43).


Perhaps:
...DSCP values 41, 42, and 43 (all decimal)).

[GW] Yes.


Current:
...CS5 DSCP (40 decimal)


Perhaps:
... CS5 DSCP value 40 (decimal)

[GW] Yes.

c) Please review these similar uses for consistency:


classic congestion control algorithm
"classic congestion control" (capped because introducing a term)


In the companion document (draft-briscoe-docsis-q-protection-07), we see:


'Classic" congestion control (and 'Scalable' congestion control)
Classic queue
Classic traffic
classic congestion controllers


Should these be made more consistent within the cluster?

[GW] In this document, the term is used as it was defined in RFC9330 (which it references). For draft-briscoe-docsis-q-protection-07, it would be worth reviewing those instances to see if they could be made more consistent with this document and with RFC9330.



Further, is the Classic queue the same as the Default queue? Or are these different things?

[GW] They are slightly different, but overlapping ideas.  There are some related features in these three documents that discuss DualQ networking:
 A.  L4S DualQ Coupled AQM (RFC9332) [defines "L4S queue" (aka "L queue", aka "low-latency queue") and "Classic queue" (aka "C queue")]
 B.  NQB PHB (this document) [defines "NQB queue" and "Default queue"] 
 C. QProt (draft-briscoe-docsis-q-protection-07) [uses "L4S queue"/"L queue" and "Classic queue"/"C queue"]
A particular piece of network equipment could support A and/or B, and optionally C. If it supports both A & B, then the L queue and the NQB queue can be one and the same, similarly the C queue and the Default queue can be one and the same (this is discussed a bit in section 2.3 of RFC9332, in section 3.3 of this document, and in section 3 of QProt).
The DOCSIS Specification that was the source material for QProt, was drafted to describe a system that supports all 3, and it adopted the terminology of RFC 9332 (or perhaps the early drafts that became RFC9332).  
The NQB PHB draft was drafted to be separable from the L4S functionality, so used distinct terms NQB queue and Default queue (where Default is a term from RFC 2474). 



d) We several uses like the following:


Original:
...that are relatively low data rate...


...be relatively low data rate...


Where we would have expected "have a relatively low data rate". May
we update these as such?

[GW] Yes. 

[GW] In addition, in Appendix A, I see:  " the same general properties as NQB traffic (non-capacity-seeking and very low data rate, relatively low data rate, and consistent data rate).", which probably looks strange to a reader.  The descriptions inside the parentheses were intended to map directly to the list "CS5, VA, and EF" one-for-one. 
So perhaps:
" the same general properties as NQB traffic (non-capacity-seeking and very low data rate, relatively low data rate, and consistent data rate, respectively)."
Or:
" the same general properties as NQB traffic (non-capacity-seeking and very low data rate for CS5, relatively low data rate for VA, and consistent data rate for EF)."


e) Please let us know if the following terms should be made consistent
and if so which of the following forms is preferred with relation to
capitalization, quotation, spelling, etc. 


Note: "Diffserv" (rather than "DiffServ") is preferred, as noted 
on the Terms list (https://www.rfc-editor.org/rpc/wiki/doku.php?id=terms <https://www.rfc-editor.org/rpc/wiki/doku.php?id=terms>).


Best Effort Access Category vs. "Best Effort" Access Category
(see also best-effort service
[GW] Yes, done. For consistency, I also removed quotation marks from "Video" Access Category.

Default vs. default
[GW] These are correct in the document as written, and used in a consistent manner as in RFC2474.

differentiated service class vs. DiffServ Service Classes
[GW] correct as written. 

differentiated services vs. Differentiated Services
[GW] done. 

Diffserv Domain vs. DiffServ domain vs. Diffserv domain
[GW] I'm unsure.  RFC2474 defines "Differentiated Services Domain", but then uses "DS domain" throughout.

Field vs. field (when describing Diffserv or DSCP)
[GW] RFC 2474 seems to use "DS field"

higher-than-necessary vs. higher-than-needed
[GW] done.

low data rate applications vs. low-rate applications
[GW] I see no instances of the latter.

quality of experience vs. Quality of Experience
[GW] done

Video Access Category vs. "Video" Access Category
[GW] done, see above.

f) We'd like to add hyphens to these terms, so they would appear as
follows. Please let us know if this is acceptable.


delay-sensitive applications / traffic
high-capacity interior nodes
low-data-rate microflow / application
low-delay performance / variation services
low-latency queue (both forms are used in RFCs 9330-9332)
rate-shaped capacity
rate-shaping function
-->
[GW] all are ok, except "low-delay variation services".   That one should be "low-delay-variation services" (low modifies variation which modifies delay). 



31) <!-- [rfced] We had the following comments/questions related to
abbreviation use throughout the document:


a) We have added expansions for abbreviations upon first use per
Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.


b) How may we expand the following abbreviations on first use?


CE
AS

[GW] CE = Congestion Experienced; AS appears once but is practically a lexicalized initialism in the IETF, so I wouldn't replace it with "Autonomous System".

c) FYI - We will remove expansions (i.e., use the abbreviation) for
instances of the expanded form of abbreviations on uses subsequent to
initial expansion for the following (per the guidance at
https://www.rfc-editor.org/styleguide/part2/#exp_abbrev <https://www.rfc-editor.org/styleguide/part2/#exp_abbrev>):


NQB
QB
DSCP
TCA
CS
QoS
EDCA
EF
-->

[GW] ok.


32) <!-- [rfced] Please review the "Inclusive Language" portion of the online 
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language&gt;>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.


Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice.




In addition, please consider whether "traditional" and "traditionally"
should be updated for clarity. While the NIST website
<https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1> <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1&gt;>
indicates that this term is potentially biased, it is also ambiguous.
"Tradition" is a subjective term, as it is not the same for everyone.
-->

[GW] The first instance: "has traditionally been defined." can be replaced by "has previously been defined."
The second instance: "a more traditional Traffic Conditioning approach and police the application of the NQB DSCP" can be replaced by "a Traffic Conditioning approach that polices the application of the NQB DSCP"



Thank you.


Megan Ferguson and Alice Russo
RFC Production Center




On Apr 6, 2026, [e-mail] <mailto:[e-mail]> wrote:


*****IMPORTANT*****


Updated 2026/04/06


RFC Author(s):
--------------


Instructions for Completing AUTH48


Your document has now entered AUTH48. Once it has been reviewed and 
approved by you and all coauthors, it will be published as an RFC. 
If an author is no longer available, there are several remedies 
available as listed in the FAQ (https://www.rfc-editor.org/faq/ <https://www.rfc-editor.org/faq/>).


You and you coauthors are responsible for engaging other parties 
(e.g., Contributors or Working Group) as necessary before providing 
your approval.


Planning your review 
---------------------


Please review the following aspects of your document:


* RFC Editor questions


Please review and resolve any questions raised by the RFC Editor 
that have been included in the XML file as comments marked as 
follows:


<!-- [rfced] ... -->


These questions will also be sent in a subsequent email.


* Changes submitted by coauthors 


Please ensure that you review any changes submitted by your 
coauthors. We assume that if you do not speak up that you 
agree to changes submitted by your coauthors.


* Content 


Please review the full content of the document, as this cannot 
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references


* Copyright notices and legends


Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions 
(TLP – https://trustee.ietf.org/license-info <https://trustee.ietf.org/license-info>).


* Semantic markup


Please review the markup in the XML file to ensure that elements of 
content are correctly tagged. For example, ensure that <sourcecode> 
and <artwork> are set correctly. See details at 
<https://authors.ietf.org/rfcxml-vocabulary> <https://authors.ietf.org/rfcxml-vocabulary&gt;>.


* Formatted output


Please review the PDF, HTML, and TXT files to ensure that the 
formatted output, as generated from the markup in the XML file, is 
reasonable. Please note that the TXT will have formatting 
limitations compared to the PDF and HTML.




Submitting changes
------------------


To submit changes, please reply to this email using ‘REPLY ALL’ as all 
the parties CCed on this message need to see your changes. The parties 
include:


* your coauthors


* [e-mail] <mailto:[e-mail]> (the RPC team)


* other document participants, depending on the stream (e.g., 
IETF Stream participants are your working group chairs, the 
responsible ADs, and the document shepherd).


* [e-mail] <mailto:[e-mail]>, which is a new archival mailing list 
to preserve AUTH48 conversations; it is not an active discussion 
list:


* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc>


* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/ <https://mailarchive.ietf.org/arch/browse/auth48archive/>


* Note: If only absolutely necessary, you may temporarily opt out 
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you 
have dropped the address. When the discussion is concluded, 
[e-mail] <mailto:[e-mail]> will be re-added to the CC list and 
its addition will be noted at the top of the message. 


You may submit your changes in one of two ways:


An update to the provided XML file
— OR —
An explicit list of changes in this format


Section # (or indicate Global)


OLD:
old text


NEW:
new text


You do not need to reply with both an updated XML file and an explicit 
list of changes, as either form is sufficient.


We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text, 
and technical changes. Information about stream managers can be found in 
the FAQ. Editorial changes do not require approval from a stream manager.




Approving for publication
--------------------------


To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.




Files 
-----


The files are available here:
https://www.rfc-editor.org/authors/rfc9956.xml <https://www.rfc-editor.org/authors/rfc9956.xml>
https://www.rfc-editor.org/authors/rfc9956.html <https://www.rfc-editor.org/authors/rfc9956.html>
https://www.rfc-editor.org/authors/rfc9956.pdf <https://www.rfc-editor.org/authors/rfc9956.pdf>
https://www.rfc-editor.org/authors/rfc9956.txt <https://www.rfc-editor.org/authors/rfc9956.txt>


Diff file of the text:
https://www.rfc-editor.org/authors/rfc9956-diff.html <https://www.rfc-editor.org/authors/rfc9956-diff.html>
https://www.rfc-editor.org/authors/rfc9956-rfcdiff.html <https://www.rfc-editor.org/authors/rfc9956-rfcdiff.html> (side by side)


Diff of the XML: 
https://www.rfc-editor.org/authors/rfc9956-xmldiff1.html <https://www.rfc-editor.org/authors/rfc9956-xmldiff1.html>




Tracking progress
-----------------


The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9956 <https://www.rfc-editor.org/auth48/rfc9956>


Please let us know if you have any questions. 


Thank you for your cooperation,


RFC Editor


--------------------------------------
RFC9956 (draft-ietf-tsvwg-nqb-33)


Title : A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services
Author(s) : G. White, T. Fossati, R. Geib
WG Chair(s) : Martin Duke, Zaheduzzaman Sarker
Area Director(s) : Gorry Fairhurst, Mike Bishop