rfc9956.original.xml		rfc9956.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version='1.0' encoding='UTF-8'?>
	<!-- This template is for creating an Internet Draft using xml2rfc,
	which is available here: http://xml.resource.org. -->
	<!DOCTYPE rfc >
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
	<!-- used by XSLT processors -->
	<!-- For a complete list and description of processing instructions (PIs),
	please see http://xml.resource.org/authoring/README.html. -->
	<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
	might want to use.
	(Here they are set differently than their defaults in xml2rfc v1.32) -->
	<?rfc strict="yes" ?>
	<!-- give errors regarding ID-nits and DTD validation -->
	<!-- control the table of contents (ToC) -->
	<?rfc toc="yes"?>
	<!-- generate a ToC -->
	<?rfc tocdepth="4"?>
	<!-- the number of levels of subsections in ToC. default: 3 -->
	<!-- control references -->
	<?rfc symrefs="yes"?>
	<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
	<?rfc sortrefs="yes" ?>
	<!-- sort the reference entries alphabetically -->
	<!-- control vertical white space
	(using these PIs as follows is recommended by the RFC Editor) -->
	<?rfc compact="yes" ?>
	<!-- do not start each main section on a new page -->
	<?rfc subcompact="no" ?>
	<!-- keep one blank line between list items -->
	<!-- end of list of popular I-D processing instructions -->
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
	tf-tsvwg-nqb-33" ipr="trust200902" obsoletes="" updates="8325" submissionType="I
	ETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true"
	version="3" consensus="true">
	<!-- xml2rfc v2v3 conversion 2.39.0 -->
	<!-- category values: std, bcp, info, exp, and historic
	ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
	,
	or pre5378Trust200902
	you can add the attributes updates="NNNN" and obsoletes="NNNN"
	they will automatically be output with "(if approved)" -->
	<!-- ***** FRONT MATTER ***** -->		<!DOCTYPE rfc [
			<!ENTITY nbsp "&#160;">
			<!ENTITY zwsp "&#8203;">
			<!ENTITY nbhy "&#8209;">
			<!ENTITY wj "&#8288;">
			]>
	<front>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
	<!-- The abbreviated title is used in the page header - it is only necessary		tf-tsvwg-nqb-33" number="9956" ipr="trust200902" obsoletes="" updates="8325" sub
	if the		missionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" s
	full title is longer than 39 characters -->		ortRefs="true" version="3" consensus="true">
	<title abbrev="Non-Queue-Building PHB">A Non-Queue-Building Per-Hop Behavior		<front>
	(NQB PHB) for Differentiated Services</title>		<title abbrev="NQB PHB for Diffserv">A Non-Queue-Building Per-Hop Behavior (
	<seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-nqb-33"/>		NQB PHB) for Differentiated Services</title>
	<!-- add 'role="editor"' below for the editors if appropriate -->
	<!-- Another author who claims to be an editor -->		<!--[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
			-->
			<seriesInfo name="RFC" value="9956"/>
	<author fullname="Greg White" initials="G." surname="White">		<author fullname="Greg White" initials="G." surname="White">
	<organization>CableLabs</organization>		<organization>CableLabs</organization>
	<address>		<address>
	<email>g.white@cablelabs.com</email>		<email>g.white@cablelabs.com</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Thomas Fossati" initials="T." surname="Fossati">		<author fullname="Thomas Fossati" initials="T." surname="Fossati">
	<organization>Linaro</organization>		<organization>Linaro</organization>
	<address>		<address>
	<email>thomas.fossati@linaro.org</email>		<email>thomas.fossati@linaro.org</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Rüdiger Geib" initials="R." surname="Geib">		<author fullname="Rüdiger Geib" initials="R." surname="Geib">
	<organization>Deutsche Telekom</organization>		<organization>Deutsche Telekom</organization>
	<address>		<address>
	<email>Ruediger.Geib@telekom.de</email>		<email>Ruediger.Geib@telekom.de</email>
	</address>		</address>
	</author>		</author>
	<date year="2025"/>		<date year="2026" month="April"/>
	<!-- Meta-data Declarations -->		<area>WIT</area>
			<workgroup>tsvwg</workgroup>
	<area>Transport</area>		<!-- [rfced] Please insert any keywords (beyond those that appear in
	<workgroup>Transport Area Working Group</workgroup>		the title) for use on https://www.rfc-editor.org/search. -->
	<keyword/>
	<!-- Keywords will be incorporated into HTML output		<keyword>example</keyword>
	files in a meta tag but they have no effect on text or nroff
	output. If you submit your draft to the RFC Editor, the
	keywords will be used for the search engine. -->
	<abstract>		<abstract>
	<t> This document specifies characteristics of a Non-Queue-Building Per-Ho		<t> This document specifies characteristics of a Non-Queue-Building Per-Ho
	p Behavior (NQB PHB). The NQB PHB provides a shallow-buffered, best-effort servi		p Behavior (NQB PHB). The NQB PHB provides a shallow-buffered, best-effort servi
	ce as a complement to a Default deep-buffered best-effort service for Internet s		ce as a complement to a Default deep-buffered, best-effort service for Internet
	ervices. The purpose of this NQB PHB is to provide a separate queue that enables		services.
	smooth (i.e. non-bursty), low-data-rate, application-limited traffic microflows
	, which would ordinarily share a queue with bursty and capacity-seeking traffic,		<!--[rfced] This sentence is long and employs a lot of hyphenation.
	to avoid the delay, delay variation and loss caused by such traffic. This PHB i		Could we reword as follows to break things up a bit?
	s implemented without prioritization and can be implemented without rate policin
	g, making it suitable for environments where the use of these features is restri		Original:
	cted. The NQB PHB has been developed primarily for use by access network segment		The purpose of this NQB PHB is to provide a separate queue that
	s, where queuing delay and queuing loss caused by Queue-Building protocols are m		enables smooth (i.e. non-bursty), low-data-rate, application-limited
	anifested, but its use is not limited to such segments. In particular, the appli		traffic microflows, which would ordinarily share a queue with bursty
	cation of NQB PHB to cable broadband links, Wi-Fi links, and mobile network radi		and capacity-seeking traffic, to avoid the delay, delay variation and
	o and core segments are discussed. This document recommends a specific Differen		loss caused by such traffic.
	tiated Services Code Point (DSCP) to identify Non-Queue-Building microflows, and
	updates the RFC8325 guidance on mapping differentiated services (Diffserv) to I		Perhaps:
	EEE 802.11 for this codepoint.</t>		The purpose of this NQB PHB is to provide a separate queue
	<t>[NOTE (to be removed by RFC-Editor): This document references an ISE su		enabling smooth (i.e., non-bursty) traffic microflows that have low data
	bmission draft (I-D.briscoe-docsis-q-protection) that is approved for publicatio		rates and limited applications to avoid the delay, delay variation,
	n as an RFC. This draft should be held for publication until the queue protectio		and loss caused by sharing a queue with bursty, capacity-seeking
	n RFC can be referenced.]</t>		traffic (which they ordinarily would have done).
			-->
			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 avo
			id the delay, delay variation and loss caused by such traffic. This PHB is imple
			mented without prioritization and can be implemented without rate policing, maki
			ng it suitable for environments where the use of these features is restricted. T
			he NQB PHB has been developed primarily for use by access network segments, wher
			e queuing delay and queuing loss caused by Queue-Building (QB) protocols are man
			ifested; however, its use is not limited to such segments.
			<!--[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?
			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.
			-->
			In particular, the application of NQB PHB to cable broadband links, Wi-Fi
			links, and mobile network radio and core segments are discussed. This document
			recommends a specific Differentiated Services Code Point (DSCP) to identify Non-
			Queue-Building microflows and updates the guidance in RFC 8325 on mapping differ
			entiated services (Diffserv) to IEEE 802.11 for this codepoint.</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section numbered="true">		<section numbered="true">
	<name>Introduction</name>		<name>Introduction</name>
	<t>This document defines a Differentiated Services per-hop behavior (PHB) called the "Non-Queue-Building Per-Hop Behavior" (NQB PHB), which isolates traff ic microflows (application-to-application flows, see <xref target="RFC2475" sect ion="1.2"/>) that are relatively low data rate and that do not themselves materi ally contribute to queuing delay and loss, allowing them to avoid the queuing de lay and losses caused by other traffic. Such Non-Queue-Building microflows (for example: interactive voice, game sync packets, certain machine-to-machine applic ations, DNS lookups, and some real-time IoT analytics data) are low-data-rate ap plication-limited microflows that are distinguished from bursty traffic microflo ws and high-data-rate traffic microflows managed by a classic congestion control algorithm, both of which cause queuing delay and loss. The term "classic conges tion control" is defined in <xref target="RFC9330"/> to mean one that coexists w ith standard Reno congestion control <xref target="RFC5681"/>. In this document we will use the term Queue-Building (QB) to refer to microflows that cause queui ng delay and loss. See <xref target="RFC2475" section="1.2"/> for definitions of other terminology used in this document.</t>
	<t>In accordance with IETF guidance in <xref target="RFC2914"/> and <xref target="RFC8085"/>, most packets carried by access networks are managed by an en d-to-end congestion control algorithm. Many of the commonly-deployed congestion control algorithms, such as <xref target="RFC5681">Reno</xref>, <xref target="RF C9438">Cubic</xref> or <xref target="I-D.ietf-ccwg-bbr">BBR</xref>, are designed to seek the available capacity of the path from sender to receiver (which can f requently be the access network link capacity), and in doing so generally oversh oot the available capacity, causing a queue to build up at the bottleneck link. This queue build-up results in variable delay and packet loss that can affect al l the applications that are sharing the bottleneck link. Moreover, many bottlene ck links implement a relatively deep buffer (100 ms or more) <xref target="Getty s2012"/><xref target="Cardwell2017"/><xref target="WikipediaBufferbloat"/><xref target="I-D.ietf-ccwg-bbr"/> in order to enable these congestion control algorit hms to use the link efficiently, which exacerbates the delay and delay variation experienced.</t>		<!--[rfced] We had a few questions related the following sentence.
	<t>In contrast to applications that frequently cause queuing delay, there are a variety of relatively low data rate applications that do not materially co ntribute to queuing delay and loss but are nonetheless subjected to it by sharin g the same bottleneck link in the access network, in particular. Many of these a pplications can be sensitive to delay or delay variation, as well as packet loss , and thus produce a poor quality of experience in such conditions.</t>		a) This sentence is long. May we break it up as follows?
	<t>Active Queue Management (AQM) mechanisms intended for single queues (su		b) There is an inconsistency in capping for Differentiated Services
	ch as <xref target="RFC8033">PIE</xref>, <xref target="RFC8034">DOCSIS-PIE</xref		with how it was used in the Abstract. We suggest simply using the
	>, <xref target="RFC9332">PI2</xref>, or <xref target="RFC8289">CoDel</xref>) ca		abbreviation (as it already appears in the Abstract).
	n improve the quality of experience for delay sensitive applications, but there
	are practical limits to the amount of improvement that can be achieved without i
	mpacting the throughput of capacity-seeking applications. For example, AQMs gene
	rally allow a significant amount of queue depth variation to accommodate the beh
	aviors of congestion control algorithms such as Reno and Cubic. If the AQM atte
	mpted to control the queue depth much more tightly, applications using those alg
	orithms would not fully utilize the link. Alternatively, flow queuing systems,
	such as <xref target="RFC8290">fq_codel</xref> can be employed to isolate microf
	lows from one another, but they are not appropriate for all bottleneck links due
	to reasons that include complexity. </t>
	<t>The NQB PHB supports differentiating between these two classes of traff		c) We have updated to "have relatively low data rates". Please review
	ic in bottleneck links and queuing them separately so that both classes can deli		that this captures your intended meaning.
	ver satisfactory quality of experience for their applications. In particular, th
	e NQB PHB provides a shallow-buffered, best-effort service as a complement to a
	Default (see <xref target="RFC2474"/>) deep-buffered best-effort service. This P
	HB is designed for broadband access network links, where there is minimal aggreg
	ation of traffic, and especially when buffers are deep (see <xref target="applic
	ability"/>). The applicability of this PHB to lower-speed links is discussed in
	<xref target="low-rate-links"/>. </t>
	<t>To be clear, a network implementing the NQB PHB solely provides isolati		d) We have made a few other punctuation changes. Please review this
	on for traffic classified as behaving in conformance with the behaviors discusse		text carefully.
	d in <xref target="behaviors"/>. A node supporting the NQB PHB makes no guarante
	es on delay or data rate for NQB-marked microflows (beyond the delay bound provi
	ded by the shallow buffer), it is the NQB senders' behavior itself which results
	in low delay and low loss.</t>
	<t><xref target="dscp"/> and <xref target="sdos"/> of this document provid		Original:
	e guidance for network operators regarding appropriate forwarding of traffic mar		This document defines a Differentiated Services per-hop behavior
	ked with the NQB Differentiated Services Code Point (DSCP). The guidance includ		(PHB) called the "Non-Queue-Building Per-Hop Behavior" (NQB PHB),
	es recommendations for the configuration of network nodes that support the NQB P		which isolates traffic microflows (application-to-application flows,
	HB as well as for network nodes that do not support the PHB, to allow NQB traffi		see Section 1.2 of [RFC2475]) that are relatively low data rate and
	c to be forwarded in a way that aligns with the goals for NQB treatment and supp		that do not themselves materially contribute to queuing delay and
	orts the use of this code point by other nodes and other networks.</t>		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.
			-->
			<t>This document defines a Differentiated Services per-hop behavior (PHB)
			called the "Non-Queue-Building Per-Hop Behavior" (or "NQB PHB"), which isolates
			traffic microflows (application-to-application flows, see <xref target="RFC2475"
			section="1.2"/>) that are relatively low data rate and that do not themselves m
			aterially contribute to queuing delay and loss, allowing them to avoid the queui
			ng delay and losses caused by other traffic.
			<!--[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).
			-->
			Non-Queue-Building microflows such as interactive voice, game sync packets
			, certain machine-to-machine applications, DNS lookups, and some real-time Inter
			net of Things (IoT) analytics data are low-data-rate, application-limited microf
			lows. These can be distinguished from bursty traffic microflows and high-data-ra
			te traffic microflows managed by a classic congestion control algorithm (both of
			which cause queuing delay and loss). The term "classic congestion control" is d
			efined in <xref target="RFC9330"/> to mean congestion control that coexists with
			standard Reno congestion control <xref target="RFC5681"/>. In this document, we
			will use "Queue-Building" (or "QB") to refer to microflows that cause queuing d
			elay and loss. See <xref target="RFC2475" section="1.2"/> for definitions of oth
			er terminology used in this document.</t>
			<!--[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...
			-->
			<t>In accordance with IETF guidance in <xref target="RFC2914"/> and <xref
			target="RFC8085"/>, most packets carried by access networks are managed by an en
			d-to-end congestion control algorithm. Many of the commonly deployed congestion
			control algorithms, such as Reno <xref target="RFC5681"></xref>, Cubic <xref tar
			get="RFC9438"></xref>, or BBR <xref target="BBR-CC"></xref>, are designed to see
			k the available capacity of the path from sender to receiver (which can frequent
			ly be the access network link capacity). In doing so, they generally overshoot t
			he available capacity, causing a queue to build up at the bottleneck link. This
			queue buildup results in variable delay and packet loss that can affect all the
			applications that are sharing the bottleneck link. Moreover, many bottleneck lin
			ks implement a relatively deep buffer (100 ms or more) (see <xref target="Gettys
			2012"/>, <xref target="Cardwell2017"/>, <xref target="WikipediaBufferbloat"/>, a
			nd <xref target="BBR-CC"/>) in order to enable these congestion control algorith
			ms to use the link efficiently, which exacerbates the delay and delay variation
			experienced.</t>
			<!--[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.
			-->
			<t>In contrast to applications that frequently cause queuing delay, there
			are a variety of relatively low data rate applications that do not materially co
			ntribute to queuing delay and loss; nonetheless, they are subjected to it by sha
			ring the same bottleneck link in the access network. Many of these applications
			can be sensitive to delay or delay variation, as well as packet loss; thus, they
			produce a poor quality of experience in such conditions.</t>
			<t>Active Queue Management (AQM) mechanisms intended for single queues (su
			ch as Proportional Integral Controller Enhanced (PIE) <xref target="RFC8033"></x
			ref>, DOCSIS-PIE <xref target="RFC8034"></xref>, PI2 <xref target="RFC9332"></xr
			ef>, or CoDel <xref target="RFC8289"></xref>) can improve the quality of experie
			nce for delay-sensitive applications, but there are practical limits to the amou
			nt of improvement that can be achieved without impacting the throughput of capac
			ity-seeking applications. For example, AQMs generally allow a significant amount
			of queue depth variation to accommodate the behaviors of congestion control alg
			orithms such as Reno and Cubic. If the AQM attempted to control the queue depth
			much more tightly, applications using those algorithms would not fully utilize
			the link. Alternatively, flow-queuing systems, such as fq_codel <xref target="R
			FC8290"></xref> can be employed to isolate microflows from one another; however,
			they are not appropriate for all bottleneck links due to reasons that include c
			omplexity. </t>
			<!-- [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.
			-->
			<!--[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)).
			-->
			<t>The NQB PHB supports differentiating between these two classes of traff
			ic in bottleneck links and queuing them separately so that both classes can deli
			ver satisfactory quality of experience for their applications. In particular, th
			e NQB PHB provides a shallow-buffered, best-effort service as a complement to a
			Default (see <xref target="RFC2474"/>) deep-buffered, best-effort service. This
			PHB is designed for broadband access network links, where there is minimal aggre
			gation of traffic, and especially when buffers are deep (see <xref target="appli
			cability"/>). The applicability of this PHB to lower-speed links is discussed in
			<xref target="low-rate-links"/>. </t>
			<t>To be clear, a network implementing the NQB PHB solely provides isolati
			on for traffic classified as behaving in conformance with the behaviors discusse
			d in <xref target="behaviors"/>. A node supporting the NQB PHB makes no guarante
			es on delay or data rate for NQB-marked microflows (beyond the delay bound provi
			ded by the shallow buffer), it is the NQB senders' behavior itself that results
			in low delay and low loss.</t>
			<t>Sections <xref target="dscp" format="counter"/> and <xref target="sdos"
			format="counter"/> of this document provide guidance for network operators rega
			rding appropriate forwarding of traffic marked with the NQB Differentiated Servi
			ces Code Point (DSCP). The guidance includes recommendations for the configurat
			ion of network nodes that support the NQB PHB as well as for network nodes that
			do not support the PHB; this allows NQB traffic to be forwarded in a way that al
			igns with the goals for NQB treatment and supports the use of this code point by
			other nodes and other networks.</t>
	</section>		</section>
	<section numbered="true">		<section numbered="true">
	<name>Requirements Language</name>		<name>Requirements Language</name>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SH		<t>
	OULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	this document are to be interpreted as described in BCP 14 <xref target="RFC2119		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, a		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	s shown here.</t>		RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
			"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
			be interpreted as
			described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
			when, and only when, they appear in all capitals, as shown here.
			</t>
	</section>		</section>
	<section numbered="true">		<section numbered="true">
	<name>Context</name>		<name>Context</name>
	<section numbered="true" anchor="behaviors">		<section numbered="true" anchor="behaviors">
	<name>Non-Queue-Building Behavior</name>		<name>Non-Queue-Building Behavior</name>
	<t>There are applications that send traffic at relatively low data rates and/or in a fairly smooth and consistent manner such that they are unlikely to exceed the available capacity of the network path between sender and receiver ev en at an inter-packet timescale. Some of these applications are transactional in nature, and might only send one packet (or a few packets) per RTT. These appli cations might themselves only cause very small, transient queues to form in netw ork buffers, but nonetheless they can be subjected to delay and delay variation as a result of sharing a network buffer with applications that tend to cause lar ge and/or standing queues to form. These applications typically implement a resp onse to network congestion that consists of discontinuing (or significantly redu cing) transmissions. These applications can be negatively affected by excessive delay and delay variation. Such applications are ideal candidates to be queued separately from the applications that are the cause of queue build-up, delay and loss.</t>		<t>There are applications that send traffic at relatively low data rates and/or in a fairly smooth and consistent manner such that they are unlikely to exceed the available capacity of the network path between sender and receiver, e ven at an inter-packet timescale. Some of these applications are transactional i n nature; they might only send one packet (or a few packets) per RTT. These app lications might themselves only cause very small, transient queues to form in ne twork buffers; nonetheless, they can be subjected to delay and delay variation a s a result of sharing a network buffer with applications that tend to cause larg e and/or standing queues to form. These applications typically implement a respo nse to network congestion that consists of discontinuing (or significantly reduc ing) transmissions. These applications can be negatively affected by excessive delay and delay variation. Such applications are ideal candidates to be queued s eparately from the applications that are the cause of queue buildup, delay, and loss.</t>
	<t>In contrast, Queue-Building (QB) microflows include those that probe for the link capacity and induce delay and loss as a result, for example microfl ows that use Cubic, Reno or other TCP/QUIC congestion control algorithms in a ca pacity-seeking manner. Other types of QB microflows include those that send at a high burst rate even if the long-term average data rate is much lower.</t>		<t>In contrast, Queue-Building (QB) microflows include those that probe for link capacity and induce delay and loss as a result, for example, microflows that use Cubic, Reno, or other TCP/QUIC congestion control algorithms in a capa city-seeking manner. Other types of QB microflows include those that send at a high burst rate even if the long-term average data rate is much lower.</t>
	</section>		</section>
	<section numbered="true">		<section numbered="true">
	<name>Relationship to the Diffserv Architecture</name>		<name>Relationship to the Diffserv Architecture</name>
	<t>The IETF has defined the Differentiated Services architecture <xref t arget="RFC2475"/> with the intention that it allows traffic to be marked in a ma nner that conveys the performance requirements of that traffic either qualitativ ely or in a relative sense (e.g. priority). The architecture defines the use of the Diffserv field <xref target="RFC2474"/> for this purpose, and numerous RFCs have been written that describe recommended interpretations of the values (Diffs erv Code Points <xref target="RFC2474"/>) of the field, and standardized treatme nts (traffic conditioning and per-hop-behaviors <xref target="RFC2475"/>) that c an be implemented to satisfy the performance requirements of traffic so marked.< /t>
	<t>While this architecture is powerful and flexible enough to be configu		<!-- [rfced] We see that [RFC2474] uses "DS" rather than "Diffserv"
	red to meet the performance requirements of a variety of applications and traffi		for "Differentiated Services". It also uses "codepoint" rather
	c categories, or to achieve differentiated service offerings, meeting the perfor		than "code point". Please review and let us know if/how to
	mance requirements of an application across the entire sender-to-receiver path i		update uses in this document.
	nvolves all the networks in the path agreeing on what those requirements are and
	sharing an interest in meeting them. In many cases this is made more difficult
	since the performance "requirements" are not strict ones (e.g., applications wil
	l degrade in some manner as loss, delay and/or delay-variation increase), so the
	importance of meeting them for any particular application in some cases involve
	s a judgment as to the value of avoiding some amount of degradation in quality f
	or that application in exchange for an increase in the degradation of another ap
	plication.</t>
	<t>Further, in many cases the implementation of Diffserv PHBs has histor		Original:
	ically involved prioritization of service classes with respect to one another, w		The architecture defines the use of the Diffserv field [RFC2474] for
	hich sets up the zero-sum game alluded to in the previous paragraph, and results		this purpose, and numerous RFCs have been written that describe
	in the need to limit access to higher priority classes via mechanisms such as a		recommended interpretations of the values (Diffserv Code Points
	ccess control, admission control, traffic conditioning and rate policing, and/or		[RFC2474]) of the field, and standardized treatments (traffic
	to meter and bill for carriage of such traffic. These mechanisms can be difficu		conditioning and per-hop-behaviors [RFC2475]) that can be implemented
	lt or impossible to implement in the Internet.</t>		to satisfy the performance requirements of traffic so marked.
			-->
			<t>The IETF has defined the Differentiated Services architecture <xref t
			arget="RFC2475"/> with the intention that it allows traffic to be marked in a ma
			nner that conveys the performance requirements of that traffic either qualitativ
			ely or in a relative sense (e.g., priority). The architecture defines the use of
			the Diffserv field <xref target="RFC2474"/> for this purpose, and numerous RFCs
			have been written that describe recommended interpretations of the values (Diff
			serv Code Points <xref target="RFC2474"/>) of the field, and standardized treatm
			ents (traffic conditioning and per-hop-behaviors <xref target="RFC2475"/>) that
			can be implemented to satisfy the performance requirements of traffic so marked.
			</t>
	<t>In contrast, the NQB PHB has been designed with the goal that it avoi ds many of these issues, and thus could conceivably be deployed across the Inter net. The intent of the NQB DSCP is that it signals verifiable behavior that perm its the sender to request differentiated treatment. Also, the NQB traffic is to be given a separate queue with forwarding preference equal to Default traffic an d given no reserved capacity other than any minimum capacity that it shares with Default traffic. As a result, the NQB PHB does not aim to meet specific applic ation performance requirements. Instead, the sole goal of the NQB PHB is to isol ate NQB traffic from other traffic that causes an increase in loss, delay, and/o r delay-variation, given that the NQB traffic is itself only an insignificant co ntributor to those degradations. The PHB is also designed to reduce the incentiv es for a sender to mismark its traffic, since neither higher capacity nor reserv ed capacity are being offered. These attributes eliminate many of the trade-offs that underlie the handling of differentiated service classes in the Diffserv ar chitecture as it has traditionally been defined. These attributes also significa ntly simplify access control and admission control functions, reducing them to s imple verification of behavior. This aspect is discussed further in <xref target ="sender"/> and <xref target="traffic_protection"/>.</t>		<t>While this architecture is powerful and flexible enough to be configu red to meet the performance requirements of a variety of applications and traffi c categories, or to achieve differentiated service offerings, meeting the perfor mance requirements of an application across the entire sender-to-receiver path i nvolves all the networks in the path agreeing on what those requirements are and sharing an interest in meeting them. In many cases, this is made more difficult since the performance "requirements" are not strict ones (e.g., applications wi ll degrade in some manner as loss, delay, and/or delay-variation increase), so t he importance of meeting them for any particular application in some cases invol ves a judgment as to the value of avoiding some amount of degradation in quality for that application in exchange for an increase in the degradation of another application.</t>
	<t>The NQB PHB is therefore intended for the situation where the perform ance requirements of applications cannot be assured across the whole sender-to-r eceiver path, and as a result, applications cannot feasibly place requirements o n the network. Instead, many applications have evolved to make the best out of t he network environment that they find themselves in. In this context, the NQB PH B is intended to provide a better network environment for applications that send data at relatively low and non-bursty data rates.</t>		<t>Further, in many cases, the implementation of Diffserv PHBs has histo rically involved prioritization of service classes with respect to one another, which sets up the zero-sum game alluded to in the previous paragraph and which r esults in the need to limit access to higher priority classes via mechanisms suc h as access control, admission control, traffic conditioning and rate policing, and/or to meter and bill for carriage of such traffic. These mechanisms can be d ifficult or impossible to implement in the Internet.</t>
	<t>In regards to comparison between the NQB PHB and other standardized P HBs in the Diffserv series, the closest similarity is to the Expedited Forwardin g (EF) PHB <xref target="RFC3246"/>, which also intends to enable low loss, low delay, and low delay variation services. Unlike EF, NQB has no requirement for a guaranteed minimum rate, nor to police incoming traffic to such a rate, and NQB is expected to be given the same forwarding preference as Default traffic. See <xref target="EF"/> for a more detailed comparison of the NQB and EF PHBs.</t>		<t>In contrast, the NQB PHB has been designed with the goal that it avoi ds many of these issues; thus, it could conceivably be deployed across the Inter net. The intent of the NQB DSCP is that it signals verifiable behavior that perm its the sender to request differentiated treatment. Also, the NQB traffic is to be given a separate queue with forwarding preference equal to Default traffic an d given no reserved capacity other than any minimum capacity that it shares with Default traffic. As a result, the NQB PHB does not aim to meet specific applic ation performance requirements. Instead, the sole goal of the NQB PHB is to isol ate NQB traffic from other traffic that causes an increase in loss, delay, and/o r delay-variation, given that the NQB traffic is, itself, only an insignificant contributor to those degradations. The PHB is also designed to reduce the incent ives for a sender to mis-mark its traffic since neither higher capacity nor rese rved capacity are being offered. These attributes eliminate many of the trade-of fs that underlie the handling of differentiated service classes in the Diffserv architecture as it has traditionally been defined. These attributes also signifi cantly simplify access control and admission control functions, reducing them to simple verification of behavior. This aspect is discussed further in Sections < xref target="sender" format="counter"/> and <xref target="traffic_protection" fo rmat="counter"/>.</t>
	<t>In nodes that support multiple DiffServ Service Classes, NQB traffic		<t>Therefore, the NQB PHB is intended for the situation where the perfor
	is intended to be treated as a part of the Default treatment. Traffic assigned t		mance requirements of applications cannot be assured across the whole sender-to-
	o this class does not receive better forwarding treatment (e.g., prioritization)		receiver path; as a result, applications cannot feasibly place requirements on t
	with respect to other classes, AFxx, EF, etc. Of course, traffic marked as NQB		he network. Instead, many applications have evolved to make the best out of the
	could (like other Default traffic) could receive better forwarding treatment wit		network environment that they find themselves in. In this context, the NQB PHB i
	h respect to Lower-Effort (LE) <xref target="RFC8622"/> (e.g. the NQB queue coul		s intended to provide a better network environment for applications that send da
	d be emptied in a priority sequence before the LE queue).</t>		ta at relatively low and non-bursty data rates.</t>
			<t>In regard to a comparison between the NQB PHB and other standardized
			PHBs in the Diffserv series, the closest similarity is to the Expedited Forwardi
			ng (EF) PHB <xref target="RFC3246"/>, which also intends to enable services that
			provide low loss, low delay, and low delay variation. Unlike EF, NQB has no req
			uirement for a guaranteed minimum rate, nor does have a requirement to police in
			coming traffic to such a rate: NQB is expected to be given the same forwarding p
			reference as Default traffic. See <xref target="EF"/> for a more detailed compar
			ison of the NQB and EF PHBs.</t>
			<!--[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.
			-->
			<t>In nodes that support multiple DiffServ Service Classes, NQB traffic
			is intended to be treated as a part of the Default treatment. Traffic assigned t
			o this class does not receive better forwarding treatment (e.g., prioritization)
			with respect to other classes, AFxx, EF, etc. Of course, traffic marked as NQB
			could (like other Default traffic) receive better forwarding treatment with resp
			ect to Lower-Effort (LE) <xref target="RFC8622"/> (e.g., the NQB queue could be
			emptied in a priority sequence before the LE queue).</t>
	</section>		</section>
	<section numbered="true">		<section numbered="true">
	<name>Relationship to L4S</name>		<name>Relationship to L4S</name>
	<t>The NQB DSCP and PHB described in this document have been defined to operate independently of the L4S Architecture <xref target="RFC9330"/>. Nonethe less, traffic marked with the NQB DSCP is intended to be compatible with L4S <xr ef target="RFC9330"/>, with the result being that NQB traffic and L4S traffic ca n share the low-latency queue in an L4S DualQ node <xref target="RFC9332"/>. Com pliance, by a network node, with the DualQ Coupled AQM requirements (<xref targe t="RFC9332" section="2.5"/>) is considered sufficient to support the NQB PHB req uirement of fair allocation of capacity between the QB and NQB queues (<xref tar get="phb_requirements"/>). Note that these requirements in turn require complian ce with all the requirements in <xref target="RFC9331" section="5"/>.</t>
			<!--[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].
			-->
			<t>In this document, the NQB DSCP and PHB have been defined to operate i
			ndependently of the Low Latency, Low Loss, and Scalable throughput (L4S) archite
			cture <xref target="RFC9330"/>. Nonetheless, traffic marked with the NQB DSCP i
			s intended to be compatible with L4S <xref target="RFC9330"/>, with the result b
			eing that NQB traffic and L4S traffic can share the low-latency queue in an L4S
			DualQ node <xref target="RFC9332"/>. A network node's compliance with the DualQ
			Coupled AQM requirements (see <xref target="RFC9332" section="2.5"/>) is conside
			red sufficient to support the NQB PHB requirement of fair allocation of capacity
			between the QB and NQB queues (<xref target="phb_requirements"/>). Note that th
			ese requirements, in turn, require compliance with all the requirements in <xref
			target="RFC9331" section="5"/>.</t>
			<!-- [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.
			-->
	<t>Applications that comply with both the NQB sender requirements in <xr ef target="sender"/> and the L4S "Prague" requirements in <xref target="RFC9331" section="4"/> could mark their packets both with the NQB DSCP and with the ECT( 1) value. </t>		<t>Applications that comply with both the NQB sender requirements in <xr ef target="sender"/> and the L4S "Prague" requirements in <xref target="RFC9331" section="4"/> could mark their packets both with the NQB DSCP and with the ECT( 1) value. </t>
	<t>In nodes that support both the NQB PHB and L4S, the L4S network funct ions SHOULD treat packets marked with the NQB DSCP and ECT(1) or CE the same as packets marked with the Default DSCP and the same ECN value. Here, L4S network f unctions refers to the L4S Network Node functions (<xref target="RFC9331" sectio n="5"/>), and any mechanisms designed to protect the L4S queue (such as those di scussed in <xref target="RFC9330" section="8.2"/>). The processing by an L4S nod e of an ECT(0) packet that is classified to the L queue (e.g. as a result of bei ng marked with a NQB DSCP) is specified in <xref target="RFC9331" section="5.4.1 .1"/> and <xref target="RFC9332" section="2.5.1.1"/>.</t>		<t>In nodes that support both the NQB PHB and L4S, the L4S network funct ions <bcp14>SHOULD</bcp14> treat packets marked with the NQB DSCP and ECT(1) or CE the same as packets marked with the Default DSCP and the same Explicit Conges tion Notification (ECN) value. Here, "L4S network functions" refers to the L4S N etwork Node functions (see <xref target="RFC9331" section="5"/>), and any mechan isms designed to protect the L4S queue (such as those discussed in <xref target= "RFC9330" section="8.2"/>). The processing by an L4S node of an ECT(0) packet th at is classified to the L queue (e.g., as a result of being marked with a NQB DS CP) is specified in <xref target="RFC9331" section="5.4.1.1"/> and <xref target= "RFC9332" section="2.5.1.1"/>.</t>
	<t>Additionally, <xref target="ecn"/> places requirements on treatment o f ECN-marked packets by a node that support the NQB PHB.</t>		<t>Additionally, <xref target="ecn"/> places requirements on treatment o f ECN-marked packets by a node that supports the NQB PHB.</t>
	</section>		</section>
	<section numbered="true" anchor="applicability">		<section numbered="true" anchor="applicability">
	<name>Applicability</name>		<name>Applicability</name>
	<t>This PHB is primarily applicable for high-speed broadband access netw ork links, where there is minimal aggregation of traffic, and deep buffers are c ommon. </t>		<t>This PHB is primarily applicable for high-speed broadband access netw ork links, where there is minimal aggregation of traffic and deep buffers are co mmon. </t>
	<t>In many other links, forwarding NQB-marked packets using the Default treatment might be sufficient to preserve the loss, delay and delay-variation pe rformance for NQB traffic. This is generally true in links that do not typicall y experience congestion (for example, many backbone and core network links), and in highly aggregated links (links designed to carry a large number of simultane ous microflows) where individual microflow burstiness is averaged out and thus i s unlikely to cause much actual delay. <xref target="aggregation"/> provides rec ommendations for configuration of network nodes in such cases.</t>		<t>In many other links, forwarding NQB-marked packets using the Default treatment might be sufficient to preserve the loss, delay, and delay-variation p erformance for NQB traffic. This is generally true in links that do not typical ly experience congestion (for example, many backbone and core network links) and in highly aggregated links (links designed to carry a large number of simultane ous microflows) where individual microflow burstiness is averaged out and, thus, is unlikely to cause much actual delay. <xref target="aggregation"/> provides r ecommendations for configuration of network nodes in such cases.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="sender" numbered="true">		<section anchor="sender" numbered="true">
	<name>Non-Queue-Building Sender Requirements</name>		<name>Non-Queue-Building Sender Requirements</name>
	<t>Microflows that are eligible to be marked with the NQB DSCP are ones		<t>Microflows that are eligible to be marked with the NQB DSCP are ones
	that send non-bursty traffic at a low data rate relative to typical network path		that send non-bursty traffic at a low data rate relative to typical network path
	capacities. Here the data rate is limited by the application itself rather tha		capacities. Here, the data rate is limited by the application itself rather th
	n by network capacity - these microflows send at a data rate of no more than abo		an by network capacity: these microflows send at a data rate of no more than abo
	ut 1 percent of the "typical" network path capacity. In addition, these microfl		ut 1% of the "typical" network path capacity. In addition, these microflows are
	ows are required to be sent in a smooth (i.e. paced) manner, where the number of		required to be sent in a smooth (i.e., paced) manner, where the number of IP by
	IP bytes sent in any time interval "T" is less than or equal to (R * T) + MTU,		tes sent in any time interval "T" is less than or equal to (R * T) + MTU, where
	where "R" is the maximum rate described in the preceding sentence, expressed in		"R" is the maximum rate described in the preceding sentence, expressed in bytes-
	bytes-per-second. For example, in today's Internet, where access network data ra		per-second. For example, at the time of writing, access network data rates are t
	tes are typically on the order of 50 Mbps or more (and see <xref target="low-rat		ypically on the order of 50 Mbps or more in the Internet (see <xref target="low-
	e-links"/> for a discussion of cases where this isn't true), this implies 500 kb		rate-links"/> for a discussion of cases where this isn't true): this implies 500
	ps as an upper limit. Note that microflows are unidirectional while application		kbps as an upper limit. Note that microflows are unidirectional while applicati
	traffic is often bidirectional (i.e., an application instance might consist of o		on traffic is often bidirectional (i.e., an application instance might consist o
	ne or more microflows in each direction). It could be the case for a particular		f one or more microflows in each direction). For a particular application, it co
	application that some of its microflows are eligible to be marked with the NQB D		uld be the case that some of its microflows are eligible to be marked with the N
	SCP while others are not. For example, an interactive video streaming applicatio		QB DSCP while others are not. For example, an interactive video streaming applic
	n might consist of a high-bandwidth video stream (not eligible for NQB marking)		ation might consist of a high-bandwidth video stream (not eligible for NQB marki
	in one direction, and a low-bandwidth control stream (eligible for NQB marking)		ng) in one direction and a low-bandwidth control stream (eligible for NQB markin
	in the other. </t>		g) in the other. </t>
			<!--[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]).
			-->
	<t>Microflows marked with the NQB DSCP are expected to comply with exist ing guidance for safe deployment on the Internet, including the guidance around response to network congestion, for example the requirements in <xref target="RF C8085"/> and <xref target="RFC3551" section="2"/> (also see the circuit breaker limits in <xref target="RFC8083" section="4.3"/> and the description of inelasti c pseudowires in <xref target="RFC7893" section="4"/>). The fact that a microflo w's data rate is low relative to typical network capacities is no guarantee that sufficient capacity exists in any particular network, and it is the responsibil ity of the application to detect and react appropriately if the network capacity is insufficient. To be clear, the description of NQB-marked microflows in this document is not to be interpreted as suggesting that applications generating su ch microflows are in any way exempt from this responsibility. One way that an a pplication marking its traffic as NQB can handle this is to implement a scalable congestion control mechanism as described in <xref target="RFC9331"/>.</t>		<t>Microflows marked with the NQB DSCP are expected to comply with exist ing guidance for safe deployment on the Internet, including the guidance around response to network congestion, for example the requirements in <xref target="RF C8085"/> and <xref target="RFC3551" section="2"/> (also see the circuit breaker limits in <xref target="RFC8083" section="4.3"/> and the description of inelasti c pseudowires in <xref target="RFC7893" section="4"/>). The fact that a microflo w's data rate is low relative to typical network capacities is no guarantee that sufficient capacity exists in any particular network, and it is the responsibil ity of the application to detect and react appropriately if the network capacity is insufficient. To be clear, the description of NQB-marked microflows in this document is not to be interpreted as suggesting that applications generating su ch microflows are in any way exempt from this responsibility. One way that an a pplication marking its traffic as NQB can handle this is to implement a scalable congestion control mechanism as described in <xref target="RFC9331"/>.</t>
	<t>The Diffserv field specification requires the definition of a recomme		<t>The Diffserv field specification requires the definition of a recomme
	nded DSCP to be associated with each standardized PHB (see <xref target="RFC2474		nded DSCP to be associated with each standardized PHB (see <xref target="RFC2474
	" section ="5"/>). In accordance with this, applications are RECOMMENDED to use		" section="5"/>). In accordance with this, applications are <bcp14>RECOMMENDED<
	the Diffserv Code Point (DSCP) 45 (decimal) to mark microflows as NQB.		/bcp14> to use the Diffserv Code Point (DSCP) 45 (decimal) to mark microflows as
	The choice of the DSCP value 45 (decimal) is motivated in part by the de		NQB.
	sire to achieve separate queuing in existing Wi-Fi networks (see <xref target="w		The choice of the DSCP value 45 (decimal) is motivated, in part, by the
	ifi"/>) and by the desire to make implementation of the PHB simpler in network e		desire to achieve separate queuing in existing Wi-Fi networks (see <xref target=
	quipment that has the ability to classify traffic based on ranges of DSCP values		"wifi"/>) and by the desire to make implementation of the PHB simpler in network
	(see <xref target="aggregation2"/> for further discussion). </t>		equipment that has the ability to classify traffic based on ranges of DSCP valu
			es (see <xref target="aggregation2"/> for further discussion). </t>
	<t>The two primary considerations for whether an application chooses to mark its traffic as NQB involve the risks of being subjected to a traffic protec tion algorithm (see <xref target="traffic_protection"/>) and/or to the consequen ces of overrunning the NQB shallow buffer if (in either case) the traffic contri butes to the formation of a queue in a node that supports the PHB. In both cases , the result could be that excess traffic is discarded or queued separately as D efault traffic (and thus potentially delivered out of order). To avoid these ris ks, if a microflow's traffic exceeds the rate equation provided in the first par agraph of this section, the application MUST NOT mark this traffic with the NQB DSCP. In such a case, the application could instead consider using a scalable co ngestion control mechanism as described in <xref target="RFC9331"/>.</t>		<t>The two primary considerations for whether an application chooses to mark its traffic as NQB involve the risks of being subjected to a traffic protec tion algorithm (see <xref target="traffic_protection"/>) and/or to the consequen ces of overrunning the NQB shallow buffer if (in either case) the traffic contri butes to the formation of a queue in a node that supports the PHB. In both cases , the result could be that excess traffic is discarded or queued separately as D efault traffic (and, thus, potentially is delivered out of order). To avoid thes e risks, if a microflow's traffic exceeds the rate equation provided in the firs t paragraph of this section, the application <bcp14>MUST NOT</bcp14> mark this t raffic with the NQB DSCP. In such a case, the application could instead consider using a scalable congestion control mechanism as described in <xref target="RFC 9331"/>.</t>
	<t>The sender requirements outlined in this section are all related to o bservable attributes of the packet stream,		<t>The sender requirements outlined in this section are all related to o bservable attributes of the packet stream,
	which makes it possible for network elements (including nodes implemen ting the PHB) to monitor for inappropriate		which makes it possible for network elements (including nodes implemen ting the PHB) to monitor for inappropriate
	usage of the DSCP, and take action (such as discarding or re-marking)		usage of the DSCP and take action (such as discarding or re-marking) o
	on traffic that does not comply. This functionality, when implemented as part of		n traffic that does not comply. This functionality, when implemented as part of
	the		the
	PHB is described in <xref target="traffic_protection"/>.</t>		PHB, is described in <xref target="traffic_protection"/>.</t>
	</section>		</section>
	<section anchor="phb_requirements" numbered="true">		<section anchor="phb_requirements" numbered="true">
	<name>Non-Queue-Building PHB Requirements</name>		<name>Non-Queue-Building PHB Requirements</name>
	<t>For the NQB PHB to become widely deployed, it is important that incen		<!--[rfced] Might breaking this text into a list be easier for the
	tives are aligned correctly, i.e., that there is a benefit to the application in		reader?
	marking its packets correctly, and a disadvantage (or at least no benefit) to a
	n application in intentionally mismarking its traffic. Thus, a useful property o
	f 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 require
	ments in <xref target="sender"/>, 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. By adhering to thes
	e principles, there is little incentive for senders to mismark their traffic as
	NQB. </t>
	<t>This principle of incentive alignment ensures a system is robust to t		Original:
	he behavior of the large majority of individuals and organizations who can be ex		Thus, a useful property of nodes (i.e. network switches and
	pected to act in their own interests (including application developers and servi		routers) that support separate queues for NQB and QB microflows is
	ce providers who act in the interests of their users). Malicious behavior is not		that for microflows consistent with the NQB sender requirements in
	necessarily based on rational self-interest, so incentive alignment is not a su		Section 4, the NQB queue would likely be a better choice than the QB
	fficient defense, but the large majority of users do not act out of malice. Prot		queue; and for microflows inconsistent with those requirements, the QB
	ection against malicious attacks (and accidents) is addressed in <xref target="t		queue would likely be a better choice than the NQB queue.
	raffic_protection"/> and summarized in <xref target="Security"/>. As mentioned p
	reviously, the NQB designation and marking is intended to convey verifiable traf		Perhaps:
	fic behavior, as opposed to simply a desire for differentiated treatment. As a r		Thus, a useful property for nodes (i.e., network switches and routers)
	esult, any mismarking can be identified by the network.</t>		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.
			-->
			<t>For the NQB PHB to become widely deployed, it is important that incen
			tives are aligned correctly, i.e., that there is a benefit to the application in
			marking its packets correctly and a disadvantage (or at least no benefit) to an
			application in intentionally mis-marking its traffic. Thus, a useful property o
			f nodes (i.e., network switches and routers) that support separate queues for NQ
			B and QB microflows is that for microflows consistent with the NQB sender requir
			ements in <xref target="sender"/>, 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. By adhering to the
			se principles, there is little incentive for senders to mis-mark their traffic a
			s NQB. </t>
			<t>This principle of incentive alignment ensures a system is robust to t
			he behavior of the large majority of individuals and organizations who can be ex
			pected to act in their own interests (including application developers and servi
			ce providers who act in the interests of their users). Malicious behavior is not
			necessarily based on rational self-interest, so incentive alignment is not a su
			fficient defense, but the large majority of users do not act out of malice. Prot
			ection against malicious attacks (and accidents) is addressed in <xref target="t
			raffic_protection"/> and summarized in <xref target="Security"/>. As mentioned p
			reviously, the NQB designation and marking is intended to convey verifiable traf
			fic behavior, as opposed to simply a desire for differentiated treatment. As a r
			esult, any mis-marking can be identified by the network.</t>
	<section numbered="true" anchor="primary">		<section numbered="true" anchor="primary">
	<name>Primary Requirements</name>		<name>Primary Requirements</name>
	<t>A node supporting the NQB PHB MUST provide a queue for Non-Queue-Buil ding traffic separate from the queue used for Default traffic.</t>		<t>A node supporting the NQB PHB <bcp14>MUST</bcp14> provide a queue for Non-Queue-Building traffic separate from the queue used for Default traffic.</t >
	<t>A node supporting the NQB PHB SHOULD NOT rate limit or rate police th e aggregate of NQB traffic separately from Default traffic. An exception to this recommendation for traffic sent towards a non-DS-capable domain is discussed in <xref target="unmanaged"/>. Note also that <xref target="traffic_protection"/> discusses potential uses of per-microflow (rather than aggregate) rate policing. </t>		<t>A node supporting the NQB PHB <bcp14>SHOULD NOT</bcp14> rate limit or rate police the aggregate of NQB traffic separately from Default traffic. An ex ception to this recommendation for traffic sent towards a non-DS-capable domain is discussed in <xref target="unmanaged"/>. Note also that <xref target="traffic _protection"/> discusses potential uses of per-microflow (rather than aggregate) rate policing.</t>
	<t>The NQB queue SHOULD be given equivalent forwarding preference compar ed to Default. The node SHOULD provide a scheduler that allows NQB and Default t raffic to share the link in a manner that treats the two classes equally, e.g., a deficit round-robin (DRR) scheduler with equal weights, or two Wireless Multim edia Access Categories with the same Enhanced Distributed Channel Access (EDCA) parameters. The use of equal weights for DRR is given as a reasonable example, a nd is not intended to preclude other scheduling weights (see below for details). A node that provides rate limits or rate guarantees for Default traffic SHOULD ensure that such limits and/or guarantees are shared with NQB traffic in a manne r that treats the two classes equally. This could be supported using a hierarchi cal scheduler where the rate limits and guarantees are configured on a parent cl ass, and the two queues (Default and NQB) are arranged as the children of the pa rent class and given equal access to the capacity configured for the parent clas s (e.g. with equal DRR scheduling). Compliance with these recommendations reduce s the incentives for QB traffic to be mismarked as NQB, and is most important in nodes that are likely bottlenecks, where deviation from them could result in a discernible benefit for mismarked traffic (to the detriment of other traffic). I n network nodes that are rarely bottlenecks, these recommendations are less crit ical. </t>		<t>The NQB queue <bcp14>SHOULD</bcp14> be given equivalent forwarding pr eference compared to the Default queue. The node <bcp14>SHOULD</bcp14> provide a scheduler that allows NQB and Default traffic to share the link in a manner tha t treats the two classes equally, e.g., a Deficit Round-Robin (DRR) scheduler wi th equal weights or two Wireless Multimedia Access Categories with the same Enha nced Distributed Channel Access (EDCA) parameters. The use of equal weights for DRR is given as a reasonable example and is not intended to preclude other sched uling weights (see below for details). A node that provides rate limits or rate guarantees for Default traffic <bcp14>SHOULD</bcp14> ensure that such limits and /or guarantees are shared with NQB traffic in a manner that treats the two class es equally. This could be supported using a hierarchical scheduler where the rat e limits and guarantees are configured on a parent class, and the two queues (De fault and NQB) are arranged as the children of the parent class and given equal access to the capacity configured for the parent class (e.g., with equal DRR sch eduling). Compliance with these recommendations reduces the incentives for QB tr affic to be mis-marked as NQB and is most important in nodes that are likely bot tlenecks, where deviation from them could result in a discernible benefit for mi s-marked traffic (to the detriment of other traffic). In network nodes that are rarely bottlenecks, these recommendations are less critical. </t>
	<t>In the DRR example above, equal scheduling weights was only an exampl e. Ideally the DRR weight would be chosen to match the highest fraction of capac ity that NQB compliant flows are likely to use on a particular network segment. Given that NQB compliant flows are not capacity-seeking (in contrast to QB flows , which can be), and since DRR allows unused capacity in one class to be used by traffic in the other, providing a higher-than-necessary NQB scheduler weight co uld be considered less problematic than the reverse. That said, providing a hig her-than-needed NQB scheduler weight does increase the likelihood that a non-com pliant microflow mismarked as NQB is able to use more than its fair share of net work capacity. NQB microflows are expected to each consume no more than 1% of t he link capacity, and in low stat-mux environments (such as at the edge of the n etwork) would be unlikely in aggregate to consume 50% of the link capacity. Thus , 50% seems a reasonable upper bound on the weight for the NQB PHB in these envi ronments.</t>		<t>In the DRR example above, equal scheduling weights is only an example . Ideally, the DRR weight would be chosen to match the highest fraction of capac ity that NQB-compliant flows are likely to use on a particular network segment. Given that NQB-compliant flows are not capacity seeking (in contrast to QB flows , which can be), and since DRR allows unused capacity in one class to be used by traffic in the other, providing a higher-than-necessary NQB scheduler weight co uld be considered less problematic than the reverse. That said, providing a hig her-than-needed NQB scheduler weight does increase the likelihood that a non-com pliant microflow mis-marked as NQB is able to use more than its fair share of ne twork capacity. NQB microflows are expected to each consume no more than 1% of the link capacity, and in low stat-mux environments (such as at the edge of the network) would be unlikely in aggregate to consume 50% of the link capacity. Thu s, 50% seems a reasonable upper bound on the weight for the NQB PHB in these env ironments.</t>
	<t>A node supporting the NQB PHB SHOULD by default classify packets mark ed with the NQB DSCP 45 (decimal) into the queue for Non-Queue-Building traffic. In accordance with the requirement in <xref target="RFC2474" section ="3"/>, a node supporting the NQB PHB MUST support the ability to configure the DSCP tha t is used to classify packets into the queue for Non-Queue-Building traffic. A n ode supporting the NQB PHB MAY support the ability to configure multiple DSCPs t hat are used to classify packets into the queue for Non-Queue-Building traffic.< /t>		<t>By default, a node supporting the NQB PHB <bcp14>SHOULD</bcp14> by cl assify packets marked with the NQB DSCP 45 (decimal) into the queue for Non-Queu e-Building traffic. In accordance with the requirement in <xref target="RFC2474 " section="3"/>, a node supporting the NQB PHB <bcp14>MUST</bcp14> support the ability to configure the DSCP that is used to classify packets into the queue fo r Non-Queue-Building traffic. A node supporting the NQB PHB <bcp14>MAY</bcp14> s upport the ability to configure multiple DSCPs that are used to classify packets into the queue for Non-Queue-Building traffic.</t>
	<t>Support for the NQB PHB is advantageous at bottleneck nodes. Many bot tleneck nodes have a relatively deep buffer for Default traffic (e.g., roughly e qual to the base RTT of the expected connections, which could be tens or hundred s of ms). Providing a similarly deep buffer for the NQB queue would be at cross purposes to providing very low queueing delay and would erode the incentives fo r QB traffic to be marked correctly at such a bottleneck node. The NQB queue MU ST 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. </t>		<t>Support for the NQB PHB is advantageous at bottleneck nodes. Many bot tleneck nodes have a relatively deep buffer for Default traffic (e.g., roughly e qual to the base RTT of the expected connections, which could be tens or hundred s of milliseconds). Providing a similarly deep buffer for the NQB queue would b e at cross purposes to providing very low queueing delay and would erode the inc entives for QB traffic to be marked correctly at such a bottleneck node. The NQ B queue <bcp14>MUST</bcp14> have a buffer size that is significantly smaller tha n the buffer provided for Default traffic. It is <bcp14>RECOMMENDED</bcp14> to c onfigure an NQB buffer size less than or equal to 10 ms at the shared NQB/Defaul t egress rate. </t>
	<t>In order to enable network operators to monitor the usage of the NQB PHB, and in particular to monitor for potential mis-marking of QB traffic, a nod e supporting the NQB PHB MUST provide statistics that can be used by the network operator to detect whether abuse is occurring (e.g. packet and drop counters). Support for such counters ensures that operators who configure the NQB PHB have the ability to track the amount of packet drop that is occurring due to traffic overrunning the shallow buffer, and then take action if they believe the PHB is causing more issues than it is solving in their environment. Those actions could include disabling the PHB, identifying and dealing with the sources of maliciou s traffic directly, enabling traffic protection (<xref target="traffic_protectio n"/>) if it is available, or pursuing a feature request with the equipment manuf acturer to add a traffic protection function if it isn't currently available.</t >		<t>In order to enable network operators to monitor the usage of the NQB PHB and, in particular, to monitor for potential mis-marking of QB traffic, a no de supporting the NQB PHB <bcp14>MUST</bcp14> provide statistics that can be use d by the network operator to detect whether abuse is occurring (e.g., packet and drop counters). Support for such counters ensures that operators who configure the NQB PHB have the ability to track the amount of packet drop that is occurrin g due to traffic overrunning the shallow buffer and then take action if they bel ieve the PHB is causing more issues than it is solving in their environment. Tho se actions could include disabling the PHB, identifying and dealing with the sou rces of malicious traffic directly, enabling traffic protection (<xref target="t raffic_protection"/>) if it is available, or pursuing a feature request with the equipment manufacturer to add a traffic protection function if it isn't current ly available.</t>
	<t>To prevent propagation of degradation of service for NQB traffic caus ed by potential mis-marking of QB traffic,		<t>To prevent propagation of degradation of service for NQB traffic caus ed by potential mis-marking of QB traffic,
	network equipment that supports this PHB and handles traffic for		network equipment that supports this PHB and handles traffic for
	multiple users SHOULD support provisioning		multiple users <bcp14>SHOULD</bcp14> support provisioning
	of capacity and related forwarding resources on a per-user		of capacity and related forwarding resources on a per-user
	basis and SHOULD support enforcement of the resulting		basis and <bcp14>SHOULD</bcp14> support enforcement of the resulting
	per-user limits on the aggregate of NQB and QB traffic for each user.		per-user limits on the aggregate of NQB and QB traffic for each user.
	In this context, the term "user" should be read as meaning an entity tha t the equipment is designed to serve more-or-less independently, such as a subsc riber in the case of access network equipment, a STA in the case of a Wi-Fi AP t hat 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.		In this context, the term "user" should be read as meaning an entity tha t the equipment is designed to serve more-or-less independently, such as a subsc riber 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 equipme nt		This functionality is commonly available in the class of network equipme nt
	for which this PHB is primarily applicable (see <xref target="applicabil ity"/>).		for which this PHB is primarily applicable (see <xref target="applicabil ity"/>).
	Provisioning methodology as well as decisions on whether and how to enfo rce the		Provisioning methodology as well as decisions on whether and how to enfo rce the
	resulting limits may vary by network operator. </t>		resulting limits may vary by network operator. </t>
	<t>While not fully described in this document, it may be possible for ne twork equipment to implement a separate QB/NQB pair of queues for additional ser vice classes beyond the Default PHB / NQB PHB pair.</t>		<t>While not fully described in this document, it may be possible for ne twork equipment to implement a separate QB/NQB pair of queues for additional ser vice classes beyond the Default PHB / NQB PHB pair.</t>
	<t>In some cases, existing network equipment has been deployed that cann ot readily be upgraded or configured to support the PHB requirements. This equip ment might however be capable of loosely supporting an NQB service - see <xref t arget="wifi_interop"/> for details and an example where this is particularly imp ortant. A similar approach might prove to be useful in other network environment s.</t>		<t>In some cases, existing network equipment has been deployed that cann ot readily be upgraded or configured to support the PHB requirements. However, t his equipment might be capable of loosely supporting an NQB service; see <xref t arget="wifi_interop"/> for details and an example where this is particularly imp ortant. A similar approach might prove to be useful in other network environment s.</t>
	</section>		</section>
	<section anchor="traffic_protection" numbered="true">		<section anchor="traffic_protection" numbered="true">
	<name>Traffic Protection</name>		<name>Traffic Protection</name>
	<t>It is possible that, due to an implementation error or misconfigurati on, a QB microflow could end up being mismarked as NQB, or vice versa. It is als o possible that a malicious actor could introduce a QB microflow marked as NQB w ith the intention of causing disruptions. In the case of a low data rate microf low that isn't marked as NQB and therefore ends up in the QB queue, it would onl y impact its own quality of service, and so it seems to be of lesser concern. Ho wever, a QB microflow that is mismarked as NQB is able to contribute to NQB queu e formation at a network node which would cause queuing delay and/or loss for al l the other microflows that are sharing the NQB queue.</t>		<t>It is possible that, due to an implementation error or misconfigurati on, a QB microflow could end up being mis-marked as NQB or vice versa. It is als o possible that a malicious actor could introduce a QB microflow marked as NQB w ith the intention of causing disruptions. In the case of a low data rate microf low that isn't marked as NQB and therefore ends up in the QB queue, it would onl y impact its own quality of service (QoS); therefore, it seems to be of lesser c oncern. However, a QB microflow that is mis-marked as NQB is able to contribute to NQB queue formation at a network node that would cause queuing delay and/or l oss for all the other microflows that are sharing the NQB queue.</t>
	<t>To prevent this situation from harming the performance of the microfl ows that comply with the requirements in <xref target="sender"/>, network elemen ts that support the NQB PHB SHOULD support a "traffic protection" function that can identify microflows or packets that are inconsistent with the sender require ments in <xref target="sender"/>, and either reclassify those microflows/packets to the QB queue or discard the offending traffic. In the case of a traffic prot ection algorithm that reclassifies offending traffic, the implementation MAY pro vide an option to additionally re-mark such traffic to Default (or possibly to a nother local use code point) so that the result of the traffic protection decisi on can be used by further hops. This sort of re-marking could provide a limited layer of protection in situations where downstream network nodes support separat e queuing for NQB marked packets but lack support for traffic protection.</t>		<t>To prevent this situation from harming the performance of the microfl ows that comply with the requirements in <xref target="sender"/>, network elemen ts that support the NQB PHB <bcp14>SHOULD</bcp14> support a "traffic protection" function that can identify microflows or packets that are inconsistent with the sender requirements in <xref target="sender"/> and either reclassify those micr oflows/packets to the QB queue or discard the offending traffic. In the case of a traffic protection algorithm that reclassifies offending traffic, the implemen tation <bcp14>MAY</bcp14> provide an option to additionally re-mark such traffic to Default (or possibly to another local use code point) so that the result of the traffic protection decision can be used by further hops. This sort of re-mar king could provide a limited layer of protection in situations where downstream network nodes support separate queuing for NQB-marked packets but lack support f or traffic protection.</t>
	<t>If traffic protection is not supported or is not effective in prevent ing		<t>If traffic protection is not supported or is not effective in prevent ing
	queue formation and growth in the NQB queue, then QB traffic that is		queue formation and growth in the NQB queue, then QB traffic that is
	mismarked as NQB is able to form a queue that overflows the shallow		mis-marked as NQB is able to form a queue that overflows the shallow
	buffer provided for NQB traffic, which is expected to result in		buffer provided for NQB traffic; this is expected to result in
	redirecting the excess packets to the QB queue or discarding them. Both		redirecting the excess packets to the QB queue or discarding them. Both
	actions degrade service for not only the mismarked QB traffic, but also		actions degrade service for not only the mis-marked QB traffic, but also
	for any correctly marked NQB traffic, likely causing a significant		for any correctly marked NQB traffic. This will likely cause a significa
	degradation of service for NQB traffic. Even if mismarked QB traffic		nt
			degradation of service for NQB traffic. Even if mis-marked QB traffic
	does not cause buffer overflow, the queue that forms results in QB		does not cause buffer overflow, the queue that forms results in QB
	traffic obtaining the reduced loss and delay benefits of the NQB service		traffic obtaining the reduced loss and delay benefits of the NQB service
	while causing queuing delay for all the other microflows that are sharin g the queue.		while causing queuing delay for all the other microflows that are sharin g the queue.
	These increased abilities of QB traffic to damage the NQB service in the absence		These increased abilities of QB traffic to damage the NQB service in the absence
	of a traffic protection function needs to be considered. This is the mot ivation for the "SHOULD" requirement		of a traffic protection function needs to be considered. This is the mot ivation for the "<bcp14>SHOULD</bcp14>" requirement
	to support traffic protection (in the previous paragraph).		to support traffic protection (in the previous paragraph).
	An NQB PHB implementation that does not support traffic protection risks being limited to deployment situations where traffic protection is potentially not necessary. One example of such a situation could be a controlled environment (e.g., enterprise LAN) where a network administrator is expected to manage the usage of DSCPs. </t>		An NQB PHB implementation that does not support traffic protection risks being limited to deployment situations where traffic protection is potentially not necessary. One example of such a situation could be a controlled environment (e.g., enterprise LAN) where a network administrator is expected to manage the usage of DSCPs. </t>
	<t>Traffic protection as it is defined here differs from Traffic Conditi oning implemented in other Diffserv contexts. Traffic Conditioning is commonly p erformed at the edge of a Diffserv domain (either ingress or egress, depending o n Traffic Conditioning Agreements in place). In contrast, traffic protection is intended to be implemented in the nodes that implement the PHB. By placing the traffic protection at the PHB node, an implementation can monitor the actual NQB queue and take action only if a queue begins to form. Implementation of traffic protection at PHB nodes that are most likely to be a bottleneck is particularly important because these are the nodes that would be expected to show the most q ueue build-up in the presence of QB traffic mismarked as NQB.</t>		<t>As it is defined here, traffic protection differs from Traffic Condit ioning implemented in other Diffserv contexts. Traffic Conditioning is commonly performed at the edge of a Diffserv domain (either ingress or egress, depending on Traffic Conditioning Agreements (TCAs) in place). In contrast, traffic protec tion is intended to be implemented in the nodes that implement the PHB. By plac ing the traffic protection at the PHB node, an implementation can monitor the ac tual NQB queue and take action only if a queue begins to form. Implementation of traffic protection at PHB nodes that are most likely to be a bottleneck is part icularly important because these are the nodes that would be expected to show th e most queue buildup in the presence of QB traffic mis-marked as NQB.</t>
	<t>This specification does not mandate a particular algorithm for traffi c protection. This is intentional, since this will probably be an area where im plementers innovate, and the specifics of traffic protection could need to be di fferent in different network equipment and in different network contexts. Instea d this specification provides guidelines and some examples of traffic protection algorithms which could be employed. </t>		<t>This specification does not mandate a particular algorithm for traffi c protection. This is intentional since this will probably be an area where imp lementers innovate. The specifics of traffic protection could need to be differ ent in different network equipment and in different network contexts. Instead, t his specification provides guidelines and some examples of traffic protection al gorithms that could be employed. </t>
	<t>The traffic protection function SHOULD NOT base its decisions upon ap plication-layer constructs (such as the port number used by the application or t he source/destination IP address). Instead, it ought to base its decisions on th e actual behavior of each microflow (i.e. the pattern of packet arrivals).</t>		<t>The traffic protection function <bcp14>SHOULD NOT</bcp14> base its de cisions upon application-layer constructs (such as the port number used by the a pplication 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).</t>
	<t>A conventional implementation of such a traffic protection algorithm		<t>A conventional implementation of such a traffic protection algorithm
	is a per-microflow rate policer, designed to identify microflows that exceed the		is a per-microflow rate policer, designed to identify microflows that exceed the
	bound provided in <xref target="sender"/>, where the value R is set to 1 percen		bound provided in <xref target="sender"/>, where the value R is set to 1% of th
	t of the egress link capacity available for NQB traffic. An alternative is to us		e egress link capacity available for NQB traffic. An alternative is to use a tra
	e a traffic protection algorithm that bases its decisions on the detection of ac		ffic protection algorithm that bases its decisions on the detection of actual qu
	tual queuing (i.e. by monitoring the queuing delay experienced by packets in the		euing (i.e., by monitoring the queuing delay experienced by packets in the NQB q
	NQB queue) in correlation with the arrival of packets for each microflow. Whil		ueue) in correlation with the arrival of packets for each microflow. While a pe
	e a per-microflow rate policer is conceptually simpler (and is based directly on		r-microflow rate policer is conceptually simpler (and is based directly on the N
	the NQB sender requirements), it could often end up being more strict than is n		QB sender requirements), it could often end up being more strict than is necessa
	ecessary (for example by policing a flow that exceeds the rate equation even whe		ry (for example, by policing a flow that exceeds the rate equation even when the
	n the link is underutilized).		link is underutilized).
	One example traffic protection algorithm based on the detection of actua		One example traffic protection algorithm based on the detection of actua
	l queuing can be found in <xref target="I-D.briscoe-docsis-q-protection"/>. Thi		l queuing can be found in <xref target="RFC9957"/>. This algorithm maintains pe
	s algorithm maintains per-microflow state for a certain number of simultaneous "		r-microflow state for a certain number of simultaneous "queue-building" microflo
	queue-building" microflows (e.g. 32), and shared state for any additional microf		ws (e.g., 32), and shared state for any additional microflows above that number.
	lows above that number.</t>		</t>
	<t>In the case of a traffic protection algorithm that reclassifies offen ding traffic, different levels of hysteresis could be considered.		<t>In the case of a traffic protection algorithm that reclassifies offen ding traffic, different levels of hysteresis could be considered.
	For example, the reclassify decision could be made on a packet-by-packet basis, which could result in significant out-of-order delivery for offending mi croflows as some portion of the microflow's packets remain in the NQB queue and some are reclassified to the Default queue.		For example, the reclassify decision could be made on a packet-by-packet basis, which could result in significant out-of-order delivery for offending mi croflows as some portion of the microflow's packets remain in the NQB queue and some are reclassified to the Default queue.
	Alternatively, a traffic protection function could employ a certain leve l of hysteresis to prevent borderline microflows from being reclassified caprici ously, thus causing less potential for out-of-order delivery.		Alternatively, a traffic protection function could employ a certain leve l of hysteresis to prevent borderline microflows from being reclassified caprici ously, thus causing less potential for out-of-order delivery.
	As a third option, the decision could be made to take action on all the future packets of the microflow, though sufficient logic would be needed to ensu re that a future microflow (e.g. with the same 5-tuple) isn't misidentified as t he current offending microflow.		As a third option, the decision could be made to take action on all the future packets of the microflow, though sufficient logic would be needed to ensu re that a future microflow (e.g., with the same 5-tuple) isn't misidentified as the current offending microflow.
	</t>		</t>
	<t>In the case of a traffic protection algorithm that discards offending traffic, similar levels of hysteresis could be considered. In this case, it is RECOMMENDED that the decision thresholds be set higher than in the case of desi gns that reclassify, since the degradation of communications caused by packet di scard are likely to be greater than the degradation caused by out-of-order deliv ery.</t>		<t>In the case of a traffic protection algorithm that discards offending traffic, similar levels of hysteresis could be considered. In this case, it is <bcp14>RECOMMENDED</bcp14> that the decision thresholds be set higher than in t he case of designs that reclassify since the degradation of communications cause d by the packet being discarded are likely to be greater than the degradation ca used by out-of-order delivery.</t>
	<t>The traffic protection function described here might require that the network element maintain microflow state. The traffic protection function MUST be designed such that the node implementing the NQB PHB does not fail (e.g. cras h) in the case that the microflow state is exhausted. This might be accomplished simply by controlling/limiting the resources dedicated to tracking misbehaving flows.</t>		<t>The traffic protection function described here might require that the network element maintain microflow state. The traffic protection function <bcp1 4>MUST</bcp14> be designed such that the node implementing the NQB PHB does not fail (e.g., crash) in the case that the microflow state is exhausted. This might be accomplished simply by controlling/limiting the resources dedicated to track ing misbehaving flows.</t>
	<t>Some networks might prefer to implement a more traditional Traffic Co		<t>Some networks might prefer to implement a more traditional Traffic Co
	nditioning approach, and police the application of the NQB DSCP at the ingress e		nditioning approach and police the application of the NQB DSCP at the ingress ed
	dge so that per-hop traffic protection is not needed. This could be accomplished		ge so that per-hop traffic protection is not needed. This could be accomplished
	via the use of a per-microflow rate policer that polices microflows at 1 percen		via the use of a per-microflow rate policer that polices microflows at 1% of the
	t of the minimum link capacity of the network. This approach would generally be		minimum link capacity of the network. This approach would generally be expecte
	expected to be inferior to per-hop traffic protection, because on one hand it w		d to be inferior to per-hop traffic protection because:</t>
	ould be difficult for edge nodes to guarantee that there would never be more tha		<ul>
	n 100 NQB flows that would share a single internal bottleneck, and on the other		<li>on one hand, it would be difficult for edge nodes to guarantee that
	hand there could be internal links that have much greater capacity than the mini		there would never be more than 100 NQB flows that would share a single internal
	mum. So, Traffic Conditioning at the edge could simultaneously be too lenient a		bottleneck, and</li>
	nd too strict.</t>		<li>on the other hand, there could be internal links that have much gre
			ater capacity than the minimum.</li>
			</ul>
			<t>So, Traffic Conditioning at the edge could simultaneously be too lenie
			nt and too strict.</t>
	</section>		</section>
	<section numbered="true">		<section numbered="true">
	<name>Limiting Packet Bursts from Links</name>		<name>Limiting Packet Bursts from Links</name>
	<t>Some link technologies introduce burstiness by briefly storing packet s prior to forwarding them. A common cause of this burstiness is link discontinu ity (i.e. where the link is not continuously available for transmission by the d evice), for example time-division-duplex links or time-division-multiple-access (TDMA) links. Some link technologies that fall into this category are passive op tical networks (PON), Wi-Fi, LTE/5G and DOCSIS. </t>		<t>Some link technologies introduce burstiness by briefly storing packet s prior to forwarding them. A common cause of this burstiness is link discontinu ity (i.e., where the link is not continuously available for transmission by the device), for example, time-division-duplex links or time-division-multiple-acces s (TDMA) links. Some link technologies that fall into this category are Passive Optical Networks (PONs), Wi-Fi, LTE/5G, and Data-Over-Cable Service Interface Sp ecification (DOCSIS). </t>
	<t>As well as NQB senders needing to limit packet bursts (see <xref targ		<t>As well as NQB senders needing to limit packet bursts (see <xref targ
	et="sender"/>), traffic designated for the NQB PHB would benefit from configurin		et="sender"/>), traffic designated for the NQB PHB would benefit from configurin
	g these link technologies to limit the burstiness introduced. This is for three		g these link technologies to limit the burstiness introduced. This is for three
	reasons. The first reason is that burstiness, whether caused by the sender or		reasons:</t>
	by a link on the path, could cause queuing delay at downstream bottlenecks and t		<ol>
	hus degrade Quality of Experience. The second reason is that burstiness in links		<li>Burstiness, whether caused by the sender or by a link on the path,
	typically means that packets have been delayed by a variable amount, i.e. for p		could cause queuing delay at downstream bottlenecks and, thus, degrade Quality o
	ackets that are being aggregated awaiting a transmission opportunity, some packe		f Experience.</li>
	ts would generally have arrived just after the last transmission opportunity, an		<li>Burstiness in links typically means that packets have been delayed
	d thus have to wait the longest, while others would generally arrive just in tim		by a variable amount. That is, for packets that are being aggregated awaiting a
	e for the next transmission opportunity, and thus would wait the least. This ma		transmission opportunity, some packets would generally have arrived just after
	nifests as delay variation which can also degrade Quality of Experience for appl		the last transmission opportunity and would have to wait the longest while other
	ications that desire NQB treatment. The third reason is that a downstream bottle		s would generally arrive just in time for the next transmission opportunity and
	neck that implements the NQB PHB could have implemented a traffic protection mec		would wait the least. This manifests as delay variation that can also degrade Q
	hanism (<xref target="traffic_protection"/>) that responds to queuing delay by r		uality of Experience for applications that desire NQB treatment.</li>
	e-marking/reclassifying/dropping packets, and bursty arrivals caused by an upstr		<li>A downstream bottleneck that implements the NQB PHB could have impl
	eam link could introduce queuing delay in the NQB queue and thus be more likely		emented a traffic protection mechanism (<xref target="traffic_protection"/>) tha
	to be subjected to traffic protection effects.</t>		t responds to queuing delay by re-marking/reclassifying/dropping packets. Burst
			y arrivals caused by an upstream link could introduce queuing delay in the NQB q
			ueue and these would be more likely to be subjected to traffic protection effect
			s.</li></ol>
	<t>This document does not set any quantified requirements for links to l imit bursts, primarily because link technologies are outside the remit of Diffse rv specifications. However, it would not seem necessary to limit bursts lower th an roughly 10% of the minimum base RTT expected in the typical deployment scenar io (e.g., 250 µs burst duration for links within the public Internet). This obse rvation aligns with a similar one in <xref target="RFC9331" section="5.5"/>.</t>		<t>This document does not set any quantified requirements for links to l imit bursts; this is primarily because link technologies are outside the remit o f Diffserv specifications. However, it would not seem necessary to limit bursts lower than roughly 10% of the minimum base RTT expected in the typical deploymen t scenario (e.g., 250 µs burst duration for links within the public Internet). T his observation aligns with a similar one in <xref target="RFC9331" section="5.5 "/>.</t>
	</section>		</section>
	<section numbered="true" anchor="ecn">		<section numbered="true" anchor="ecn">
	<name>Treatment of the Explicit Congestion Notification field</name>		<name>Treatment of the Explicit Congestion Notification Field</name>
	<t>NQB network functions MUST treat packets marked with the NQB DSCP uni		<t>NQB network functions <bcp14>MUST</bcp14> treat packets marked with t
	formly, regardless of the value of the ECN field. Here, NQB network functions re		he NQB DSCP uniformly, regardless of the value of the ECN field. Here, the term
	fers to the traffic protection function (defined in <xref target="traffic_protec		"NQB network functions" refers to the traffic protection function (defined in <x
	tion"/>) and any re-marking/traffic policing function designed to protect unmana		ref target="traffic_protection"/>) and any re-marking/traffic policing function
	ged networks (as described in <xref target="unmanaged"/>).</t>		designed to protect unmanaged networks (as described in <xref target="unmanaged"
			/>).</t>
	</section>		</section>
	</section>		</section>
	<section numbered="true" anchor="dscp">		<section numbered="true" anchor="dscp">
	<name>Operational Considerations</name>		<name>Operational Considerations</name>
	<t>This section describes considerations for network operators regarding t he identification, marking, and handling of NQB traffic. It outlines aggregation behaviors and special considerations in unmanaged and inter-network scenarios. Additionally, <xref target="aggregation"/> contains configuration recommendation s for nodes that do not support the NQB PHB, and <xref target="unmanaged"/> cont ains configuration recommentations for networks that interconnect with non-DS-ca pable domains.</t>		<t>This section describes considerations for network operators regarding t he identification, marking, and handling of NQB traffic. It outlines aggregation behaviors and special considerations in unmanaged and inter-network scenarios. Additionally, <xref target="aggregation"/> contains configuration recommendation s for nodes that do not support the NQB PHB. <xref target="unmanaged"/> contains configuration recommendations for networks that interconnect with non-DS-capabl e domains.</t>
	<section numbered="true">		<section numbered="true">
	<name>NQB Traffic Identification</name>		<name>NQB Traffic Identification</name>
	<t>As required in <xref target="phb_requirements"/>, nodes supporting th e NQB PHB provide for the configuration of classifiers that can be used to diffe rentiate between QB and NQB traffic of equivalent importance. The assigned NQB DSCP (45 decimal) is recommended for use as the default classifier to distinguis h NQB traffic from traffic classified as Default (DSCP 0) (see <xref target="sen der"/> and <xref target="primary"/>).</t>		<t>As required in <xref target="phb_requirements"/>, nodes supporting th e NQB PHB provide for the configuration of classifiers that can be used to diffe rentiate between QB and NQB traffic of equivalent importance. The assigned NQB DSCP (45 decimal) is recommended for use as the default classifier to distinguis h NQB traffic from traffic classified as Default (DSCP 0) (see Sections <xref ta rget="sender" format="counter"/> and <xref target="primary" format="counter"/>). </t>
	</section>		</section>
	<section anchor="aggregation" numbered="true">		<section anchor="aggregation" numbered="true">
	<name>Aggregation of the NQB DSCP into another Diffserv PHB</name>		<name>Aggregation of the NQB DSCP into Another Diffserv PHB</name>
	<t>It is RECOMMENDED that networks and nodes that do not support the NQB		<t>It is <bcp14>RECOMMENDED</bcp14> that networks and nodes that do not
	PHB be configured to treat traffic marked with the NQB DSCP the same as traffic		support the NQB PHB be configured to treat traffic marked with the NQB DSCP the
	with the Default DSCP. This includes networks (such as MPLS) and nodes that ag		same as traffic with the Default DSCP. This includes networks (such as MPLS) an
	gregate service classes as discussed in <xref target="RFC5127"/> and <xref targe		d nodes that aggregate service classes as discussed in <xref target="RFC5127"/>
	t="RFC8100"/>, in which case this recommendation would result in traffic marked		and <xref target="RFC8100"/>; in this case, this recommendation would result in
	with the NQB DSCP being aggregated into the Elastic Treatment Aggregate (for <xr		traffic marked with the NQB DSCP being aggregated into the Elastic Treatment Agg
	ef target="RFC5127"/> networks) or the Default / Elastic Treatment Aggregate (fo		regate (for networks as described in <xref target="RFC5127"/>) or the Default /
	r <xref target="RFC8100"/> networks). </t>		Elastic Treatment Aggregate (for networks as described in <xref target="RFC8100"
			/>). </t>
	<t>Networks and nodes that do not support the NQB PHB ought to only clas sify packets with the NQB DSCP value into the appropriate treatment aggregate, o r encapsulate such packets for purposes of aggregation, and SHOULD NOT re-mark t hem with a different DSCP. This preservation of the NQB DSCP value enables hops further along the path to provide the NQB PHB successfully. This aligns with rec ommendations in <xref target="RFC5127"/>.</t>		<t>Networks and nodes that do not support the NQB PHB ought to only clas sify packets with the NQB DSCP value into the appropriate treatment aggregate, o r encapsulate such packets for purposes of aggregation, and <bcp14>SHOULD NOT</b cp14> re-mark them with a different DSCP. This preservation of the NQB DSCP valu e enables hops further along the path to provide the NQB PHB successfully. This aligns with recommendations in <xref target="RFC5127"/>.</t>
	<t>In nodes that do not typically experience congestion (for example, ma ny backbone and core network switches), forwarding packets with the NQB DSCP usi ng the Default treatment might be sufficient to preserve the loss, delay and del ay-variation performance for NQB traffic. </t>		<t>In nodes that do not typically experience congestion (for example, ma ny backbone and core network switches), forwarding packets with the NQB DSCP usi ng the Default treatment might be sufficient to preserve the loss, delay, and de lay-variation performance for NQB traffic. </t>
	<t>In nodes that do experience congestion, forwarding packets with the N QB DSCP using the Default treatment could result in degradation of the loss, del ay and delay-variation performance but nonetheless preserves the incentives desc ribed in <xref target="phb_requirements"/>. </t>		<t>In nodes that do experience congestion, forwarding packets with the N QB DSCP using the Default treatment could result in degradation of the loss, del ay, and delay-variation performance but nonetheless preserves the incentives des cribed in <xref target="phb_requirements"/>. </t>
	<t>Aggregating traffic marked with the NQB DSCP into a PHB designed for		<t>Aggregating traffic marked with the NQB DSCP into a PHB designed for
	real-time, delay sensitive traffic		real-time, delay-sensitive traffic
	(e.g. the Real-Time Treatment Aggregate <xref target="RFC5127"/> or the		(e.g., the Real-Time Treatment Aggregate <xref target="RFC5127"/> or the
	Bulk Real-Time Treatment Aggregate <xref target="RFC8100"/>), might better prese		Bulk Real-Time Treatment Aggregate <xref target="RFC8100"/>), might better pres
	rve the loss, delay and delay-variation performance in the		erve the loss, delay, and delay-variation performance in the
	presence of congestion, but would need to be done with consideration of		presence of congestion; however, it would need to be done with considera
	the risk of creating		tion of the risk of creating
	an incentive for non-compliant traffic to be mis-marked as NQB.</t>		an incentive for non-compliant traffic to be mis-marked as NQB.</t>
	</section>		</section>
	<section numbered="true" anchor="aggregation2">		<section numbered="true" anchor="aggregation2">
	<name>Aggregation of other DSCPs into the NQB PHB</name>		<name>Aggregation of Other DSCPs into the NQB PHB</name>
	<t>The Differentiated Services model provides flexibility for operators
	to control the way they choose to aggregate traffic marked with a specific DSCP.
	Operators of nodes that support the NQB PHB could choose to aggregate other ser
	vice classes into the NQB queue. This is particularly useful in cases where spec
	ialized PHBs for these other service classes had not been provided at a potentia
	l bottleneck, perhaps because it was too complex to manage traffic contracts and
	conditioning. Candidate service classes for this aggregation would include thos
	e that carry low-data-rate inelastic traffic that has low to very-low tolerance
	for loss, delay and/or delay-variation. Operators would need to use their own ju
	dgment based on the actual traffic characteristics in their networks in deciding
	whether or not to aggregate other service classes / DSCPs with NQB. For network
	s that use the <xref target="RFC4594"/> service class definitions, this could in
	clude Telephony (EF/VA), Signaling (CS5), and possibly Real-Time Interactive (CS
	4) (depending on data rate). In the preceding sentence, "VA" and "CSx" refer to
	Voice-Admit (<xref target="RFC5865"/>) and Class Selector (<xref target="RFC2474
	"/>) respectively. In some networks, equipment limitations may necessitate aggre
	gating a range of DSCPs (e.g. traffic marked with DSCPs 40-47 (decimal), i.e., t
	hose whose three most significant bits are 0b101). As noted in <xref target="sen
	der"/>, the choice of the DSCP value 45 (decimal) is motivated in part by the de
	sire to make this aggregation simpler in network equipment that can classify pac
	kets via comparing the DSCP value to a range of configured values.</t>
	<t>A node providing only a NQB queue and a Default queue may obtain an N		<!-- We note that [RFC5685] uses "VOICE-ADMIT" rather than
	QB performance similar to that of EF, for example as described by <xref target="		"Voice-Admit". Please review and let us know if/how to update.
	RFC2598" section="A.3.1"/>. Some caveats and differences are discussed in <xref
	target="EF"/>.</t>		Original:
	<t>[NOTE: this section references the obsoleted RFC2598 instead of its r		In the preceding sentence, "VA" and "CSx" refer to Voice-Admit
	eplacement RFC3246, because the former contains the description of EF performanc		([RFC5865]) and Class Selector ([RFC2474]) respectively.
	e.]</t>		-->
			<t>The Differentiated Services model provides flexibility for operators
			to control the way they choose to aggregate traffic marked with a specific DSCP.
			Operators of nodes that support the NQB PHB could choose to aggregate other ser
			vice classes into the NQB queue. This is particularly useful in cases where spec
			ialized PHBs for these other service classes had not been provided at a potentia
			l bottleneck, perhaps because it was too complex to manage traffic contracts and
			conditioning. Candidate service classes for this aggregation would include thos
			e that carry low-data-rate inelastic traffic that has low to very-low tolerance
			for loss, delay, and/or delay variation. Operators would need to use their own j
			udgment based on the actual traffic characteristics in their networks in decidin
			g whether or not to aggregate other service classes / DSCPs with NQB. For networ
			ks that use the service class definitions from <xref target="RFC4594"/>, this co
			uld include Telephony (EF/VA), Signaling (CS5), and possibly Real-Time Interacti
			ve (CS4) (depending on data rate). In the preceding sentence, "VA" and "CSx" ref
			er to Voice-Admit (<xref target="RFC5865"/>) and Class Selector (<xref target="R
			FC2474"/>), respectively. In some networks, equipment limitations may necessitat
			e aggregating a 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 <xref tar
			get="sender"/>, the choice of the DSCP value 45 (decimal) is motivated in part b
			y the desire to make this aggregation simpler in network equipment that can clas
			sify packets via comparing the DSCP value to a range of configured values.</t>
			<t>A node providing only a NQB queue and a Default queue may obtain an N
			QB performance similar to that of EF, for example, as described by <xref target=
			"RFC2598" section="A.3.1"/>. Some caveats and differences are discussed in <xref
			target="EF"/>.</t>
			<t>[NOTE: this section references the obsoleted RFC 2598 instead of its
			replacement (RFC 3246) because the former contains the description of EF perform
			ance.]</t>
			<!--[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.]
			-->
	</section>		</section>
	<section anchor="re-marking" numbered="true">		<section anchor="re-marking" numbered="true">
	<name>Cross-domain usage and DSCP Re-marking</name>		<name>Cross-Domain Usage and DSCP Re-marking</name>
	<t>In contrast to some existing standard PHBs, which are typically only		<t>In contrast to some existing standard PHBs, which are typically only
	used within a Diffserv Domain (e.g., an AS or an enterprise network), this PHB i		used within a Diffserv Domain (e.g., an AS or an enterprise network), this PHB i
	s expected to be used across the Internet, wherever suitable operator agreements		s expected to be used across the Internet, wherever suitable operator agreements
	apply. Under the <xref target="RFC2474"/> model, this requires that the corres		apply. Under the model described in <xref target="RFC2474"/>, this requires th
	ponding DSCP is recognized and mapped across network boundaries accordingly.</t>		at the corresponding DSCP is recognized and mapped across network boundaries acc
			ordingly.</t>
	<t>If NQB support is extended across a DiffServ domain boundary, the int		<!--[rfced] Perhaps it would be helpful to the reader to describe
	erconnected networks agreeing to support NQB SHOULD use the DSCP value 45 (decim		what part of RFC 8100 is being used here?
	al) for NQB at network interconnection, unless a different DSCP is explicitly do
	cumented in the TCA (Traffic Conditioning Agreement, see <xref target="RFC2475"/		Original:
	>) for that interconnection. If <xref target="RFC8100"/> is operational between		If [RFC8100] is operational between interconnected domains, the
	interconnected domains, the receiving domain may prefer a different DSCP for NQB		receiving domain may prefer a different DSCP for NQB traffic that
	traffic that allows for a DSCP range-based classification for the Default / Ela		allows for a DSCP range-based classification for the Default / Elastic
	stic Treatment Aggregate. Similar to the handling of DSCPs for other PHBs (and a		Treatment Aggregate.
	s discussed in <xref target="RFC2475"/>), networks can re-mark NQB traffic to a		-->
	DSCP other than 45 (decimal) for internal usage. To ensure reliable NQB PHB trea
	tment on the entire path, the appropriate NQB DSCP would need to be restored whe		<t>If NQB support is extended across a DiffServ domain boundary, the int
	n forwarding to another network.</t>		erconnected networks agreeing to support NQB <bcp14>SHOULD</bcp14> use the DSCP
			value 45 (decimal) for NQB at network interconnection, unless a different DSCP i
			s explicitly documented in the TCA (Traffic Conditioning Agreement, see <xref ta
			rget="RFC2475"/>) for that interconnection. If <xref target="RFC8100"/> is opera
			tional between interconnected domains, the receiving domain may prefer a differe
			nt DSCP for NQB traffic that allows for a DSCP range-based classification for th
			e Default / Elastic Treatment Aggregate. Similar to the handling of DSCPs for ot
			her PHBs (and as discussed in <xref target="RFC2475"/>), networks can re-mark NQ
			B traffic to a DSCP value other than 45 (decimal) for internal usage. To ensure
			reliable NQB PHB treatment on the entire path, the appropriate NQB DSCP would ne
			ed to be restored when forwarding to another network.</t>
	<section anchor="unmanaged" numbered="true">		<section anchor="unmanaged" numbered="true">
	<name>Interoperability with Non-DS-Capable Domains </name>		<name>Interoperability with Non-DS-Capable Domains </name>
	<t>As discussed in <xref target="RFC2475" section="4"/>, there may be cases where a network operator that supports Diffserv is delivering traffic to a nother network domain (e.g. a network outside of their administrative control), where there is an understanding that the downstream domain does not support Diff serv or there is no knowledge of the traffic management capabilities of the down stream domain, and no agreement in place. In such cases, <xref target="RFC2475" section="4"/> suggests that the upstream domain opportunistically re-mark traff ic 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 domai n.</t>
	<t>In the case of a network that supports the NQB PHB (and carries tra		<!-- [rfced] We note that Section 4 of [RFC2475] uses "Class Selector
	ffic marked with the recommended NQB DSCP value) the same concerns apply. In par		codepoint" rather than "Class Selector Codepoint". Please review
	ticular, since the recommended NQB DSCP value could be given high priority in so		and let us know if/how to update.
	me non-DS-compliant network equipment (e.g., legacy Wi-Fi APs as described in <x
	ref target="wifi_interop"/>), it is RECOMMENDED that the operator of the upstrea		Original:
	m domain implement one of the following safeguards before delivering traffic int		In such cases, Section 4 of [RFC2475] suggests that the upstream
	o a non-DS-capable domain.</t>		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.
			-->
			<t>As discussed in <xref target="RFC2475" section="4"/>, there may be
			cases where a network operator that supports Diffserv is delivering traffic to a
			nother network domain (e.g., a network outside of their administrative control)
			where there is an understanding that the downstream domain does not support Diff
			serv or there is no knowledge of the traffic management capabilities of the down
			stream domain, and no agreement in place. In such cases, <xref target="RFC2475"
			section="4"/> suggests that the upstream domain opportunistically re-mark traff
			ic 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 domai
			n.</t>
			<t>In the case of a network that supports the NQB PHB (and carries tra
			ffic marked with the recommended NQB DSCP value), the same concerns apply. In pa
			rticular, since the recommended NQB DSCP value could be given high priority in s
			ome non-DS-compliant network equipment (e.g., legacy Wi-Fi APs as described in <
			xref target="wifi_interop"/>), it is <bcp14>RECOMMENDED</bcp14> that the operato
			r of the upstream domain implement one of the following safeguards before delive
			ring traffic into a non-DS-capable domain:</t>
	<ol>		<ol>
	<li><t>One option for such a safeguard is to re-mark NQB traffic to DS CP 0 (Default) (or another Class Selector DSCP) before delivering traffic into a non-DS-capable domain, in accordance with the suggestion in <xref target="RFC24 75" section="4"/>.		<li><t>One option for such a safeguard is to re-mark NQB traffic to DS CP 0 (Default) (or another Class Selector DSCP) before delivering traffic into a non-DS-capable domain, in accordance with the suggestion in <xref target="RFC24 75" section="4"/>.
	Network equipment designed for such environments, SHOULD by default re -mark NQB traffic to DSCP 0 (Default), and SHOULD support the ability to change and disable this re-marking.		Network equipment designed for such environments <bcp14>SHOULD</bcp14> , by default, re-mark NQB traffic to DSCP 0 (Default) and <bcp14>SHOULD</bcp14> support the ability to change and disable this re-marking.
	Re-marking NQB traffic to DSCP 0 (Default) could be considered the "sa fest" approach since the upstream domain can thereby ensure that NQB traffic is not given inappropriate treatment in the non-DS-capable domain.		Re-marking NQB traffic to DSCP 0 (Default) could be considered the "sa fest" approach since the upstream domain can thereby ensure that NQB traffic is not given inappropriate treatment in the non-DS-capable domain.
	That said, it comes with the downside that the re-marking ruins any po ssibility of NQB isolation in any further downstream domain (not just the immedi ate neighbor).</t></li>		That said, it comes with the downside that the re-marking ruins any po ssibility of NQB isolation in any further downstream domain (not just the immedi ate neighbor).</t></li>
	<li><t>As an alternative to re-marking all NQB traffic, such an operat or could deploy a traffic protection (see <xref target="traffic_protection"/>) o r a shaping/policing function on traffic marked with the NQB DSCP that minimizes the potential for negative impacts on Default traffic, should the downstream do main treat traffic with the NQB DSCP as high priority.</t>		<li><t>As an alternative to re-marking all NQB traffic, such an operat or could deploy a traffic protection (see <xref target="traffic_protection"/>) o r a shaping/policing function on traffic marked with the NQB DSCP that minimizes the potential for negative impacts on Default traffic, should the downstream do main treat traffic with the NQB DSCP as high priority.</t>
	<t>In the case that a traffic protection function is used, it MUST eit		<t>In the case that a traffic protection function is used, it <bcp14>M
	her re-mark offending traffic to DSCP 0 (or another Class Selector DSCP) or disc		UST</bcp14> either re-mark offending traffic to DSCP 0 (or another Class Selecto
	ard it.		r DSCP) or discard it.
	Note that a traffic protection function as defined in this document mi		Note that a traffic protection function, as defined in this document,
	ght only provide protection from issues occurring in subsequent network hops if		might only provide protection from issues occurring in subsequent network hops i
	the device implementing the traffic protection function is the bottleneck link o		f the device implementing the traffic protection function is the bottleneck link
	n the path, so it might not be a solution for all situations. </t>		on the path, so it might not be a solution for all situations. </t>
	<t>In the case that a traffic policing function or a rate shaping func		<t>In the case that a traffic policing function or a rate shaping func
	tion is applied to the aggregate of NQB traffic destined to such a downstream do		tion is applied to the aggregate of NQB traffic destined to such a downstream do
	main, the policer/shaper rate SHOULD be set to either 5% of the interconnection		main, the policer/shaper rate <bcp14>SHOULD</bcp14> be set to either 5% of the i
	data rate, or 5% of the typical rate for such interconnections, whichever is gre		nterconnection data rate or 5% of the typical rate for such interconnections, wh
	ater, with excess traffic being re-marked and classified for Default forwarding		ichever is greater, with excess traffic being re-marked and classified for Defau
	(or dropped, as a last resort).		lt forwarding (or dropped, as a last resort).
	A traffic policing function SHOULD allow approximately 100 ms of burst		A traffic policing function <bcp14>SHOULD</bcp14> allow approximately
	tolerance (e.g. a token bucket depth equal to 100 ms multiplied by the policer		100 ms of burst tolerance (e.g., a token bucket depth equal to 100 ms multiplied
	rate).		by the policer rate).
	A traffic shaping function SHOULD allow approximately 10 ms of burst t		A traffic shaping function <bcp14>SHOULD</bcp14> allow approximately 1
	olerance, and no more than 50 ms of buffering.		0 ms of burst tolerance and no more than 50 ms of buffering.
	The burst tolerance values recommended here are intended to reduce the		The burst tolerance values recommended here are intended to reduce the
	degradation that could be introduced to delay and loss sensitive traffic marked		degradation that could be introduced to delay- and loss-sensitive traffic marke
	NQB without significantly degrading Default traffic, and could be adjusted base		d NQB without significantly degrading Default traffic and that could be adjusted
	d on local network policy. Increasing the burst tolerance would further reduce t		based on local network policy. Increasing the burst tolerance would further red
	he potential for degradation (increased loss or increased delay) of traffic mark		uce the potential for degradation (increased loss or increased delay) of traffic
	ed NQB, but would come at the cost of an increased risk of degradation (increase		marked NQB but would come at the cost of an increased risk of degradation (incr
	d loss or increased delay) of Default traffic. </t>		eased loss or increased delay) of Default traffic. </t>
	<t>The recommendation to limit NQB traffic to 5% is based on an assump tion that internal links in the downstream domain could have data rates as low a s one tenth of the interconnect rate, in which case if the entire aggregate of N QB traffic traversed a single instance of such a link, the aggregate would consu me no more than 50% of that link's capacity. The limit for NQB traffic SHOULD b e adjusted based on any knowledge of the local network environment that is avail able.</t> </li>		<t>The recommendation to limit NQB traffic to 5% is based on an assump tion that internal links in the downstream domain could have data rates as low a s one tenth of the interconnect rate; in which case, if the entire aggregate of NQB traffic traversed a single instance of such a link, the aggregate would cons ume no more than 50% of that link's capacity. The limit for NQB traffic <bcp14> SHOULD</bcp14> be adjusted based on any knowledge of the local network environme nt that is available.</t> </li>
	</ol>		</ol>
	</section>		</section>
	</section>		</section>
	<section numbered="true">		<section numbered="true">
	<name>The NQB DSCP and Tunnels</name>		<name>The NQB DSCP and Tunnels</name>
	<t><xref target="RFC2983"/> discusses tunnel models that support Diffser v. It describes a "uniform model" in which the inner DSCP is copied to the outer header at encapsulation, and the outer DSCP is copied to the inner header at de capsulation. It also describes a "pipe model" in which the outer DSCP is not cop ied to the inner header at decapsulation. Both models can be used in conjunctio n with the NQB PHB. In the case of the pipe model, any DSCP manipulation (re-mar king) of the outer header by intermediate nodes would be discarded at tunnel egr ess. In some cases, this could improve the possibility of achieving NQB treatmen t in subsequent nodes, but in other cases it could degrade that possibility (e.g . if the re-marking was designed specifically to preserve NQB treatment in downs tream domains).</t>		<t><xref target="RFC2983"/> discusses tunnel models that support Diffser v. It describes a "uniform model" in which the inner DSCP is copied to the outer header at encapsulation and the outer DSCP is copied to the inner header at dec apsulation. It also describes a "pipe model" in which the outer DSCP is not copi ed to the inner header at decapsulation. Both models can be used in conjunction with the NQB PHB. In the case of the pipe model, any DSCP manipulation (re-mark ing) of the outer header by intermediate nodes would be discarded at tunnel egre ss. In some cases, this could improve the possibility of achieving NQB treatment in subsequent nodes; in other cases, it could degrade that possibility (e.g., i f the re-marking was designed specifically to preserve NQB treatment in downstre am domains).</t>
	<t>As is discussed in <xref target="RFC2983"/>, tunnel protocols that ar		<!--[rfced] Note that we have changed IPSec to IPsec to match the
	e sensitive to reordering (such as IPSec <xref target="RFC4301"/> or L2TP <xref		following from RFC 4301:
	target="RFC2661"/>) can result in undesirable interactions if multiple DSCP PHBs
	are signaled for traffic within a tunnel instance. This is true for tunnels con		The spelling "IPsec" is preferred and used throughout this and all
	taining a mix of QB and NQB traffic as well. Additionally, since networks suppor		related IPsec standards. All other capitalizations of IPsec (e.g.,
	ting the NQB PHB could implement a traffic protection mechanism (see <xref targe		IPSEC, IPSec, ipsec) are deprecated.
	t="traffic_protection"/>) and/or responses to NQB buffer overrun that result in		-->
	out-of-order delivery for traffic marked with the NQB DSCP, even tunnels solely
	containing NQB traffic could have issues if they are sensitive to reordering and		<t>As is discussed in <xref target="RFC2983"/>, tunnel protocols that ar
	the outer header retains the NQB DSCP. As a result, the use of a reordering-sen		e sensitive to reordering (such as IPsec <xref target="RFC4301"/> or Layer 2 Tun
	sitive tunnel protocol to carry NQB traffic, or a mix of QB and NQB traffic, nec		neling Protocol (L2TP) <xref target="RFC2661"/>) can result in undesirable inter
	essitates that the outer tunnel header be re-marked with a non-NQB DSCP (e.g. De		actions if multiple DSCP PHBs are signaled for traffic within a tunnel instance.
	fault), in which case the "pipe" model is preferable because it preserves the ma		This is true for tunnels containing a mix of QB and NQB traffic. Additionally,
	rking differentiation at tunnel decapsulation.</t>		since networks supporting the NQB PHB could implement a traffic protection mecha
			nism (see <xref target="traffic_protection"/>) and/or responses to NQB buffer ov
			errun that result in out-of-order delivery for traffic marked with the NQB DSCP,
			even tunnels solely containing NQB traffic could have issues if they are sensit
			ive to reordering and the outer header retains the NQB DSCP. As a result, the us
			e of a reordering-sensitive tunnel protocol to carry NQB traffic, or a mix of QB
			and NQB traffic, necessitates that the outer tunnel header be re-marked with a
			non-NQB DSCP (e.g., Default); in this case, the "pipe" model is preferable becau
			se it preserves the marking differentiation at tunnel decapsulation.</t>
	</section>		</section>
	<section numbered="true" anchor="low-rate-links">		<section numbered="true" anchor="low-rate-links">
	<name>Guidance for Lower-Rate Links</name>		<name>Guidance for Lower-Rate Links</name>
	<t>The NQB sender requirements in <xref target="sender"/> place responsi bility in the hands of the application developer to determine the likelihood tha t the application's sending behavior could result in a queue forming along the p ath. These requirements rely on application developers having a reasonable sens e for the network context in which their application is to be deployed. Even so , there will undoubtedly be networks that contain links having a data rate that is below the lower end of what is considered "typical", and some of these links could even be below the instantaneous sending rate of some NQB-marked applicatio ns.</t>		<t>The NQB sender requirements in <xref target="sender"/> place responsi bility in the hands of the application developer to determine the likelihood tha t the application's sending behavior could result in a queue forming along the p ath. These requirements rely on application developers having a reasonable sens e for the network context in which their application is to be deployed. Even so , there will undoubtedly be networks that contain links having a data rate that is below the lower end of what is considered "typical"; some of these links coul d even be below the instantaneous sending rate of some NQB-marked applications.< /t>
	<t>To limit the consequences of this scenario, operators of networks wit		<t>To limit the consequences of this scenario, operators of networks wit
	h lower rate links SHOULD consider utilizing a traffic protection function on th		h lower rate links <bcp14>SHOULD</bcp14> consider utilizing a traffic protection
	ose links that is more tolerant of burstiness (i.e., a temporary queue). This wi		function on those links that is more tolerant of burstiness (i.e., a temporary
	ll have the effect of allowing a larger set of NQB-marked microflows to remain i		queue). This will have the effect of allowing a larger set of NQB-marked microfl
	n the NQB queue, but will come at the expense of a greater potential for delay v		ows to remain in the NQB queue; however, it will come at the expense of a greate
	ariation. In implementations that support <xref target="I-D.briscoe-docsis-q-pr		r potential for delay variation. In implementations that support <xref target="
	otection"/>, the burst tolerance can be configured via the CRITICALqLSCORE_us in		RFC9957"/>, the burst tolerance can be configured via the CRITICALqLSCORE_us inp
	put parameter.</t>		ut parameter.</t>
	<t>Alternatively, operators of networks with lower rate links MAY choose		<t>Alternatively, operators of networks with lower rate links <bcp14>MAY
	to disable NQB support (and thus aggregate traffic marked with the NQB DSCP wit		</bcp14> choose to disable NQB support (and thus aggregate traffic marked with t
	h Default traffic) on these lower rate links. For links that have a data rate t		he NQB DSCP with Default traffic) on these lower rate links. For links that hav
	hat is less than ten percent of "typical" path rates, it is RECOMMENDED that the		e a data rate that is less than 10% of "typical" path rates, it is <bcp14>RECOMM
	NQB PHB be disabled and that traffic marked with the NQB DSCP is therefore carr		ENDED</bcp14> that the NQB PHB be disabled and that traffic marked with the NQB
	ied using the Default PHB (without being re-marked to the Default DSCP (0)).</t>		DSCP is therefore carried using the Default PHB (without being re-marked to the
			Default DSCP (0)).</t>
	</section>		</section>
	</section>		</section>
	<section numbered="true" anchor="sdos">		<section numbered="true" anchor="sdos">
	<name>Mapping NQB to standards of other SDOs</name>		<name>Mapping NQB to Standards of Other SDOs</name>
	<t>This section provide recommendations for the support of the NQB PHB in certain use cases. This section is not exhaustive.</t>		<t>This section provide recommendations for the support of the NQB PHB in certain use cases. This section is not exhaustive.</t>
	<section numbered="true">		<section numbered="true">
	<name>DOCSIS Access Networks</name>		<name>DOCSIS Access Networks</name>
	<t>Residential cable broadband Internet services are commonly configured with a single bottleneck link (the access network link) upon which the service definition is applied. The service definition, typically an upstream/downstream data rate tuple, is implemented as a configured pair of rate shapers that are ap plied to the user's traffic. In such networks, the quality of service that each application receives, and as a result, the quality of experience that it generat es for the user is influenced by the characteristics of the access network link. </t>		<t>Residential cable broadband Internet services are commonly configured with a single bottleneck link (the access network link) upon which the service definition is applied. The service definition, typically an upstream/downstream data rate tuple, is implemented as a configured pair of rate shapers that are ap plied to the user's traffic. In such networks, the quality of service that each application receives, and as a result, the quality of experience that it generat es for the user is influenced by the characteristics of the access network link. </t>
	<t> To support the NQB PHB, cable broadband services would need to be co nfigured to provide a separate queue for traffic marked with the NQB DSCP. The N QB queue would need to be configured to share the service's rate shaped capacity with the queue for QB traffic. Further discussion about support of the NQB PHB in DOCSIS networks can be found in <xref target="LOW_LATENCY_DOCSIS"/>.</t>		<t> To support the NQB PHB, cable broadband services would need to be co nfigured to provide a separate queue for traffic marked with the NQB DSCP. The N QB queue would need to be configured to share the service's rate shaped capacity with the queue for QB traffic. Further discussion about support of the NQB PHB in DOCSIS networks can be found in <xref target="LOW_LATENCY_DOCSIS"/>.</t>
	</section>		</section>
	<section numbered="true">		<section numbered="true">
	<name>Mobile Networks</name>		<name>Mobile Networks</name>
	<t>Historically, 3GPP mobile networks have utilized "bearers" to encapsu late each user's user plane traffic through the radio and core networks. A "dedi cated bearer" can be allocated a Quality of Service (QoS) to apply any prioritis ation to its microflows at queues and radio schedulers. Typically, an LTE operat or provides a dedicated bearer for IMS VoLTE (Voice over LTE) traffic, which is prioritized in order to meet regulatory obligations for call completion rates; a nd a "best effort" default bearer, for Internet traffic. The "best effort" beare r provides no guarantees, and hence its buffering characteristics are not compat ible with low-latency traffic. The 5G radio and core systems offer more flexibil ity over bearer allocation, meaning bearers can be allocated per traffic type ( e.g., loss-tolerant, low-latency etc.) and hence support more suitable treatment of Internet real-time microflows.</t>
	<t>To support the NQB PHB, the mobile network could be configured to giv		<t>Historically, 3GPP mobile networks have utilized "bearers" to encapsu
	e User Equipment (UE, the mobile device used by the subscriber) a dedicated, low		late each user's user plane traffic through the radio and core networks. A "dedi
	-latency, non-GBR (non-Guaranteed Bit Rate), EPS (Evolved Packet System, the cor		cated bearer" can be allocated a Quality of Service (QoS) to apply any prioritiz
	e and access network architecture used in LTE) bearer, e.g., one with QCI 7 (QoS		ation to its microflows at queues and radio schedulers. Typically, an LTE operat
	Class Identifier 7, which is typically used for low-latency, non-GBR services),		or provides a dedicated bearer for IP Multimedia Subsystems (IMS) VoLTE (Voice o
	in addition to the default EPS bearer. Alternatively, in a 5G system, a Data Ra		ver LTE) traffic, which is prioritized in order to meet regulatory obligations f
	dio Bearer with 5QI 7 (5G QoS Identifier 7, similarly used for low-latency traff		or call completion rates, and a "best effort" default bearer for Internet traffi
	ic) could be provisioned (see Table 5.7.4-1: Standardized 5QI to QoS characteris		c. The "best effort" bearer provides no guarantees; hence, its buffering charact
	tics mapping in <xref target="SA-5G"/>).</t>		eristics are not compatible with low-latency traffic. The 5G radio and core syst
			ems offer more flexibility over bearer allocation, meaning bearers can be alloca
			ted per traffic type (e.g., loss-tolerant, low-latency, etc.); hence, they suppo
			rt more suitable treatment of Internet real-time microflows.</t>
			<!--[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.
			-->
			<t>To support the NQB PHB, the mobile network could be configured to giv
			e 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 cor
			e 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. Alternatively, in a 5G system, a Data Ra
			dio Bearer with 5QI 7 (5G QoS Identifier 7), similarly used for low-latency traf
			fic, could be provisioned (see Table 5.7.4-1: Standardized 5QI to QoS characteri
			stics mapping in <xref target="SA-5G"/>).</t>
	<t>A packet carrying the NQB DSCP could then be routed through this dedi cated low-latency EPS bearer, while a packet that has no associated NQB marking would be routed through the default EPS bearer.</t>		<t>A packet carrying the NQB DSCP could then be routed through this dedi cated low-latency EPS bearer, while a packet that has no associated NQB marking would be routed through the default EPS bearer.</t>
	</section>		</section>
	<section anchor="wifi" numbered="true">		<section anchor="wifi" numbered="true">
	<name>Wi-Fi Networks</name>		<name>Wi-Fi Networks</name>
	<t>Wi-Fi networking equipment compliant with 802.11e/n/ac/ax <xref targe t="IEEE802-11"/> generally supports either four or eight transmit queues and fou r sets of associated Enhanced Distributed Channel Access (EDCA) parameters (corr esponding to the four Wi-Fi Multimedia (WMM) Access Categories) that are used to enable differentiated medium access characteristics. The four WMM Access Catego ries, referred to as Voice Access Category (AC_VO), Video Access Category (AC_VI ), Best Effort Access Category (AC_BE), and Background Access Category (AC_BK), provide four levels of prioritized access to the wireless medium. As discussed i n <xref target="RFC8325"/>, it has been a common practice for Wi-Fi implementati ons to use a default DSCP to User Priority (UP) mapping that utilizes the most s ignificant three bits of the Diffserv Field to select "User Priority" which is t hen mapped to the four WMM Access Categories. <xref target="RFC8325"/> also pro vides an alternative mapping that more closely aligns with the DSCP recommendati ons provided by the IETF. In the case of some managed Wi-Fi equipment, this mapp ing can be controlled by the network operator, e.g., via <xref target="TR-369">T R-369</xref>.</t>		<t>Wi-Fi networking equipment compliant with 802.11e/n/ac/ax <xref targe t="IEEE802-11"/> generally supports either four or eight transmit queues and fou r sets of associated Enhanced Distributed Channel Access (EDCA) parameters (corr esponding to the four Wi-Fi Multimedia (WMM) Access Categories) that are used to enable differentiated medium access characteristics. The four WMM Access Catego ries, referred to as Voice Access Category (AC_VO), Video Access Category (AC_VI ), Best Effort Access Category (AC_BE), and Background Access Category (AC_BK), provide four levels of prioritized access to the wireless medium. As discussed i n <xref target="RFC8325"/>, it has been a common practice for Wi-Fi implementati ons to use a default DSCP to User Priority (UP) mapping that utilizes the most s ignificant three bits of the Diffserv Field to select "User Priority", which is then mapped to the four WMM Access Categories. <xref target="RFC8325"/> also pr ovides an alternative mapping that more closely aligns with the DSCP recommendat ions provided by the IETF. In the case of some managed Wi-Fi equipment, this map ping can be controlled by the network operator, e.g., via TR-369 <xref target="T R-369"></xref>.</t>
	<t>In addition to the requirements provided in other sections of this do		<t>In addition to the requirements provided in other sections of this do
	cument, to support the NQB PHB, Wi-Fi equipment (including equipment compliant w		cument, to support the NQB PHB, Wi-Fi equipment (including equipment compliant w
	ith <xref target="RFC8325"/>) SHOULD map the NQB DSCP 45 (decimal) into a separa		ith <xref target="RFC8325"/>) <bcp14>SHOULD</bcp14> map the NQB DSCP 45 (decimal
	te queue in the same Access Category as the queue that carries Default traffic (		) into a separate queue in the same Access Category as the queue that carries De
	i.e. the Best Effort Access Category).		fault traffic (i.e., the Best Effort Access Category).
	It is RECOMMENDED that Wi-Fi equipment provide a separate queue in UP 0,		It is <bcp14>RECOMMENDED</bcp14> that Wi-Fi equipment provide a separate
	and map the NQB DSCP 45 (decimal) to that queue.		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 limitati		If a separate queue in UP 0 cannot be provided (due to hardware limitati
	ons, etc.) a Wi-Fi device MAY map the NQB DSCP 45 (decimal) to UP 3.</t>		ons, etc.), a Wi-Fi device <bcp14>MAY</bcp14> map the NQB DSCP 45 (decimal) to U
			P 3.</t>
	<section anchor="wifi_interop" numbered="true">		<section anchor="wifi_interop" numbered="true">
	<name>Interoperability with Existing Wi-Fi Networks</name>		<name>Interoperability with Existing Wi-Fi Networks</name>
	<t>While some existing Wi-Fi equipment might be capable (in some cases via firmware update) of supporting the NQB PHB requirements, many currently dep loyed devices cannot be configured in this way. As a result, the remainder of th is section discusses interoperability with these existing Wi-Fi networks, as opp osed to PHB compliance.</t>		<t>While some existing Wi-Fi equipment might be capable (in some cases via firmware update) of supporting the NQB PHB requirements, many currently dep loyed devices cannot be configured in this way. As a result, the remainder of th is section discusses interoperability with these existing Wi-Fi networks, as opp osed to PHB compliance.</t>
	<t>Since this equipment is widely deployed, and the Wi-Fi link can bec ome a bottleneck link, the performance of traffic marked with the NQB DSCP acros s such links could have a significant impact on the viability and adoption of th e NQB DSCP and PHB. Depending on the DSCP used to mark NQB traffic, existing Wi- Fi equipment that uses the default mapping of DSCPs to Access Categories (<xref target="RFC8325" section="2.3"/>) and the default EDCA parameters will support e ither (but not both) of the following characteristics:</t>		<t>Since this equipment is widely deployed, and the Wi-Fi link can bec ome a bottleneck link, the performance of traffic marked with the NQB DSCP acros s such links could have a significant impact on the viability and adoption of th e NQB DSCP and PHB. Depending on the DSCP used to mark NQB traffic, existing Wi- Fi equipment that uses the default mapping of DSCPs to Access Categories (see <x ref target="RFC8325" section="2.3"/>) and the default EDCA parameters will suppo rt either (but not both) of the following characteristics:</t>
	<ul><li>the NQB PHB requirement for separate queuing of NQB traffic fr om Default traffic (<xref target="primary"/>) </li>		<ul><li>the NQB PHB requirement for separate queuing of NQB traffic fr om Default traffic (<xref target="primary"/>) </li>
	<li>the recommendation to treat NQB traffic with forwarding preference equal to that used for Default traffic (<xref target="primary"/>)</li></ul>		<li>the recommendation to treat NQB traffic with forwarding preference equal to that used for Default traffic (<xref target="primary"/>)</li></ul>
	<t>The DSCP value 45 (decimal) is recommended for NQB (see <xref targe t="sender"/>). This maps NQB to UP 5 using the default mapping, which is in the "Video" Access Category. While this choice of DSCP enables these Wi-Fi systems t o support the NQB PHB requirement for separate queuing, existing Wi-Fi devices g enerally utilize EDCA parameters that result in statistical prioritization of th e "Video" Access Category above the "Best Effort" Access Category. In addition this equipment does not support the remaining NQB PHB recommendations in <xref t arget="phb_requirements"/>. The rationale for the choice of DSCP 45 (decimal) as well as its ramifications, and remedies for its limitations are discussed furth er below.</t>		<t>The DSCP value 45 (decimal) is recommended for NQB (see <xref targe t="sender"/>). This maps NQB to UP 5 using the default mapping, which is in the "Video" Access Category. While this choice of DSCP enables these Wi-Fi systems t o support the NQB PHB requirement for separate queuing, existing Wi-Fi devices g enerally utilize EDCA parameters that result in statistical prioritization of th e "Video" Access Category above the "Best Effort" Access Category. In addition, this equipment does not support the remaining NQB PHB recommendations in <xref target="phb_requirements"/>. The rationale for the choice of DSCP 45 (decimal) a s well as its ramifications and remedies for its limitations are discussed furth er below.</t>
	<t>The choice of separated queuing rather than equal forwarding prefer ence in existing Wi-Fi networks was motivated by the following:</t>		<t>The choice of separated queuing rather than equal forwarding prefer ence in existing Wi-Fi networks was motivated by the following:</t>
	<ul>		<ul>
	<li>Separate queuing is necessary in order to provide a benefit for traffic marked with the NQB DSCP. </li>		<li>Separate queuing is necessary in order to provide a benefit for traffic marked with the NQB DSCP. </li>
	<li>The arrangement of queues in Wi-Fi equipment is typically fixed,		<li>The arrangement of queues in Wi-Fi equipment is typically fixed,
	whereas the relative priority of the Access Category queues is configurable. Mo		whereas the relative priority of the Access Category queues is configurable. Mo
	st Wi-Fi equipment has hardware support (albeit generally not exposed for user c		st Wi-Fi equipment has hardware support (albeit generally not exposed for user c
	ontrol) which could be used to adjust the EDCA parameters in order to meet the e		ontrol), which could be used to adjust the EDCA parameters in order to meet the
	qual forwarding preference recommendation. This is discussed further below.</li>		equal forwarding preference recommendation. This is discussed further below.</li
	<li>Traffic that is compliant with the NQB sender requirements <xref		>
	target="sender"/> is expected to cause minimal degradation to traffic in lower		<li>Traffic that is compliant with the NQB sender requirements in <x
	priority Access Categories, and in any case would be unlikely to cause more degr		ref target="sender"/> is expected to cause minimal degradation to traffic in low
	adation to lower priority Access Categories than the existing recommended Video		er priority Access Categories. In any case, it would be unlikely to cause more
	Access Category traffic types: Broadcast Video, Multimedia Streaming, Multimedia		degradation to lower priority Access Categories than the existing recommended Vi
	Conferencing from <xref target="RFC8325"/>, and AudioVideo, ExcellentEffort fro		deo Access Category traffic types: Broadcast Video, Multimedia Streaming, Multim
	m <xref target="QOS_TRAFFIC_TYPE"/>.</li>		edia Conferencing from <xref target="RFC8325"/>, and AudioVideo, ExcellentEffort
	<li>Several existing client applications that are compatible with th		from <xref target="QOS_TRAFFIC_TYPE"/>.</li>
	e NQB sender requirements already select the Video Access Category, and thus wou		<li>Several existing client applications that are compatible with th
	ld not see a degradation in performance by transitioning to the NQB DSCP, regard		e NQB sender requirements already select the Video Access Category; thus, they w
	less of whether the network supported the PHB.</li>		ould not see a degradation in performance by transitioning to the NQB DSCP, rega
			rdless of whether the network supported the PHB.</li>
	<li>Application instances on Wi-Fi client devices are already free t o choose any Access Category that they wish, regardless of their sending behavio r, 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>Application instances on Wi-Fi client devices are already free t o choose any Access Category that they wish, regardless of their sending behavio r, 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 net		<li>For application traffic that originates outside of the Wi-Fi net
	work, and thus is transmitted by the Access Point, the choice of DSCP 45 does cr		work, and, thus, is transmitted by the Access Point, the choice of DSCP 45 does
	eate a potential for abuse by non-compliant applications. But, opportunities ex		create a potential for abuse by non-compliant applications. However, opportunit
	ist in the network components upstream of the Wi-Fi Access Point to police the u		ies exist in the network components upstream of the Wi-Fi Access Point to police
	sage of the NQB DSCP and potentially re-mark traffic that is considered non-comp		the usage of the NQB DSCP and potentially re-mark traffic that is considered no
	liant, as is recommended in <xref target="unmanaged"/>.		n-compliant, as is recommended in <xref target="unmanaged"/>.
	Furthermore, it is reasonable to expect that ISPs currently manage t		Furthermore, it is reasonable to expect that ISPs currently manage t
	he DSCPs on traffic destined to their customers' networks, and will continue to		he DSCPs on traffic destined to their customers' networks and will continue to d
	do so whether they support NQB or not. This includes the practice in residential		o so whether or not they support NQB. This includes the practice in residential
	broadband networks of re-marking the Diffserv field to zero on all traffic. Any		broadband networks of re-marking the Diffserv field to zero on all traffic. Any
	change to these practices done to enable the NQB DSCP to pass through could be		change to these practices done to enable the NQB DSCP to pass through could be d
	done alongside the implementation of the recommendations in <xref target="unmana		one alongside the implementation of the recommendations in <xref target="unmanag
	ged"/>.</li>		ed"/>.</li>
	</ul>		</ul>
	<t>The choice of Video Access Category rather than the Voice Access Ca tegory was motivated by the desire to minimize the potential for degradation of Best Effort Access Category traffic. The choice of Video Access Category rather than the Background Access Category was motivated by the much greater potential of degradation to NQB traffic that would be caused by the vast majority of traf fic in most Wi-Fi networks, which utilizes the Best Effort Access Category.</t>		<t>The choice of Video Access Category rather than the Voice Access Ca tegory was motivated by the desire to minimize the potential for degradation of Best Effort Access Category traffic. The choice of Video Access Category rather than the Background Access Category was motivated by the much greater potential of degradation to NQB traffic that would be caused by the vast majority of traf fic in most Wi-Fi networks, which utilizes the Best Effort Access Category.</t>
	<t>As stated above, the use of DSCP 45 (decimal) for NQB is not expect ed to create incentives for abuse by non-compliant applications in the Wi-Fi upl ink direction.		<t>As stated above, the use of DSCP 45 (decimal) for NQB is not expect ed to create incentives for abuse by non-compliant applications in the Wi-Fi upl ink direction.
	The fact that the NQB DSCP brings with it the potential for degradatio n of non-compliant applications (traffic protection and/or a shallow queue resul ting in reordering and/or packet loss at some hop along the path) plus the exist ence of multiple other DSCP values that don't carry the risk of degradation, and which could be readily used to obtain prioritization (AC_VI or even AC_VO), lea ds to the conclusion that NQB non-compliant applications that are seeking priori tization in the Wi-Fi uplink would be better off selecting one of those other DS CPs. This conclusion is not expected to be disturbed by network support for NQB increasing the likelihood of DSCP 45 traffic traversing network boundaries witho ut change to the DSCP, as that likelihood of increased network boundary traversa l is balanced by a likelihood of NQB traffic encountering the traffic-limiting a spects of NQB support, traffic protection and shallow buffers, which limit the p otential for abuse.</t>		The fact that the NQB DSCP brings with it the potential for degradatio n of non-compliant applications (traffic protection and/or a shallow queue resul ting in reordering and/or packet loss at some hop along the path) plus the exist ence of multiple other DSCP values that don't carry the risk of degradation and that could be readily used to obtain prioritization (AC_VI or even AC_VO) leads to the conclusion that NQB non-compliant applications that are seeking prioritiz ation in the Wi-Fi uplink would be better off selecting one of those other DSCPs . This conclusion is not expected to be disturbed by network support for NQB inc reasing the likelihood of DSCP 45 traffic traversing network boundaries without change to the DSCP, as that likelihood of increased network boundary traversal i s balanced by a likelihood of NQB traffic encountering the traffic-limiting aspe cts of NQB support, traffic protection, and shallow buffers, which limit the pot ential for abuse.</t>
	<t>In the case of traffic originating outside of the Wi-Fi network, th e prioritization of traffic marked with the NQB DSCP via the Video Access Catego ry (if left unchanged) could potentially erode the principle of alignment of inc entives discussed in <xref target="phb_requirements"/>. In order to preserve the incentives principle for NQB, Wi-Fi systems MAY be configured such that the EDC A parameters for the Video Access Category match those of the Best Effort Access Category, which will mean AC_VI is at the same priority level as AC_BE. These c hanges might not be possible on all Access Points, and in any case the requireme nts and recommendations in <xref target="unmanaged"/> would apply in this situat ion.</t>		<t>In the case of traffic originating outside of the Wi-Fi network, th e prioritization of traffic marked with the NQB DSCP via the Video Access Catego ry (if left unchanged) could potentially erode the principle of alignment of inc entives discussed in <xref target="phb_requirements"/>. In order to preserve the incentives principle for NQB, Wi-Fi systems <bcp14>MAY</bcp14> be configured su ch that the EDCA parameters for the Video Access Category match those of the Bes t Effort Access Category, which will mean AC_VI is at the same priority level as AC_BE. These changes might not be possible on all Access Points; in any case, t he requirements and recommendations in <xref target="unmanaged"/> would apply in this situation.</t>
	<t>Systems that utilize <xref target="RFC8325"/> but cannot provide a separate AC_BE queue for NQB traffic, SHOULD map the NQB DSCP 45 (decimal) (or t he locally determined alternative) to UP 5 in the "Video" Access Category as wel l (see <xref target="updates_to_8325"/>).</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 C ategory as well (see <xref target="updates_to_8325"/>).</t>
	</section>		</section>
	<section anchor="updates_to_8325" numbered="true">		<section anchor="updates_to_8325" numbered="true">
	<name>The Updates to RFC 8325</name>		<name>The Updates to RFC 8325</name>
	<t>[XXX RFC Editor please replace RFCXXXX with this RFC number when publ
	ished XXX]</t>
	<t><xref target="RFC8325" section="4.2.9"/> describes the recommendation for the handling of Standard service class traffic that carries the Default DSCP. This update to <xref target="RFC8325"/> changes the title of <xref target="RFC8325" section="4.2.9"/> from "Standard" to "Standard and Non-Queue-Building". This up date additionally adds a paragraph at the end of <xref target="RFC8325" section= "4.2.9"/> as follows:</t>		<t><xref target="RFC8325" section="4.2.9"/> describes the recommendation for the handling of Standard service class traffic that carries the Default DSCP. This update to <xref target="RFC8325"/> changes the title of <xref target="RFC8325" section="4.2.9"/> from "Standard" to "Standard and Non-Queue-Building". This up date additionally adds a paragraph at the end of <xref target="RFC8325" section= "4.2.9"/> as follows:</t>
	<t indent="4" keepWithPrevious="true">RFCXXXX defines a shallow-buffered best-ef		<blockquote>RFC 9956 defines a shallow-buffered, best-effort service for traffic
	fort service for traffic marked with the NQB DSCP (45 decimal) and recommends th		marked with the NQB DSCP 45 (decimal) and recommends the following treatment in
	e following treatment in Wi-Fi equipment.		Wi-Fi equipment.
	It is RECOMMENDED that Wi-Fi equipment map the NQB DSCP 45 (decimal) into a sepa		It is <bcp14>RECOMMENDED</bcp14> that Wi-Fi equipment map the NQB DSCP 45 (decim
	rate queue in the same Access Category as the queue that carries Default traffic		al) into a separate queue in the same Access Category as the queue that carries
	(i.e. the Best Effort Access Category).		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		It is <bcp14>RECOMMENDED</bcp14> that Wi-Fi equipment provide a separate queue i
	the NQB DSCP 45 (decimal) to that queue.		n 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		If a separate queue in UP 0 cannot be provided (due to hardware limitations, etc
	.) a Wi-Fi device MAY map the NQB DSCP 45 (decimal) to UP 3. If neither of these		.), a Wi-Fi device <bcp14>MAY</bcp14> map the NQB DSCP 45 (decimal) to UP 3. If
	options provides a separate queue from Default traffic, it is RECOMMENDED that		neither of these options provides a separate queue from Default traffic, it is <
	Wi-Fi equipment map the NQB DSCP 45 (decimal) to UP 5 (which corresponds to the		bcp14>RECOMMENDED</bcp14> that Wi-Fi equipment map the NQB DSCP 45 (decimal) to
	default mapping described in Section 2.3). RFCXXXX provides additional recommen		UP 5
	dations and requirements for support of the NQB PHB that aren't available in the		(which corresponds to the default mapping described in Section 2.3). RFC 9956 p
	QoS model described in Section 6, but nonetheless could be supported in impleme		rovides additional recommendations and requirements for support of the NQB PHB t
	ntations.</t>		hat aren't available in the QoS model described in Section 6 but nonetheless cou
			ld be supported in implementations.</blockquote>
			<t>In another update to <xref target="RFC8325"/> captured below, a new row for "
			Non-Queue-Building" traffic is inserted between the existing "Low-Latency Data"
			and "OAM" rows in Figure 1 of <xref target="RFC8325"/> as follows:</t>
			<!-- [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 |
			|===============+======+==========+=============+====================|
			-->
	<t>This update to <xref target="RFC8325"/> inserts a new row for "Non-Queue-Buil ding" traffic between the existing "Low-Latency Data" and "OAM" rows in its Figu re 1 as follows:</t>
	<artwork type="ascii-art" name="fig1_update.txt">		<artwork type="ascii-art" name="fig1_update.txt">
	<![CDATA[		<![CDATA[
	+---------------+------+----------+-------------+--------------------+		+---------------+------+----------+-------------+--------------------+
	| Low- | AF21 | | | |		| Low- | AF21 | | | |
	| Latency | AF22 | RFC 2597 | 3 | AC_BE (Best Effort)|		| Latency | AF22 | RFC 2597 | 3 | AC_BE (Best Effort)|
	| Data | AF23 | | | |		| Data | AF23 | | | |
	+---------------+------+----------+-------------+--------------------+		+---------------+------+----------+-------------+--------------------+
	| Non- | | | 0, 3 | AC_BE (Best Effort)|		| Non- | | | 0, 3 | AC_BE (Best Effort)|
	| Queue- | NQB | RFC XXXX | OR |		| Queue- | NQB | RFC 9956 | OR |
	| Building | | | 5 | AC_VI (Video) |		| Building | | | 5 | AC_VI (Video) |
	| | | | See Section 4.2.9 |		| | | | See Section 4.2.9 |
	+---------------+------+----------+-------------+--------------------+		+---------------+------+----------+-------------+--------------------+
	| OAM | CS2 | RFC 2474 | 0 | AC_BE (Best Effort)|		| OAM | CS2 | RFC 2474 | 0 | AC_BE (Best Effort)|
	+---------------+------+----------+-------------+--------------------+		+---------------+------+----------+-------------+--------------------+
	]]>		]]>
			---------------+------+----------+-------------+--------------------+
	</artwork>		</artwork>
	<t>This update adds the following sentence to the end of the first paragraph in		<t>A third update adds the following sentence to the end of the first paragraph
	<xref target="RFC8325" section="5.3"/>: "An exception to this is the NQB DSCP 4		in <xref target="RFC8325" section="5.3"/>:</t>
	5 (decimal) which encodes for best-effort service."</t>
			<blockquote>An exception to this is the NQB DSCP 45 (decimal), which encodes for
			best-effort service.</blockquote>
	</section>		</section>
	</section>		</section>
	</section>		</section>
	<section anchor="IANA" numbered="true">		<section anchor="IANA" numbered="true">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t>This document requests that IANA assign the Differentiated Services Fie		<t>IANA has assigned the Differentiated Services Field Codepoint (DSCP) 45
	ld Codepoint (DSCP) 45 ('0b101101', 0x2D) from the "Differentiated Services Fiel		from the "Differentiated Services Field Codepoints (DSCP)" registry (<eref targ
	d Codepoints (DSCP)" registry (https://www.iana.org/assignments/dscp-registry/)		et="https://www.iana.org/assignments/dscp-registry/"/>) ("DSCP Pool 3 Codepoints
	("DSCP Pool 3 Codepoints", Codepoint Space xxxx01, Standards Action) as the reco		", Codepoint Space xxxx01, Standards Action (<xref target="RFC8126" format="defa
	mmended codepoint for Non-Queue-Building behavior.</t>		ult"/>) for Non-Queue-Building behavior.</t>
	<t>IANA should update this registry as follows:</t>
	<ul>
	<li>Name: NQB</li>
	<li>Value (Binary): 101101</li>
	<li>Value (Decimal): 45</li>
	<li>Reference: this document</li>
	</ul>
	</section>
	<section numbered="true">
	<name>Implementation Status</name>
	<t>Note to RFC Editor: This section should be removed prior to publication </t>		<t>IANA has updated this registry as follows:</t>
	<t>The NQB PHB is implemented in equipment compliant with the current DOCS		<dl spacing="normal">
	IS 3.1		<dt>Name:</dt><dd>NQB</dd>
	specification, published by CableLabs at:		<dt>Value (Binary):</dt><dd>101101</dd>
	<eref target="https://www.cablelabs.com/specifications/search?query=&amp		<dt>Value (Decimal):</dt><dd>45</dd>
	;category=DOCSIS&amp;subcat=DOCSIS%203.1&amp;doctype=Specifications&amp;content=		<dt>Reference:</dt><dd>RFC 9956</dd>
	false&amp;archives=false&amp;currentPage=1">CableLabs Specifications Search</ere		</dl>
	f>.</t>
	<t>CableLabs maintains a list of production cable modem devices that are C
	ertified as being compliant to the DOCSIS Specifications, this list is available
	at <eref target="https://www.cablelabs.com/wp-content/uploads/2013/10/cert_qual
	.xlsx"/>. DOCSIS 3.1 modems certified in CW 134 or greater implement the NQB PHB
	. This includes products from Arcadyan Technology Corporation, Arris, AVM, Castl
	enet, Commscope, Hitron, Motorola, Netgear, Sagemcom and Vantiva.
	There are additional production implementations that have not been Certifi
	ed as compliant to the specification, but which have been tested in non-public I
	nteroperability Events.
	These implementations are all proprietary, not available as open source.</
	t>
	</section>		</section>
	<section anchor="Security" numbered="true">		<section anchor="Security" numbered="true">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>The security considerations for the NQB PHB relate to the potential to impact the capacity available or delay experienced by other flows that share a b ottleneck on the path with traffic that is marked with the recommended NQB DSCP. </t>		<t>The security considerations for the NQB PHB relate to the potential to impact the capacity available or delay experienced by other flows that share a b ottleneck on the path with traffic that is marked with the recommended NQB DSCP. </t>
	<t>Full support for the NQB PHB in bottleneck links limits the		<t>Full support for the NQB PHB in bottleneck links limits the
	incentives for a Queue-Building application to mismark its packets as		incentives for a Queue-Building application to mis-mark its packets as
	NQB, particularly for implementations that support traffic protection.		NQB, particularly for implementations that support traffic protection.
	If a Queue-Building microflow were to mismark		If a Queue-Building microflow were to mis-mark
	its packets as NQB, it would be unlikely to receive a benefit by		its packets as NQB, it would be unlikely to receive a benefit by
	doing so, and it would usually experience a degradation, in contrast		doing so, and it would usually experience a degradation, in contrast
	to mismarking its packets for a higher-priority PHB, e.g., the EF PHB		to mis-marking its packets for a higher-priority PHB, e.g., the EF PHB
	<xref target="RFC3246"/>.		<xref target="RFC3246"/>.
	The nature of the degradation would depend on the specifics of the PHB imp lementation, including response to NQB buffer overflow (and on the presence or a bsence of a traffic protection function), but could include excessive packet los s, excessive delay variation and/or excessive out-of-order delivery. If a Non-Qu eue-Building microflow was to fail to mark its packets as NQB, it could suffer t he delay and loss typical of sharing a queue with capacity seeking traffic.</t>		The nature of the degradation would depend on the specifics of the PHB imp lementation, including response to NQB buffer overflow (and on the presence or a bsence of a traffic protection function) but could include excessive packet loss , excessive delay variation, and/or excessive out-of-order delivery. If a Non-Qu eue-Building microflow were to fail to mark its packets as NQB, it could suffer the delay and loss typical of sharing a queue with capacity-seeking traffic.</t>
	<t>To preserve low delay performance for NQB traffic, networks that suppor t the NQB PHB will need to ensure that mechanisms are in place to prevent malici ous traffic marked with the NQB DSCP from causing excessive queue delay. <xref target="traffic_protection"/> recommends the implementation of a traffic protect ion mechanism to achieve this goal. The recommendations on traffic protection m echanisms in this document presume that some type of "flow" state be maintained in order to differentiate between microflows that are causing queuing delay and those that aren't. Since this flow state is likely finite, this opens up the po ssibility of flow-state exhaustion attacks. While this document requires that t raffic protection mechanisms be designed with this possibility in mind, the outc omes of flow-state exhaustion would depend on the implementation.</t>		<t>To preserve low-delay performance for NQB traffic, networks that suppor t the NQB PHB will need to ensure that mechanisms are in place to prevent malici ous traffic marked with the NQB DSCP from causing excessive queue delay. <xref target="traffic_protection"/> recommends the implementation of a traffic protect ion mechanism to achieve this goal. The recommendations on traffic protection m echanisms in this document presume that some type of "flow" state be maintained in order to differentiate between microflows that are causing queuing delay and those that aren't. Since this flow state is likely finite, this opens up the po ssibility of flow-state exhaustion attacks. While this document requires that t raffic protection mechanisms be designed with this possibility in mind, the outc omes of flow-state exhaustion would depend on the implementation.</t>
	<t>If traffic protection is not implemented or is not able to		<t>If traffic protection is not implemented or is not able to
	prevent queue formation in the NQB shallow buffer, the limited size		prevent queue formation in the NQB shallow buffer, the limited size
	of that buffer will cause a growing queue to overrun that buffer,		of that buffer will cause a growing queue to overrun that buffer,
	resulting in negative effects (e.g., reforwarding as Default, discarding)		resulting in negative effects (e.g., reforwarding as Default, discarding)
	that potentially impact multiple NQB-marked microflows, independent of whe ther each affected		that potentially impact multiple NQB-marked microflows, independent of whe ther each affected
	microflow contributed to queue formation. As discussed elsewhere in		microflow contributed to queue formation. As discussed elsewhere in
	this draft, those negative effects serve to discourage misuse and abuse of		this document, those negative effects serve to discourage misuse and abuse of
	NQB by QB traffic, but the negative side effects on NQB traffic that		NQB by QB traffic, but the negative side effects on NQB traffic that
	is using NQB (and the associated shallow buffer) as intended		is using NQB (and the associated shallow buffer) as intended
	motivates limiting the effects of shallow buffer overrun via per-user prov isioning limits		motivates limiting the effects of shallow buffer overrun via per-user prov isioning limits
	that prevent queue overrun effects from affecting other users (see <xref t arget="primary"/>).</t>		that prevent queue overrun effects from affecting other users (see <xref t arget="primary"/>).</t>
	<t>Notwithstanding the above, the choice of DSCP for NQB does allow existi ng Wi-Fi networks to readily (and by default) support some of the PHB requiremen ts, but without a traffic protection function, and (when left in the default sta te) by giving NQB traffic higher priority than QB traffic. This is not considere d to be a compliant implementation of the PHB. These existing Wi-Fi networks cur rently provide priority to half of the DSCP space, whether or not 45 is assigned to the NQB DSCP. While the NQB DSCP value could also be abused to gain priorit y on such links, the potential presence of traffic protection functions in other hops along the path (which likely act on the NQB DSCP value alone) would make i t less attractive for such abuse than any of the other 31 DSCP values that are g iven priority.</t>		<t>Notwithstanding the above, the choice of DSCP for NQB does allow existi ng Wi-Fi networks to readily (and by default) support some of the PHB requiremen ts, but without a traffic protection function, and (when left in the default sta te) by giving NQB traffic higher priority than QB traffic. This is not considere d to be a compliant implementation of the PHB. These existing Wi-Fi networks cur rently provide priority to half of the DSCP space, whether or not 45 (decimal) i s assigned to the NQB DSCP. While the NQB DSCP value could also be abused to ga in priority on such links, the potential presence of traffic protection function s in other hops along the path (which likely act on the NQB DSCP value alone) wo uld make it less attractive for such abuse than any of the other 31 DSCP values that are given priority.</t>
	<t>This document discusses the potential use of the NQB DSCP and NQB PHB i n network technologies that are standardized in other SDOs. Any security conside rations that relate to deployment and operation of NQB solely in specific networ k technologies are not discussed here.</t>		<t>This document discusses the potential use of the NQB DSCP and NQB PHB i n network technologies that are standardized in other SDOs. Any security conside rations that relate to deployment and operation of NQB solely in specific networ k technologies are not discussed here.</t>
	<t>NQB uses the Diffserv field. The design of Diffserv does not include in tegrity protection for the DSCP, and thus it is possible for the DSCP to be chan ged by an on-path attacker. The NQB PHB and associated DSCP don't change this. W hile re-marking DSCPs is permitted for various reasons (some are discussed in th is document, others can be found in <xref target="RFC2474"/> and <xref target="R FC2475"/>), if done maliciously, this might negatively affect the QoS of the tam pered microflow. Nonetheless, an on-path attacker can also alter other mutable f ields in the IP header (e.g. the TTL), which can wreak much more havoc than just altering QoS treatment.</t>		<t>NQB uses the Diffserv field. The design of Diffserv does not include in tegrity protection for the DSCP; thus, it is possible for the DSCP to be changed by an on-path attacker. The NQB PHB and associated DSCP don't change this. Whil e re-marking DSCPs is permitted for various reasons (some are discussed in this document, others can be found in <xref target="RFC2474"/> and <xref target="RFC2 475"/>), if done maliciously, this might negatively affect the QoS of the tamper ed microflow. Nonetheless, an on-path attacker can also alter other mutable fiel ds in the IP header (e.g., the TTL), which can wreak much more havoc than just a ltering QoS treatment.</t>
	</section>		</section>
	</middle>		</middle>
	<!-- *****BACK MATTER ***** -->
	<back>		<back>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	<name>Normative References</name>		<name>Normative References</name>
	<reference anchor="RFC8085" target="https://www.rfc-editor.org/info/rfc8		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	085" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.80		085.xml"/>
	85.xml">		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	<front>		119.xml"/>
	<title>UDP Usage Guidelines</title>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<seriesInfo name="DOI" value="10.17487/RFC8085"/>		174.xml"/>
	<seriesInfo name="RFC" value="8085"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<seriesInfo name="BCP" value="145"/>		325.xml"/>
	<author initials="L." surname="Eggert" fullname="L. Eggert">		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	<organization/>		474.xml"/>
	</author>
	<author initials="G." surname="Fairhurst" fullname="G. Fairhurst">
	<organization/>
	</author>
	<author initials="G." surname="Shepherd" fullname="G. Shepherd">
	<organization/>
	</author>
	<date year="2017" month="March"/>
	</front>
	</reference>
	<xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RF
	C.2119.xml"/>
	<xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RF
	C.8174.xml"/>
	<xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RF
	C.8325.xml"/>
	<xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RF
	C.2474.xml"/>
	<!-- <xi:include href="http://xml.resource.org/public/rfc/bibxml/referenc e.RFC.0791.xml"/> -->		<!-- <xi:include href="http://xml.resource.org/public/rfc/bibxml/referenc e.RFC.0791.xml"/> -->
	</references>		</references>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
	<xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RF		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	C.2983.xml"/>		983.xml"/>
	<xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RF		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
	C.3246.xml"/>		246.xml"/>
	<xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RF		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	C.2914.xml"/>		914.xml"/>
	<xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RF		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	C.8033.xml"/>		033.xml"/>
	<xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RF		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	C.8034.xml"/>		034.xml"/>
	<xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RF		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
	C.8289.xml"/>		26.xml"/>
	<xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RF		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	C.8290.xml"/>		289.xml"/>
	<xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RF		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	C.2475.xml"/>		290.xml"/>
	<xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RF		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	C.4594.xml"/>		475.xml"/>
	<xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RF		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
	C.8100.xml"/>		594.xml"/>
	<xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RF		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	C.5127.xml"/>		100.xml"/>
	<xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RF		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
	C.7893.xml"/>		127.xml"/>
	<xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RF		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	C.3551.xml"/>		893.xml"/>
	<xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RF		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
	C.8083.xml"/>		551.xml"/>
	<xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RF		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	C.9330.xml"/>		083.xml"/>
	<xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RF		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	C.9331.xml"/>		330.xml"/>
	<xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RF		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	C.9332.xml"/>		331.xml"/>
	<xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RF		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	C.9435.xml"/>		332.xml"/>
	<xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RF		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	C.8622.xml"/>		435.xml"/>
	<xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RF		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	C.2598.xml"/>		622.xml"/>
	<xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RF		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	C.5681.xml"/>		598.xml"/>
	<xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RF		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
	C.4301.xml"/>		681.xml"/>
	<xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RF		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
	C.2661.xml"/>		301.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	draft-briscoe-docsis-q-protection-07.xml"/>		661.xml"/>
	<xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RF		<!-- [RFC9957];
	C.9438.xml"/>		draft-briscoe-docsis-q-protection-07 companion document
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.		-->
	draft-ietf-ccwg-bbr-03.xml"/>		<reference anchor="RFC9957" target="https://www.rfc-editor.org/info/rfc9957">
	<xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RF		<front>
	C.5865.xml"/>		<title>The DOCSIS(r) Queue Protection Algorithm to Preserve Low Latency</t
	<reference anchor="Custura">		itle>
			<author initials="B." surname="Briscoe" fullname="Bob Briscoe" role="edito
			r">
			<organization>Independent</organization>
			</author>
			<author initials="G." surname="White" fullname="Greg White">
			<organization>CableLabs</organization>
			</author>
			<date month="April" year="2026" />
			</front>
			<seriesInfo name="RFC" value="9957"/>
			<seriesInfo name="DOI" value="10.17487/RFC9957"/>
			</reference>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
			438.xml"/>
			<!-- [BBR-CC]
			draft-ietf-ccwg-bbr-04
			IESG State: I-D Exists as of 2/10/26
			-->
			<reference anchor="BBR-CC" target="https://datatracker.ietf.org/doc/html/draft-i
			etf-ccwg-bbr-04">
			<front>
			<title>BBR Congestion Control</title>
			<author initials="N." surname="Cardwell" fullname="Neal Cardwell" role="ed
			itor">
			<organization>Google</organization>
			</author>
			<author initials="I." surname="Swett" fullname="Ian Swett" role="editor">
			<organization>Google</organization>
			</author>
			<author initials="J." surname="Beshay" fullname="Joseph Beshay" role="edit
			or">
			<organization>Meta</organization>
			</author>
			<date month="October" day="20" year="2025" />
			</front>
			<seriesInfo name="Internet-Draft" value="draft-ietf-ccwg-bbr-04" />
			</reference>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
			865.xml"/>
			<!-- [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.
			-->
			<reference anchor="Custura" target="https://tma.ifip.org/wp-content/uplo
			ads/sites/7/2017/06/mnm2017_paper13.pdf">
	<front>		<front>
	<title>Exploring DSCP modification pathologies in mobile edge networ ks</title>		<title>Exploring DSCP modification pathologies in mobile edge networ ks</title>
	<seriesInfo name="TMA" value=""/>
	<author initials="A." surname="Custura"/>		<author initials="A." surname="Custura"/>
	<author initials="A." surname="Venne"/>		<author initials="A." surname="Venne"/>
	<author initials="G." surname="Fairhurst"/>		<author initials="G." surname="Fairhurst"/>
	<date year="2017"/>		<date year="2017"/>
	</front>		</front>
			<refcontent>Network Traffic Measurement and Analysis Conference (TMA)< /refcontent>
	</reference>		</reference>
	<reference anchor="Barik">		<!-- [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) and added it.
			-->
			<reference anchor="Barik" target="https://gitlab2.informatik.uni-wuerzbu
			rg.de/itc-conference/itc-publications-public/-/raw/master/itc30/Barik18ITC30.pdf
			?inline=true">
	<front>		<front>
	<title>Can WebRTC QoS Work? A DSCP Measurement Study</title>		<title>Can WebRTC QoS Work? A DSCP Measurement Study</title>
	<seriesInfo name="ITC" value="30"/>
	<author initials="R." surname="Barik"/>		<author initials="R." surname="Barik"/>
	<author initials="M." surname="Welzl"/>		<author initials="M." surname="Welzl"/>
	<author initials="A." surname="Elmokashfi"/>		<author initials="A." surname="Elmokashfi"/>
	<author initials="T." surname="Dreibholz"/>		<author initials="T." surname="Dreibholz"/>
	<author initials="S." surname="Gjessing"/>		<author initials="S." surname="Gjessing"/>
	<date month="September" year="2018"/>		<date month="September" year="2018"/>
	</front>		</front>
			<refcontent>30th International Teletraffic Congress (ITC 30)</refconte
			nt>
			<seriesInfo name="DOI" value="10.1109/ITC30.2018.00034"/>
	</reference>		</reference>
	<reference anchor="SA-5G">
			<!--[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? -->
			<reference anchor="SA-5G" target="https://portal.3gpp.org/desktopmodules
			/Specifications/SpecificationDetails.aspx?specificationId=3144
			">
	<front>		<front>
	<title>System Architecture for 5G</title>		<title>System Architecture for the 5G System (5GS)</title>
	<author>		<author>
	<organization>3GPP</organization>		<organization>3GPP</organization>
	</author>		</author>
	<date month="June" year="2024"/>		<date month="June" year="2024"/>
	</front>		</front>
	<refcontent>TS 23.501 V18.6.0</refcontent>		<seriesInfo name="3GPP" value="TS 23.501"/>
			<refcontent>Version 18.6.0, Release 18</refcontent>
	</reference>		</reference>
	<reference anchor="IEEE802-11" target="https://standards.ieee.org/standa
	rd/802_11-2020.html">		<!-- [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? -->
			<reference anchor="IEEE802-11" target="https://ieeexplore.ieee.org/docum
			ent/9363693">
	<front>		<front>
	<title>IEEE 802.11-2020</title>		<title>IEEE Standard for Information Technology -- Telecommunication
	<seriesInfo name="IEEE" value="802"/>		s and Information Exchange between Systems - Local and Metropolitan Area Network
	<author fullname="IEEE-SA"/>		s -- Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) a
	<date month="December" year="2020"/>		nd Physical Layer (PHY) Specifications</title>
			<author>
			<organization>IEEE</organization>
			</author>
			<date month="February" year="2021"/>
			</front>
			<seriesInfo name="IEEE Std" value="802.11-2020"/>
			<seriesInfo name="DOI" value="10.1109/IEEESTD.2021.9363693"/>
			</reference>
			<!-- Note to PE: XML for possible update to [IEEE802-11] (note
			the slashes in the title for double hyphens)
			<reference anchor="IEEE802-11-upd" target="https://ieeexplore.ieee.org/d
			ocument/10979691">
			<front>
			<title>IEEE Standard for Information Technology -/- Telecommunicatio
			ns 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</title>
			<author>
			<organization>IEEE</organization>
			</author>
			<date month="April" year="2025"/>
	</front>		</front>
			<seriesInfo name="IEEE Std" value="802.11-2024"/>
			<seriesInfo name="DOI" value="10.1109/IEEESTD.2025.10979691"/>
	</reference>		</reference>
			-->
			<!-- [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.
			-->
	<reference anchor="TR-369" target="https://usp.technology/specification/ index.html">		<reference anchor="TR-369" target="https://usp.technology/specification/ index.html">
	<front>		<front>
	<title>The User Services Platform</title>		<title>The User Services Platform</title>
	<author>		<author>
	<organization>Broadband Forum</organization>		<organization>Broadband Forum</organization>
	</author>		</author>
	<date year="2022" month="January"/>		<date year="2025" month="July"/>
	</front>		</front>
			<refcontent>Issue: 1 Amendment 4 Corrigendum 2</refcontent>
	</reference>		</reference>
	<reference anchor="QOS_TRAFFIC_TYPE" target="https://learn.microsoft.com /en-us/windows/win32/api/qos2/ne-qos2-qos_traffic_type">		<reference anchor="QOS_TRAFFIC_TYPE" target="https://learn.microsoft.com /en-us/windows/win32/api/qos2/ne-qos2-qos_traffic_type">
	<front>		<front>
	<title>QOS_TRAFFIC_TYPE enumeration</title>		<title>QOS_TRAFFIC_TYPE enumeration (qos2.h)</title>
	<author>		<author>
	<organization>Microsoft, Corporation</organization>		<organization>Microsoft, Corporation</organization>
	</author>		</author>
	<date year="2022"/>		<date month="January" year="2022"/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="LOW_LATENCY_DOCSIS" target="https://cablela.bs/low-la tency-docsis-technology-overview-february-2019">		<reference anchor="LOW_LATENCY_DOCSIS" target="https://cablela.bs/low-la tency-docsis-technology-overview-february-2019">
	<front>		<front>
	<title>Low Latency DOCSIS: Technology Overview</title>		<title>Low Latency DOCSIS: Technology Overview</title>
	<author>		<author>
	<organization>CableLabs</organization>		<organization>CableLabs</organization>
	</author>		</author>
	<date year="2019" month="February"/>		<date year="2019" month="February"/>
	</front>		</front>
	</reference>		</reference>
			<!-- [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) 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.
			-->
	<reference anchor="Gettys2012">		<reference anchor="Gettys2012">
	<front>		<front>
	<title>Bufferbloat: Dark Buffers in the Internet</title>		<title>Bufferbloat: Dark Buffers in the Internet</title>
	<author initials="J." surname="Gettys" />		<author initials="J." surname="Gettys"/>
	<author initials="K." surname="Nichols" />		<author initials="K." surname="Nichols"/>
	<date month="January" year="2012" />		<date month="January" year="2012"/>
	</front>		</front>
	<seriesInfo name="Communications of the ACM" value="Vol. 55, No. 1, pp		<refcontent>Communications of the ACM, vol. 55, no. 1, pp. 57-65</refc
	. 57-65" />		ontent>
	<seriesInfo name="DOI" value="10.1145/2063166.2071893"/>		<seriesInfo name="DOI" value="10.1145/2063176.2063196"/>
	</reference>		</reference>
			<!-- [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>.
			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>.
			-->
	<reference anchor="Cardwell2017">		<reference anchor="Cardwell2017">
	<front>		<front>
	<title>BBR: Congestion-Based Congestion Control</title>		<title>BBR: Congestion-Based Congestion Control</title>
	<author initials="N." surname="Cardwell" />		<author initials="N." surname="Cardwell"/>
	<author initials="Y." surname="Cheng" />		<author initials="Y." surname="Cheng"/>
	<author initials="V." surname="Jacobson" />		<author fullname="C. Stephen Gunn"/>
	<author initials="J." surname="Iyengar" />		<author fullname="Soheil Hassas Yeganeh"/>
	<author initials="I." surname="Swett" />		<author initials="V." surname="Jacobson"/>
	<author initials="B." surname="Yan" />		<date month="February" year="2017"/>
	<date month="February" year="2017" />
	</front>		</front>
	<seriesInfo name="Communications of the ACM" value="Vol. 60, No. 2, pp . 58-66" />		<refcontent>Communications of the ACM, vol. 60, no. 2, pp. 58-66</refc ontent>
	<seriesInfo name="DOI" value="10.1145/3009824"/>		<seriesInfo name="DOI" value="10.1145/3009824"/>
	</reference>		</reference>
	<reference anchor="WikipediaBufferbloat" target="https://en.wikipedia.or g/wiki/Bufferbloat">		<reference anchor="WikipediaBufferbloat" target="https://en.wikipedia.or g/w/index.php?title=Bufferbloat&amp;oldid=1292250296">
	<front>		<front>
	<title>Bufferbloat</title>		<title>Bufferbloat</title>
	<author>		<author>
	<organization>Wikipedia Contributors</organization>		<organization>Wikipedia</organization>
	</author>		</author>
	<date day="23" month="May" year="2025" />		<date month="May" year="2025"/>
	</front>		</front>
	</reference>		</reference>
	</references>		</references>
	</references>		</references>
	<section>		<section>
	<name>DSCP Re-marking Policies</name>		<name>DSCP Re-marking Policies</name>
	<t>Some network operators typically bleach (zero out) the Diffserv field on ingress into their network <xref target="RFC9435"/><xref target="Custura"/>< xref target="Barik"/>, and in some cases apply their own DSCP for internal usage . Bleaching the NQB DSCP is not expected to cause harm to Default traffic, but i t will severely limit the ability to provide NQB treatment. Reports on existing deployments of DSCP manipulation <xref target="Custura"/><xref target="Barik"/> categorize the re-marking behaviors into the following six 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.</t>		<t>Some network operators typically bleach (zero out) the Diffserv field on ingress into their network (see <xref target="RFC9435"/>, <xref target="Cust ura"/>, and <xref target="Barik"/>) and, in some cases, apply their own DSCP for internal use. Bleaching the NQB DSCP is not expected to cause harm to Default t raffic, but it will severely limit the ability to provide NQB treatment. Reports on existing deployments of DSCP manipulation (see <xref target="Custura"/> and <xref target="Barik"/>) categorize the re-marking behaviors into the following p olicies: bleach all traffic (set DSCP to zero); set the top three bits (the for mer 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.</t>
	<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 th ese policies. Thus it appears that these re-marking policies would be unlikely to result in QB traffic being marked as NQB (45). In terms of the fate of traff ic marked with the NQB DSCP that is subjected to 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, the ability for a subsequent network hop to differentiate NQB traffic via DSCP w ould clearly be lost entirely.</t>		<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 th ese policies. Thus, it appears that these re-marking policies would be unlikely to result in QB traffic being marked as NQB (45). In terms of the fate of traf fic marked with the NQB DSCP that is subjected to one of these policies, it woul d 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, the ability for a subsequent network hop to differentiate NQB traffic via DSCP would clearly be lost entirely.</t>
	<t>In the policies where the top three bits are overwritten (see <xref t arget="RFC9435" section="4.2"/>), the NQB DSCP (45) would receive the same marki ng as would the currently unassigned Pool 3 DSCPs 5,13,21,29,37,53,61, with all of these DSCPs getting re-marked to DSCP = 5, 13 or 21 (depending on the overwri te value used). Since none of the DSCPs in the preceding lists are currently ass igned by IANA, and they all are reserved for Standards Action, it is believed th at they are not widely used currently, but this could vary based on local-usage, and could change in the future. If networks in which this sort of re-marking oc curs (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 trea tment to other traffic that was not originally marked as NQB. In addition, as d escribed in <xref target="RFC9435" section="6"/> future assignments of these 0bx xx101 DSCPs would need to be made with consideration of the potential that they all are treated as NQB in some networks.</t>		<t>In the policies where the top three bits are overwritten (see <xref t arget="RFC9435" section="4.2"/>), the NQB DSCP (45) would receive the same marki ng 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 o n the overwrite value used). Since none of the DSCPs in the preceding lists are currently assigned by IANA, and they all are reserved for Standards Action, it i s believed that they are not widely used currently; however, this could vary bas ed on local-usage and could change in the future. 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. In addition, as described in <xref target="RFC9435" section="6"/> future assignmen ts of these 0bxxx101 DSCPs would need to be made with consideration of the poten tial that they all are treated as NQB in some networks.</t>
	<t>For the policy in which the low three bits are set to 0b000, the NQB (45) value would be re-marked to CS5 and would be indistinguishable from CS5, VA , EF (and the currently unassigned DSCPs 41, 42, 43). Traffic marked using the existing standardized DSCPs in this list are likely to share the same general pr operties as NQB traffic (non-capacity-seeking, very low data rate or relatively low and consistent data rate). Similarly, any future recommended usage for DSCPs 41, 42, 43 would likely be somewhat compatible with NQB treatment, assuming tha t IP Precedence compatibility (see <xref target="RFC4594" section="1.5.4"/>) is maintained in the future. Here there might be an opportunity for a node to provi de the NQB PHB or the CS5 PHB to CS5-marked traffic and retain some of the benef its of NQB marking. This could be another motivation to classify CS5-marked tra ffic into the NQB queue (as discussed in <xref target="aggregation2"/>).</t>		<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). Traf fic marked using the existing standardized DSCPs in this list are likely to shar e the same general properties as NQB traffic (non-capacity-seeking and very low data rate, relatively low data rate, and consistent data rate). Similarly, any f uture recommended usage for DSCPs 41, 42, 43 would likely be somewhat compatible with NQB treatment, assuming that IP Precedence compatibility (see <xref target ="RFC4594" section="1.5.4"/>) is maintained in the future. Here there might be a n opportunity for a node to provide the NQB PHB or the CS5 PHB to CS5-marked tra ffic and retain some of the benefits of NQB marking. This could be another moti vation to classify CS5-marked traffic into the NQB queue (as discussed in <xref target="aggregation2"/>).</t>
	</section>		</section>
	<section anchor="EF">		<section anchor="EF">
	<name>Comparison with Expedited Forwarding</name>		<name>Comparison with Expedited Forwarding</name>
	<t>The Expedited Forwarding definition <xref target="RFC3246"/> provides t		<t>The Expedited Forwarding definition <xref target="RFC3246"/> provides t
	he following text to describe the EF PHB forwarding behavior: "This specificatio		he following text to describe the EF PHB forwarding behavior:</t>
	n defines a PHB in which EF		<blockquote>
	packets are guaranteed to receive service at or above a configured rate" a		This specification defines a PHB in which EF packets are guaranteed
	nd "the rate at which EF		to receive service at or above a configured rate</blockquote>
	traffic is served at a given output interface should be at least the		<t>and</t>
	configured rate R, over a suitably defined interval, independent of		<blockquote>the rate at
	the offered load of non-EF traffic to that interface."		which EF traffic is served at a given output interface should be at
	Notably, this description is true of any class of traffic that is configur		least the configured rate R, over a suitably defined interval,
	ed with a guaranteed minimum rate, including the Default PHB if configured per t		independent of the offered load of non-EF traffic to that interface.</blockquote
	he guidelines in <xref target="RFC4594" section="1.5.1"/>. <xref target="RFC3246		>
	"/> goes on to formalize the definition of EF by requiring that an EF node be ch		<t>Notably, this description is true of any class of traffic that is confi
	aracterizable in terms of the fidelity with which it is able to provide a guaran		gured with a guaranteed minimum rate, including the Default PHB if configured pe
	teed rate.</t>		r the guidelines in <xref target="RFC4594" section="1.5.1"/>. <xref target="RFC3
			246"/> 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 gua
			ranteed rate.</t>
	<t>While the NQB PHB is not required to be configured with a guaranteed mi nimum rate, <xref target="RFC2474"/> and <xref target="RFC4594"/> recommend assi gning some minimum resources for the Default PHB, in particular some dedicated c apacity. If such a guaranteed minimum rate is configured for the Default PHB, it is recommended (<xref target="phb_requirements"/>) that NQB traffic share and b e given equal access to that rate. In such cases, the NQB PHB could effectively receive a rate guarantee of (e.g.) 50% of the rate guaranteed to the combined NQ B/Default PHBs, and so technically complies with the PHB forwarding behavior def ined for EF. </t>		<t>While the NQB PHB is not required to be configured with a guaranteed mi nimum rate, <xref target="RFC2474"/> and <xref target="RFC4594"/> recommend assi gning some minimum resources for the Default PHB, in particular, some dedicated capacity. If such a guaranteed minimum rate is configured for the Default PHB, i t is recommended (<xref target="phb_requirements"/>) that NQB traffic share and be given equal access to that rate. In such cases, the NQB PHB could effectively receive a rate guarantee of (for example) 50% of the rate guaranteed to the com bined NQB/Default PHBs; therefore, it technically complies with the PHB forwardi ng behavior defined for EF. </t>
	<t>However, EF is intended to be a managed service, and requires that traf		<t>However, EF is intended to be a managed service and requires that traff
	fic be policed such that the arriving rate of traffic into the EF PHB doesn't ex		ic be policed such that the arriving rate of traffic into the EF PHB doesn't exc
	ceed the guaranteed forwarding rate configured for the PHB, thereby ensuring tha		eed the guaranteed forwarding rate configured for the PHB. This ensures that lo
	t low delay and low delay variation are provided. NQB is intended as a best eff		w delay and low delay variation are provided. NQB is intended as a best effort
	ort service, and hence the aggregate of traffic arriving to the NQB PHB queue co		service; hence, the aggregate of traffic arriving to the NQB PHB queue could exc
	uld exceed the forwarding rate available to the PHB. <xref target="traffic_prote		eed the forwarding rate available to the PHB. <xref target="traffic_protection"/
	ction"/> discusses the recommended mechanism for handling excess traffic in NQB.		> discusses the recommended mechanism for handling excess traffic in NQB.
	While EF relies on rate policing and dropping of excess traffic at the dom		While EF relies on rate policing and dropping of excess traffic at the dom
	ain border, this is only one option for NQB. NQB primarily recommends traffic pr		ain border, this is only one option for NQB. NQB primarily recommends traffic pr
	otection located at each potential bottleneck, where actual queuing can be detec		otection located at each potential bottleneck, where actual queuing can be detec
	ted and where excess traffic can be reclassified into the Default PHB rather tha		ted and where excess traffic can be reclassified into the Default PHB rather tha
	n dropping it. Local traffic protection is more feasible for NQB, given the focu		n dropping it. Local traffic protection is more feasible for NQB, given the focu
	s is on access networks, where one node is typically designed to be the known bo		s is on access networks, where one node is typically designed to be the known bo
	ttleneck where traffic control functions all reside. In contrast, EF is presumed		ttleneck where traffic control functions all reside. In contrast, EF is presumed
	to follow the Diffserv architecture <xref target="RFC2475"/> for core networks,		to follow the Diffserv architecture <xref target="RFC2475"/> for core networks,
	where traffic conditioning is delegated to border nodes, in order to simplify h		where traffic conditioning is delegated to border nodes in order to simplify hi
	igh capacity interior nodes.		gh capacity interior nodes.
	Further, NQB recommends a microflow-based mechanism to limit the performan ce impact of excess traffic to those microflows causing potential congestion of the NQB queue, whereas EF ignores microflow properties.		Further, NQB recommends a microflow-based mechanism to limit the performan ce impact of excess traffic to 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 ensu red if such a mechanism is operational. Note also that this mechanism for NQB op erates at the available forwarding rate for the PHB (which could vary based on o ther traffic load) as opposed to a configured guaranteed rate, as in EF.</t>		Note that, under congestion, low loss for NQB-conformant flows is only ens ured if such a mechanism is operational. Note also that this mechanism for NQB o perates at the available forwarding rate for the PHB (which could vary based on other traffic load) as opposed to a configured guaranteed rate, as in EF.</t>
	<t>The lack of a requirement of a guaranteed minimum rate, and the lack of a requirement to police incoming traffic to such a rate, makes the NQB PHB suit able for implementation in networks where link capacity is not or cannot be guar anteed.</t>		<t>The lack of a requirement of a guaranteed minimum rate, and the lack of a requirement to police incoming traffic to such a rate, makes the NQB PHB suit able for implementation in networks where link capacity is not or cannot be guar anteed.</t>
	<t>There are additional distinctions between EF and NQB arising from the i		<t>There are additional distinctions between EF and NQB arising from the i
	ntended usage as described in <xref target="RFC4594"/> and the actual usage in p		ntended usage as described in <xref target="RFC4594"/> and the actual usage in p
	ractice in the Internet. In <xref target="RFC4594" section="1.5.3"/>, EF is desc		ractice in the Internet. In <xref target="RFC4594" section="1.5.3"/>, EF is desc
	ribed as generally being used to carry voice or data that requires "wire like" b		ribed as generally being used to carry voice or data that requires "wire-like" b
	ehavior through the network.		ehavior through the network.
	The NQB PHB similarly is useful to carry application traffic requiring wir		The NQB PHB similarly is useful to carry application traffic requiring wir
	e like performance, characterized by low delay and low delay-variation, but plac		e-like performance, characterized by low delay and low delay variation, but plac
	es a pre-condition that each microflow be relatively low data rate and sent in a		es 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 priori		smooth (non-bursty) manner. In actual practice, EF traffic is oftentimes priori
	tized over Default traffic. This contrasts with NQB traffic which is to be treat		tized over Default traffic. This contrasts with NQB traffic, which is to be trea
	ed with the same forwarding precedence as Default (and sometimes aggregated with		ted with the same forwarding precedence as Default (and sometimes aggregated wit
	Default).</t>		h Default).</t>
	</section>		</section>
	<section>		<section>
	<name>Impact on Higher Layer Protocols</name>		<name>Impact on Higher Layer Protocols</name>
	<t>The NQB PHB itself has no impact on higher layer protocols, because it only isolates NQB traffic from non-NQB. However, traffic protection of the PHB c an have unintended side-effects on higher layer protocols. Traffic protection in troduces the possibility that microflows classified into the NQB queue could exp erience out-of-order delivery or packet loss if their behavior is not consistent with the NQB sender requirements. Out-of-order delivery could be particularly l ikely 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 in 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 queu e. In the case of redirection, depending on the queuing delay and scheduling wi thin the network element, this could result in packets being delivered out of or der. As a result, the use of the NQB DSCP by a higher layer protocol carries so me risk that an increased amount of out-of-order delivery or packet loss will be experienced. This characteristic provides one disincentive for incorrectly sett ing the NQB DSCP on traffic that doesn't comply with the NQB sender requirements .</t>		<t>The NQB PHB itself has no impact on higher layer protocols because it o nly isolates NQB traffic from non-NQB. However, traffic protection of the PHB ca n have unintended side effects on higher layer protocols. Traffic protection int roduces the possibility that microflows classified into the NQB queue could expe rience out-of-order delivery or packet loss if their behavior is not consistent with the NQB sender requirements. Out-of-order delivery could be particularly li kely if the traffic protection algorithm makes decisions on a packet-by-packet b asis. In this scenario, a microflow that is (mis-)marked as NQB and that causes a queue to form in 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 wit hin the network element, this could result in packets being delivered out of ord er. As a result, the use of the NQB DSCP by a higher layer protocol carries som e risk that an increased amount of out-of-order delivery or packet loss will be experienced. This characteristic provides one disincentive for incorrectly setti ng the NQB DSCP on traffic that doesn't comply with the NQB sender requirements. </t>
	</section>		</section>
	<section>		<section>
	<name>Alternative Diffserv Code Points</name>		<name>Alternative Diffserv Code Points</name>
	<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 m eet specific application requirements (e.g., a guaranteed-delay path for voice t raffic), it could be preferred to use another DSCP.</t>		<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 me et specific application requirements (e.g., a guaranteed-delay path for voice tr affic), use of another DSCP value could be preferred.</t>
	<t>In end systems where the choice of using DSCP 45 (decimal) is not ava ilable to the application, the CS5 DSCP (40 decimal) could be used as a fallback . See <xref target="aggregation2"/> for rationale as to why this choice could b e fruitful.</t>		<t>In end systems where the choice of using DSCP 45 (decimal) is not ava ilable to the application, the CS5 DSCP (40 decimal) could be used as a fallback . See <xref target="aggregation2"/> for rationale as to why this choice could b e fruitful.</t>
	</section>		</section>
	<section anchor="Acknowledgements" numbered="false">		<section anchor="Acknowledgements" numbered="false">
	<name>Acknowledgements</name>		<name>Acknowledgements</name>
	<t>Thanks to Gorry Fairhurst, Diego Lopez, Stuart Cheshire, Brian Carpente		<t>Thanks to <contact fullname="Gorry Fairhurst"/>, <contact
	r, Bob Briscoe, Greg Skinner, Toke Hoeiland-Joergensen, Luca Muscariello, David		fullname="Diego Lopez"/>, <contact fullname="Stuart Cheshire"/>,
	Black, Jerome Henry, Steven Blake, Jonathan Morton, Roland Bless, Kevin Smith, M		<contact fullname="Brian Carpenter"/>, <contact fullname="Bob
	artin Dolly and Kyle Rose for their review comments. Thanks also to Gorry Fairh		Briscoe"/>, <contact fullname="Greg Skinner"/>, <contact fullname="Toke
	urst and Ana Custura for their input on selection of appropriate DSCPs.</t>		Hoeiland-Joergensen"/>, <contact fullname="Luca Muscariello"/>, <contact
			fullname="David Black"/>, <contact fullname="Jerome Henry"/>, <contact
			fullname="Steven Blake"/>, <contact fullname="Jonathan Morton"/>,
			<contact fullname="Roland Bless"/>, <contact fullname="Kevin Smith"/>,
			<contact fullname="Martin Dolly"/>, and <contact fullname="Kyle Rose"/>
			for their review comments. Thanks also to <contact fullname="Gorry
			Fairhurst"/> and <contact fullname="Ana Custura"/> for their input on
			selection of appropriate DSCPs. Thanks to the following for IESG reviews
			and comments: <contact fullname="Mohamed Boucadair"/>, <contact fullname="Ketan
			Talaulikar"/>, <contact fullname="Mike Bishop"/>, <contact fullname="Roman Danyl
			iw"/>, and <contact fullname="Éric Vyncke"/>.</t>
	</section>		</section>
	<!-- Possibly a 'Contributors' section ... -->
			<!--[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.
			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?
			iv) May we treat other DSCP numbers similarly? Some examples:
			Current:
			...DSCPs 41, 42, 43).
			Perhaps:
			...DSCP values 41, 42, and 43 (all decimal)).
			Current:
			...CS5 DSCP (40 decimal)
			Perhaps:
			... CS5 DSCP value 40 (decimal)
			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?
			Further, is the Classic queue the same as the Default queue? Or are these diffe
			rent things?
			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?
			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).
			Best Effort Access Category vs. "Best Effort" Access Category
			(see also best-effort service
			Default vs. default
			differentiated service class vs. DiffServ Service Classes
			differentiated services vs. Differentiated Services
			Diffserv Domain vs. DiffServ domain vs. Diffserv domain
			Field vs. field (when describing Diffserv or DSCP)
			higher-than-necessary vs. higher-than-needed
			low data rate applications vs. low-rate applications
			quality of experience vs. Quality of Experience
			Video Access Category vs. "Video" Access Category
			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
			-->
			<!-- [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
			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):
			NQB
			QB
			DSCP
			TCA
			CS
			QoS
			EDCA
			EF
			-->
			<!-- [rfced] Please review the "Inclusive Language" portion of the online
			Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
			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-l
			ibrary/nist-technical-series-publications-author-instructions#table1>
			indicates that this term is potentially biased, it is also ambiguous.
			"Tradition" is a subjective term, as it is not the same for everyone.
			-->
	-&gt;
	</back>		</back>
	</rfc>		</rfc>
	<!-- vim: ft=xml tabstop=2 expandtab:
End of changes. 162 change blocks.
	736 lines changed or deleted		1401 lines changed or added
This html diff was produced by rfcdiff 1.48.