rfc9956v2.txt		rfc9956.txt
	skipping to change at line 19 ¶		skipping to change at line 19 ¶
	A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated		A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated
	Services		Services
	Abstract		Abstract
	This document specifies characteristics of a Non-Queue-Building Per-		This document specifies characteristics of a Non-Queue-Building Per-
	Hop Behavior (NQB PHB). The NQB PHB provides a shallow-buffered,		Hop Behavior (NQB PHB). The NQB PHB provides a shallow-buffered,
	best-effort service as a complement to a Default deep-buffered, best-		best-effort service as a complement to a Default deep-buffered, best-
	effort service for Internet services. The purpose of this NQB PHB is		effort service for Internet services. The purpose of this NQB PHB is
	to provide separate queue-enabling traffic microflows that are smooth		to provide a separate queue that enables smooth (i.e., non-bursty),
	(i.e., non-bursty), have a low data rate, and are application limited		low-data-rate, application-limited traffic microflows, to avoid the
	to avoid the delay, delay variation, and loss that would ordinarily		delay, delay variation and loss that would ordinarily be caused by
	be caused by sharing a queue with bursty, capacity-seeking traffic.		sharing a queue with bursty, capacity-seeking traffic. This PHB is
	This PHB is implemented without prioritization and can be implemented		implemented without prioritization and can be implemented without
	without rate policing, making it suitable for environments where the		rate policing, making it suitable for environments where the use of
	use of these features is restricted. The NQB PHB has been developed		these features is restricted. The NQB PHB has been developed
	primarily for use by access network segments, where queuing delay and		primarily for use by access network segments, where queuing delay and
	queuing loss caused by Queue-Building (QB) protocols are manifested;		queuing loss caused by Queue-Building (QB) protocols are manifested;
	however, its use is not limited to such segments. In particular, the		however, its use is not limited to such segments. In particular, the
	application of NQB PHB to cable broadband links, Wi-Fi links, and		application of NQB PHB to cable broadband links, Wi-Fi links, and
	mobile network radio/core segments are discussed in this document.		mobile network radio/core segments are discussed in this document.
	This document recommends a specific Differentiated Services Code		This document recommends a specific Differentiated Services Code
	Point (DSCP) to identify NQB microflows and updates the guidance in		Point (DSCP) to identify NQB microflows and updates the guidance in
	RFC 8325 on mapping Differentiated Services (Diffserv or DS) to IEEE		RFC 8325 on mapping Differentiated Services (Diffserv or DS) to IEEE
	802.11 for this codepoint.		802.11 for this codepoint.
	skipping to change at line 71 ¶		skipping to change at line 71 ¶
	include Revised BSD License text as described in Section 4.e of the		include Revised BSD License text as described in Section 4.e of the
	Trust Legal Provisions and are provided without warranty as described		Trust Legal Provisions and are provided without warranty as described
	in the Revised BSD License.		in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction		1. Introduction
	2. Requirements Language		2. Requirements Language
	3. Context		3. Context
	3.1. NQB Behavior		3.1. NQB Behavior
	3.2. Relationship to the DS Architecture		3.2. Relationship to the Diffserv Architecture
	3.3. Relationship to L4S		3.3. Relationship to L4S
	3.4. Applicability		3.4. Applicability
	4. NQB Sender Requirements		4. NQB Sender Requirements
	5. NQB PHB Requirements		5. NQB PHB Requirements
	5.1. Primary Requirements		5.1. Primary Requirements
	5.2. Traffic Protection		5.2. Traffic Protection
	5.3. Limiting Packet Bursts from Links		5.3. Limiting Packet Bursts from Links
	5.4. Treatment of the Explicit Congestion Notification Field		5.4. Treatment of the Explicit Congestion Notification Field
	6. Operational Considerations		6. Operational Considerations
	6.1. NQB Traffic Identification		6.1. NQB Traffic Identification
	6.2. Aggregation of the NQB DSCP into Another DS PHB		6.2. Aggregation of the NQB DSCP into Another Diffserv PHB
	6.3. Aggregation of Other DSCPs into the NQB PHB		6.3. Aggregation of Other DSCPs into the NQB PHB
	6.4. Cross-Domain Usage and DSCP Re-marking		6.4. Cross-Domain Usage and DSCP Re-marking
	6.4.1. Interoperability with Non-DS-Capable Domains		6.4.1. Interoperability with Non-DS-Capable Domains
	6.5. The NQB DSCP and Tunnels		6.5. The NQB DSCP and Tunnels
	6.6. Guidance for Lower-Rate Links		6.6. Guidance for Lower-Rate Links
	7. Mapping NQB to Standards of Other SDOs		7. Mapping NQB to Standards of Other SDOs
	7.1. DOCSIS Access Networks		7.1. DOCSIS Access Networks
	7.2. Mobile Networks		7.2. Mobile Networks
	7.3. Wi-Fi Networks		7.3. Wi-Fi Networks
	7.3.1. Interoperability with Existing Wi-Fi Networks		7.3.1. Interoperability with Existing Wi-Fi Networks
	7.3.2. The Updates to RFC 8325		7.3.2. The Updates to RFC 8325
	8. IANA Considerations		8. IANA Considerations
	9. Security Considerations		9. Security Considerations
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	10.2. Informative References		10.2. Informative References
	Appendix A. DSCP Re-marking Policies		Appendix A. DSCP Re-marking Policies
	Appendix B. Comparison with Expedited Forwarding		Appendix B. Comparison with Expedited Forwarding
	Appendix C. Impact on Higher Layer Protocols		Appendix C. Impact on Higher Layer Protocols
	Appendix D. Alternative DS Codepoints		Appendix D. Alternative Diffserv Codepoints
	Acknowledgements		Acknowledgements
	Authors' Addresses		Authors' Addresses
	1. Introduction		1. Introduction
	This document defines a DS PHB called the "Non-Queue-Building Per-Hop		This document defines a Diffserv PHB called the "Non-Queue-Building
	Behavior" (or "NQB PHB"). The NQB PHB isolates traffic microflows		Per-Hop Behavior" (or "NQB PHB"). The NQB PHB isolates traffic
	(application-to-application flows, see Section 1.2 of [RFC2475]) that		microflows (application-to-application flows, see Section 1.2 of
	have relatively low data rates and that do not, themselves,		[RFC2475]) that have relatively low data rates and that do not,
	materially contribute to queuing delay and loss. This isolation		themselves, materially contribute to queuing delay and loss. This
	allows these traffic microflows to avoid the queuing delay and losses		isolation allows these traffic microflows to avoid the queuing delay
	caused by other traffic.		and losses caused by other traffic.
	NQB microflows such as interactive voice, game sync packets, certain		NQB microflows such as interactive voice, game sync packets, certain
	machine-to-machine applications, DNS lookups, and some real-time		machine-to-machine applications, DNS lookups, and some real-time
	Internet of Things (IoT) analytics data are low-data-rate,		Internet of Things (IoT) analytics data are low-data-rate,
	application-limited microflows. These can be distinguished from		application-limited microflows. These can be distinguished from
	bursty traffic microflows and high-data-rate traffic microflows		bursty traffic microflows and high-data-rate traffic microflows
	managed by a classic congestion control algorithm (both of which		managed by a classic congestion control algorithm (both of which
	cause queuing delay and loss). The term "classic congestion control"		cause queuing delay and loss). The term "classic congestion control"
	is defined in [RFC9330] to mean congestion control that coexists with		is defined in [RFC9330] to mean congestion control that coexists with
	standard Reno congestion control [RFC5681]. In this document, we		standard Reno congestion control [RFC5681]. In this document, we
	skipping to change at line 233 ¶		skipping to change at line 233 ¶
	candidates to be queued separately from the applications that are the		candidates to be queued separately from the applications that are the
	cause of queue buildup, delay, and loss.		cause of queue buildup, delay, and loss.
	In contrast, QB microflows include those that probe for link capacity		In contrast, QB microflows include those that probe for link capacity
	and induce delay and loss as a result, for example, microflows that		and induce delay and loss as a result, for example, microflows that
	use CUBIC, Reno, or other TCP/QUIC congestion control algorithms in a		use CUBIC, Reno, or other TCP/QUIC congestion control algorithms in a
	capacity-seeking manner. Other types of QB microflows include those		capacity-seeking manner. Other types of QB microflows include those
	that send at a high burst rate even if the long-term average data		that send at a high burst rate even if the long-term average data
	rate is much lower.		rate is much lower.
	3.2. Relationship to the DS Architecture		3.2. Relationship to the Diffserv Architecture
	The IETF has defined the DS architecture [RFC2475] with the intention		The IETF has defined the Diffserv architecture [RFC2475] with the
	that it allows traffic to be marked in a manner that conveys the		intention that it allows traffic to be marked in a manner that
	performance requirements of that traffic either qualitatively or in a		conveys the performance requirements of that traffic either
	relative sense (e.g., priority). The architecture defines the use of		qualitatively or in a relative sense (e.g., priority). The
	the DS field [RFC2474] for this purpose, and numerous RFCs have been		architecture defines the use of the DSCP field [RFC2474] for this
	written that describe recommended interpretations of the values (DS		purpose, and numerous RFCs have been written that describe
	Codepoints [RFC2474]) of the field, and standardized treatments		recommended interpretations of the values (Diffserv Codepoints
	(traffic conditioning and per-hop-behaviors [RFC2475]) that can be		[RFC2474]) of the field, and standardized treatments (traffic
	implemented to satisfy the performance requirements of traffic so		conditioning and per-hop-behaviors [RFC2475]) that can be implemented
	marked.		to satisfy the performance requirements of traffic so marked.
	While this architecture is powerful and flexible enough to be		While this architecture is powerful and flexible enough to be
	configured to meet the performance requirements of a variety of		configured to meet the performance requirements of a variety of
	applications and traffic categories, or to achieve differentiated		applications and traffic categories, or to achieve differentiated
	service offerings, meeting the performance requirements of an		service offerings, meeting the performance requirements of an
	application across the entire sender-to-receiver path involves all		application across the entire sender-to-receiver path involves all
	the networks in the path agreeing on what those requirements are and		the networks in the path agreeing on what those requirements are and
	sharing an interest in meeting them. In many cases, this is made		sharing an interest in meeting them. In many cases, this is made
	more difficult since the performance "requirements" are not strict		more difficult since the performance "requirements" are not strict
	ones (e.g., applications will degrade in some manner as loss, delay,		ones (e.g., applications will degrade in some manner as loss, delay,
	and/or delay-variation increase), so the importance of meeting them		and/or delay-variation increase), so the importance of meeting them
	for any particular application in some cases involves a judgment as		for any particular application in some cases involves a judgment as
	to the value of avoiding some amount of degradation in quality for		to the value of avoiding some amount of degradation in quality for
	that application in exchange for an increase in the degradation of		that application in exchange for an increase in the degradation of
	another application.		another application.
	Further, in many cases, the implementation of DS PHBs has		Further, in many cases, the implementation of Diffserv PHBs has
	historically involved prioritization of service classes with respect		historically involved prioritization of service classes with respect
	to one another, which sets up the zero-sum game alluded to in the		to one another, which sets up the zero-sum game alluded to in the
	previous paragraph and which results in the need to limit access to		previous paragraph and which results in the need to limit access to
	higher priority classes via mechanisms such as access control,		higher priority classes via mechanisms such as access control,
	admission control, traffic conditioning and rate policing, and/or to		admission control, traffic conditioning and rate policing, and/or to
	meter and bill for carriage of such traffic. These mechanisms can be		meter and bill for carriage of such traffic. These mechanisms can be
	difficult or impossible to implement in the Internet.		difficult or impossible to implement in the Internet.
	In contrast, the NQB PHB has been designed with the goal that it		In contrast, the NQB PHB has been designed with the goal that it
	avoids many of these issues; thus, it could conceivably be deployed		avoids many of these issues; thus, it could conceivably be deployed
	skipping to change at line 286 ¶		skipping to change at line 286 ¶
	reserved capacity other than any minimum capacity that it shares with		reserved capacity other than any minimum capacity that it shares with
	Default traffic. As a result, the NQB PHB does not aim to meet		Default traffic. As a result, the NQB PHB does not aim to meet
	specific application performance requirements. Instead, the sole		specific application performance requirements. Instead, the sole
	goal of the NQB PHB is to isolate NQB traffic from other traffic that		goal of the NQB PHB is to isolate NQB traffic from other traffic that
	causes an increase in loss, delay, and/or delay-variation, given that		causes an increase in loss, delay, and/or delay-variation, given that
	the NQB traffic is, itself, only an insignificant contributor to		the NQB traffic is, itself, only an insignificant contributor to
	those degradations. The PHB is also designed to reduce the		those degradations. The PHB is also designed to reduce the
	incentives for a sender to mis-mark its traffic since neither higher		incentives for a sender to mis-mark its traffic since neither higher
	capacity nor reserved capacity are being offered. These attributes		capacity nor reserved capacity are being offered. These attributes
	eliminate many of the trade-offs that underlie the handling of		eliminate many of the trade-offs that underlie the handling of
	differentiated service classes in the DS architecture as it has		differentiated service classes in the Diffserv architecture as it has
	previously been defined. These attributes also significantly		previously been defined. These attributes also significantly
	simplify access control and admission control functions, reducing		simplify access control and admission control functions, reducing
	them to simple verification of behavior. This aspect is discussed		them to simple verification of behavior. This aspect is discussed
	further in Sections 4 and 5.2.		further in Sections 4 and 5.2.
	Therefore, the NQB PHB is intended for the situation where the		Therefore, the NQB PHB is intended for the situation where the
	performance requirements of applications cannot be assured across the		performance requirements of applications cannot be assured across the
	whole sender-to-receiver path; as a result, applications cannot		whole sender-to-receiver path; as a result, applications cannot
	feasibly place requirements on the network. Instead, many		feasibly place requirements on the network. Instead, many
	applications have evolved to make the best out of the network		applications have evolved to make the best out of the network
	environment that they find themselves in. In this context, the NQB		environment that they find themselves in. In this context, the NQB
	PHB is intended to provide a better network environment for		PHB is intended to provide a better network environment for
	applications that send data at relatively low and non-bursty data		applications that send data at relatively low and non-bursty data
	rates.		rates.
	In regard to a comparison between the NQB PHB and other standardized		In regard to a comparison between the NQB PHB and other standardized
	PHBs in the DS series, the closest similarity is to the Expedited		PHBs in the Diffserv series, the closest similarity is to the
	Forwarding (EF) PHB [RFC3246], which also intends to enable services		Expedited Forwarding (EF) PHB [RFC3246], which also intends to enable
	that provide low loss, low delay, and low-delay variation. Unlike		services that provide low loss, low delay, and low-delay variation.
	EF, NQB has no requirement for a guaranteed minimum rate, nor does		Unlike EF, NQB has no requirement for a guaranteed minimum rate, nor
	have a requirement to police incoming traffic to such a rate: NQB is		does have a requirement to police incoming traffic to such a rate:
	expected to be given the same forwarding preference as Default		NQB is expected to be given the same forwarding preference as Default
	traffic. See Appendix B for a more detailed comparison of the NQB		traffic. See Appendix B for a more detailed comparison of the NQB
	and EF PHBs.		and EF PHBs.
	In nodes that support multiple DS Service Classes, NQB traffic is		In nodes that support multiple Diffserv Service Classes, NQB traffic
	intended to be handled as a part of the Default treatment. Traffic		is intended to be handled as a part of the Default treatment.
	assigned to this class does not receive better forwarding treatment		Traffic assigned to this class does not receive better forwarding
	(e.g., prioritization) with respect to other classes, AFxx, EF, etc.		treatment (e.g., prioritization) with respect to other classes, AFxx,
	Of course, traffic marked as NQB could (like other Default traffic)		EF, etc. Of course, traffic marked as NQB could (like other Default
	receive better forwarding treatment with respect to Lower-Effort (LE)		traffic) receive better forwarding treatment with respect to Lower-
	[RFC8622] (e.g., the NQB queue could be emptied in a priority		Effort (LE) [RFC8622] (e.g., the NQB queue could be emptied in a
	sequence before the LE queue).		priority sequence before the LE queue).
	3.3. Relationship to L4S		3.3. Relationship to L4S
	In this document, the NQB DSCP and PHB have been defined to operate		In this document, the NQB DSCP and PHB have been defined to operate
	independently of the Low Latency, Low Loss, and Scalable throughput		independently of the Low Latency, Low Loss, and Scalable throughput
	(L4S) architecture [RFC9330]. Nonetheless, traffic marked with the		(L4S) architecture [RFC9330]. Nonetheless, traffic marked with the
	NQB DSCP is intended to be compatible with L4S [RFC9330], with the		NQB DSCP is intended to be compatible with L4S [RFC9330], with the
	result being that NQB traffic and L4S traffic can share the low-		result being that NQB traffic and L4S traffic can share the low-
	latency queue in an L4S DualQ node [RFC9332]. A network node's		latency queue in an L4S DualQ node [RFC9332]. A network node's
	compliance with the DualQ Coupled AQM requirements (see Section 2.5		compliance with the DualQ Coupled AQM requirements (see Section 2.5
	skipping to change at line 416 ¶		skipping to change at line 416 ¶
	insufficient. To be clear, the description of NQB-marked microflows		insufficient. To be clear, the description of NQB-marked microflows
	in this document is not to be interpreted as suggesting that		in this document is not to be interpreted as suggesting that
	applications generating such microflows are in any way exempt from		applications generating such microflows are in any way exempt from
	this responsibility. One way that an application marking its traffic		this responsibility. One way that an application marking its traffic
	as NQB can handle this is to implement a scalable congestion control		as NQB can handle this is to implement a scalable congestion control
	mechanism as described in [RFC9331].		mechanism as described in [RFC9331].
	The DS field specification requires the definition of a recommended		The DS field specification requires the definition of a recommended
	DSCP to be associated with each standardized PHB (see Section 5 of		DSCP to be associated with each standardized PHB (see Section 5 of
	[RFC2474]). In accordance with this, applications are RECOMMENDED to		[RFC2474]). In accordance with this, applications are RECOMMENDED to
	use the DSCP 45 (decimal) to mark microflows as NQB. The choice of		use the DSCP value 45 (decimal) to mark microflows as NQB. The
	the DSCP value 45 (decimal) is motivated, in part, by the desire to		choice of the DSCP value 45 (decimal) is motivated, in part, by the
	achieve separate queuing in existing Wi-Fi networks (see Section 7.3)		desire to achieve separate queuing in existing Wi-Fi networks (see
	and by the desire to make implementation of the PHB simpler in		Section 7.3) and by the desire to make implementation of the PHB
	network equipment that has the ability to classify traffic based on		simpler in network equipment that has the ability to classify traffic
	ranges of DSCP values (see Section 6.3 for further discussion).		based on ranges of DSCP values (see Section 6.3 for further
			discussion).
	The two primary considerations for whether an application chooses to		The two primary considerations for whether an application chooses to
	mark its traffic as NQB involve the risks of being subjected to a		mark its traffic as NQB involve the risks of being subjected to a
	traffic protection algorithm (see Section 5.2) and/or to the		traffic protection algorithm (see Section 5.2) and/or to the
	consequences of overrunning the NQB shallow buffer if (in either		consequences of overrunning the NQB shallow buffer if (in either
	case) the traffic contributes to the formation of a queue in a node		case) the traffic contributes to the formation of a queue in a node
	that supports the PHB. In both cases, the result could be that		that supports the PHB. In both cases, the result could be that
	excess traffic is discarded or queued separately as Default traffic		excess traffic is discarded or queued separately as Default traffic
	(and, thus, potentially is delivered out of order). To avoid these		(and, thus, potentially is delivered out of order). To avoid these
	risks, if a microflow's traffic exceeds the rate equation provided in		risks, if a microflow's traffic exceeds the rate equation provided in
	skipping to change at line 453 ¶		skipping to change at line 454 ¶
	Section 5.2.		Section 5.2.
	5. NQB PHB Requirements		5. NQB PHB Requirements
	For the NQB PHB to become widely deployed, it is important that		For the NQB PHB to become widely deployed, it is important that
	incentives are aligned correctly, i.e., that there is a benefit to		incentives are aligned correctly, i.e., that there is a benefit to
	the application in marking its packets correctly and a disadvantage		the application in marking its packets correctly and a disadvantage
	(or at least no benefit) to an application in intentionally mis-		(or at least no benefit) to an application in intentionally mis-
	marking its traffic. Thus, a useful property of nodes (i.e., network		marking its traffic. Thus, a useful property of nodes (i.e., network
	switches and routers) that support separate queues for NQB and QB		switches and routers) that support separate queues for NQB and QB
	microflows is that for microflows consistent with the NQB sender		microflows is that each queue tends to be the better choice for the
	requirements in Section 4, the NQB queue would likely be a better		traffic it is designed for: the NQB queue for microflows consistent
	choice than the QB queue; and for microflows inconsistent with those		with the NQB sender requirements in Section 4 and the QB queue for
	requirements, the QB queue would likely be a better choice than the		those that are not. By adhering to these principles, there is little
	NQB queue. By adhering to these principles, there is little
	incentive for senders to mis-mark their traffic as NQB.		incentive for senders to mis-mark their traffic as NQB.
	This principle of incentive alignment ensures a system is robust to		This principle of incentive alignment ensures a system is robust to
	the behavior of the large majority of individuals and organizations		the behavior of the large majority of individuals and organizations
	who can be expected to act in their own interests (including		who can be expected to act in their own interests (including
	application developers and service providers who act in the interests		application developers and service providers who act in the interests
	of their users). Malicious behavior is not necessarily based on		of their users). Malicious behavior is not necessarily based on
	rational self-interest, so incentive alignment is not a sufficient		rational self-interest, so incentive alignment is not a sufficient
	defense, but the large majority of users do not act out of malice.		defense, but the large majority of users do not act out of malice.
	Protection against malicious attacks (and accidents) is addressed in		Protection against malicious attacks (and accidents) is addressed in
	skipping to change at line 526 ¶		skipping to change at line 526 ¶
	could be considered less problematic than the reverse. That said,		could be considered less problematic than the reverse. That said,
	providing a higher-than-needed NQB scheduler weight does increase the		providing a higher-than-needed NQB scheduler weight does increase the
	likelihood that a non-compliant microflow mis-marked as NQB is able		likelihood that a non-compliant microflow mis-marked as NQB is able
	to use more than its fair share of network capacity. NQB microflows		to use more than its fair share of network capacity. NQB microflows
	are expected to each consume no more than 1% of the link capacity,		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)		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.		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		Thus, 50% seems a reasonable upper bound on the weight for the NQB
	PHB in these environments.		PHB in these environments.
	By default, a node supporting the NQB PHB SHOULD by classify packets		By default, a node supporting the NQB PHB SHOULD classify packets
	marked with the NQB DSCP 45 (decimal) into the queue for NQB traffic.		marked with the DSCP value 45 (decimal) into the queue for NQB
	In accordance with the requirement in Section 3 of [RFC2474], a node		traffic. In accordance with the requirement in Section 3 of
	supporting the NQB PHB MUST support the ability to configure the DSCP		[RFC2474], a node supporting the NQB PHB MUST support the ability to
	that is used to classify packets into the queue for NQB traffic. A		configure the DSCP that is used to classify packets into the queue
	node supporting the NQB PHB MAY support the ability to configure		for NQB traffic. A node supporting the NQB PHB MAY support the
	multiple DSCPs that are used to classify packets into the queue for		ability to configure multiple DSCPs that are used to classify packets
	NQB traffic.		into the queue for NQB traffic.
	Support for the NQB PHB is advantageous at bottleneck nodes. Many		Support for the NQB PHB is advantageous at bottleneck nodes. Many
	bottleneck nodes have a relatively deep buffer for Default traffic		bottleneck nodes have a relatively deep buffer for Default traffic
	(e.g., roughly equal to the base RTT of the expected connections,		(e.g., roughly equal to the base RTT of the expected connections,
	which could be tens or hundreds of milliseconds). Providing a		which could be tens or hundreds of milliseconds). Providing a
	similarly deep buffer for the NQB queue would be at cross purposes to		similarly deep buffer for the NQB queue would be at cross purposes to
	providing very low queueing delay and would erode the incentives for		providing very low queueing delay and would erode the incentives for
	QB traffic to be marked correctly at such a bottleneck node. The NQB		QB traffic to be marked correctly at such a bottleneck node. The NQB
	queue MUST have a buffer size that is significantly smaller than the		queue MUST have a buffer size that is significantly smaller than the
	buffer provided for Default traffic. It is RECOMMENDED to configure		buffer provided for Default traffic. It is RECOMMENDED to configure
	skipping to change at line 643 ¶		skipping to change at line 643 ¶
	service in the absence of a traffic protection function needs to be		service in the absence of a traffic protection function needs to be
	considered. This is the motivation for the "SHOULD" requirement to		considered. This is the motivation for the "SHOULD" requirement to
	support traffic protection (in the previous paragraph). An NQB PHB		support traffic protection (in the previous paragraph). An NQB PHB
	implementation that does not support traffic protection risks being		implementation that does not support traffic protection risks being
	limited to deployment situations where traffic protection is		limited to deployment situations where traffic protection is
	potentially not necessary. One example of such a situation could be		potentially not necessary. One example of such a situation could be
	a controlled environment (e.g., enterprise LAN) where a network		a controlled environment (e.g., enterprise LAN) where a network
	administrator is expected to manage the usage of DSCPs.		administrator is expected to manage the usage of DSCPs.
	As it is defined here, traffic protection differs from Traffic		As it is defined here, traffic protection differs from Traffic
	Conditioning implemented in other DS contexts. Traffic Conditioning		Conditioning implemented in other Diffserv contexts. Traffic
	is commonly performed at the edge of a DS domain (either ingress or		Conditioning is commonly performed at the edge of a DS domain (either
	egress, depending on Traffic Conditioning Agreements (TCAs) in		ingress or egress, depending on Traffic Conditioning Agreements
	place). In contrast, traffic protection is intended to be		(TCAs) in place). In contrast, traffic protection is intended to be
	implemented in the nodes that implement the PHB. By placing the		implemented in the nodes that implement the PHB. By placing the
	traffic protection at the PHB node, an implementation can monitor 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.		actual NQB queue and take action only if a queue begins to form.
	Implementation of traffic protection at PHB nodes that are most		Implementation of traffic protection at PHB nodes that are most
	likely to be a bottleneck is particularly important because these are		likely to be a bottleneck is particularly important because these are
	the nodes that would be expected to show the most queue buildup in		the nodes that would be expected to show the most queue buildup in
	the presence of QB traffic mis-marked as NQB.		the presence of QB traffic mis-marked as NQB.
	This specification does not mandate a particular algorithm for		This specification does not mandate a particular algorithm for
	traffic protection. This is intentional since this will probably be		traffic protection. This is intentional since this will probably be
	skipping to change at line 773 ¶		skipping to change at line 773 ¶
	3. A downstream bottleneck that implements the NQB PHB could have		3. A downstream bottleneck that implements the NQB PHB could have
	implemented a traffic protection mechanism (Section 5.2) that		implemented a traffic protection mechanism (Section 5.2) that
	responds to queuing delay by re-marking/reclassifying/dropping		responds to queuing delay by re-marking/reclassifying/dropping
	packets. Bursty arrivals caused by an upstream link could		packets. Bursty arrivals caused by an upstream link could
	introduce queuing delay in the NQB queue and these would be more		introduce queuing delay in the NQB queue and these would be more
	likely to be subjected to traffic protection effects.		likely to be subjected to traffic protection effects.
	This document does not set any quantified requirements for links to		This document does not set any quantified requirements for links to
	limit bursts; this is primarily because link technologies are outside		limit bursts; this is primarily because link technologies are outside
	the remit of DS specifications. However, it would not seem necessary		the remit of Diffserv specifications. However, it would not seem
	to limit bursts lower than roughly 10% of the minimum base RTT		necessary to limit bursts lower than roughly 10% of the minimum base
	expected in the typical deployment scenario (e.g., 250 µs burst		RTT expected in the typical deployment scenario (e.g., 250 µs burst
	duration for links within the public Internet). This observation		duration for links within the public Internet). This observation
	aligns with a similar one in Section 5.5 of [RFC9331].		aligns with a similar one in Section 5.5 of [RFC9331].
	5.4. Treatment of the Explicit Congestion Notification Field		5.4. Treatment of the Explicit Congestion Notification Field
	NQB network functions MUST treat packets marked with the NQB DSCP		NQB network functions MUST treat packets marked with the NQB DSCP
	uniformly, regardless of the value of the ECN field. Here, the term		uniformly, regardless of the value of the ECN field. Here, the term
	"NQB network functions" refers to the traffic protection function		"NQB network functions" refers to the traffic protection function
	(defined in Section 5.2) and any re-marking/traffic policing function		(defined in Section 5.2) and any re-marking/traffic policing function
	designed to protect unmanaged networks (as described in		designed to protect unmanaged networks (as described in
	skipping to change at line 803 ¶		skipping to change at line 803 ¶
	unmanaged and inter-network scenarios. Additionally, Section 6.2		unmanaged and inter-network scenarios. Additionally, Section 6.2
	contains configuration recommendations for nodes that do not support		contains configuration recommendations for nodes that do not support
	the NQB PHB. Section 6.4.1 contains configuration recommendations		the NQB PHB. Section 6.4.1 contains configuration recommendations
	for networks that interconnect with non-DS-capable domains.		for networks that interconnect with non-DS-capable domains.
	6.1. NQB Traffic Identification		6.1. NQB Traffic Identification
	As required in Section 5, nodes supporting the NQB PHB provide for		As required in Section 5, nodes supporting the NQB PHB provide for
	the configuration of classifiers that can be used to differentiate		the configuration of classifiers that can be used to differentiate
	between QB and NQB traffic of equivalent importance. The assigned		between QB and NQB traffic of equivalent importance. The assigned
	NQB DSCP (45 decimal) is recommended for use as the default		NQB DSCP value (45 decimal) is recommended for use as the default
	classifier to distinguish NQB traffic from traffic classified as		classifier to distinguish NQB traffic from traffic classified as
	Default (DSCP 0) (see Sections 4 and 5.1).		Default (DSCP 0) (see Sections 4 and 5.1).
	6.2. Aggregation of the NQB DSCP into Another DS PHB		6.2. Aggregation of the NQB DSCP into Another Diffserv PHB
	It is RECOMMENDED that networks and nodes that do not support the NQB		It is RECOMMENDED that networks and nodes that do not support the NQB
	PHB be configured to treat traffic marked with the NQB DSCP the same		PHB be configured to treat traffic marked with the NQB DSCP the same
	as traffic with the Default DSCP. This includes networks (such as		as traffic with the Default DSCP. This includes networks (such as
	MPLS) and nodes that aggregate service classes as discussed in		MPLS) and nodes that aggregate service classes as discussed in
	[RFC5127] and [RFC8100]; in this case, this recommendation would		[RFC5127] and [RFC8100]; in this case, this recommendation would
	result in traffic marked with the NQB DSCP being aggregated into the		result in traffic marked with the NQB DSCP being aggregated into the
	Elastic Treatment Aggregate (for networks as described in [RFC5127])		Elastic Treatment Aggregate (for networks as described in [RFC5127])
	or the Default / Elastic Treatment Aggregate (for networks as		or the Default / Elastic Treatment Aggregate (for networks as
	described in [RFC8100]).		described in [RFC8100]).
	skipping to change at line 847 ¶		skipping to change at line 847 ¶
	Aggregating traffic marked with the NQB DSCP into a PHB designed for		Aggregating traffic marked with the NQB DSCP into a PHB designed for
	real-time, delay-sensitive traffic (e.g., the Real-Time Treatment		real-time, delay-sensitive traffic (e.g., the Real-Time Treatment
	Aggregate [RFC5127] or the Bulk Real-Time Treatment Aggregate		Aggregate [RFC5127] or the Bulk Real-Time Treatment Aggregate
	[RFC8100]), might better preserve the loss, delay, and delay-		[RFC8100]), might better preserve the loss, delay, and delay-
	variation performance in the presence of congestion; however, it		variation performance in the presence of congestion; however, it
	would need to be done with consideration of the risk of creating an		would need to be done with consideration of the risk of creating an
	incentive for non-compliant traffic to be mis-marked as NQB.		incentive for non-compliant traffic to be mis-marked as NQB.
	6.3. Aggregation of Other DSCPs into the NQB PHB		6.3. Aggregation of Other DSCPs into the NQB PHB
	The DS model provides flexibility for operators to control the way		The Diffserv model provides flexibility for operators to control the
	they choose to aggregate traffic marked with a specific DSCP.		way they choose to aggregate traffic marked with a specific DSCP.
	Operators of nodes that support the NQB PHB could choose to aggregate		Operators of nodes that support the NQB PHB could choose to aggregate
	other service classes into the NQB queue. This is particularly		other service classes into the NQB queue. This is particularly
	useful in cases where specialized PHBs for these other service		useful in cases where specialized PHBs for these other service
	classes had not been provided at a potential bottleneck, perhaps		classes had not been provided at a potential bottleneck, perhaps
	because it was too complex to manage traffic contracts and		because it was too complex to manage traffic contracts and
	conditioning. Candidate service classes for this aggregation would		conditioning. Candidate service classes for this aggregation would
	include those that carry low-data-rate inelastic traffic that has low		include those that carry low-data-rate inelastic traffic that has low
	to very-low tolerance for loss, delay, and/or delay variation.		to very-low tolerance for loss, delay, and/or delay variation.
	Operators would need to use their own judgment based on the actual		Operators would need to use their own judgment based on the actual
	traffic characteristics in their networks in deciding whether or not		traffic characteristics in their networks in deciding whether or not
	skipping to change at line 890 ¶		skipping to change at line 890 ¶
	used within a DS domain (e.g., an Autonomous System (AS) or an		used within a DS domain (e.g., an Autonomous System (AS) or an
	enterprise network), this PHB is expected to be used across the		enterprise network), this PHB is expected to be used across the
	Internet, wherever suitable operator agreements apply. Under the		Internet, wherever suitable operator agreements apply. Under the
	model described in [RFC2474], this requires that the corresponding		model described in [RFC2474], this requires that the corresponding
	DSCP is recognized and mapped across network boundaries accordingly.		DSCP is recognized and mapped across network boundaries accordingly.
	If NQB support is extended across a DS domain boundary, the		If NQB support is extended across a DS domain boundary, the
	interconnected networks agreeing to support NQB SHOULD use the DSCP		interconnected networks agreeing to support NQB SHOULD use the DSCP
	value 45 (decimal) for NQB at network interconnection, unless a		value 45 (decimal) for NQB at network interconnection, unless a
	different DSCP is explicitly documented in the TCA (see [RFC2475])		different DSCP is explicitly documented in the TCA (see [RFC2475])
	for that interconnection. If Section 4 of [RFC8100] is operational		for that interconnection. If a Diffserv-Intercon Interconnection
	between interconnected domains, the receiving domain may prefer a		Class (see Section 4 of [RFC8100]) is operational between
	different DSCP for NQB traffic that allows for a DSCP range-based		interconnected domains, the receiving domain may prefer a different
			DSCP for NQB traffic that allows for a DSCP range-based
	classification for the Default / Elastic Treatment Aggregate.		classification for the Default / Elastic Treatment Aggregate.
	Similar to the handling of DSCPs for other PHBs (and as discussed in		Similar to the handling of DSCPs for other PHBs (and as discussed in
	[RFC2475]), networks can re-mark NQB traffic to a DSCP value other		[RFC2475]), networks can re-mark NQB traffic to a DSCP value other
	than 45 (decimal) for internal usage. To ensure reliable NQB PHB		than 45 (decimal) for internal usage. To ensure reliable NQB PHB
	treatment on the entire path, the appropriate NQB DSCP would need to		treatment on the entire path, the appropriate NQB DSCP would need to
	be restored when forwarding to another network.		be restored when forwarding to another network.
	6.4.1. Interoperability with Non-DS-Capable Domains		6.4.1. Interoperability with Non-DS-Capable Domains
	As discussed in Section 4 of [RFC2475], there may be cases where a		As discussed in Section 4 of [RFC2475], there may be cases where a
	network operator that supports DS is delivering traffic to another		network operator that supports Diffserv is delivering traffic to
	network domain (e.g., a network outside of their administrative		another network domain (e.g., a network outside of their
	control) where there is an understanding that the downstream domain		administrative control) where there is an understanding that the
	does not support DS or there is no knowledge of the traffic		downstream domain does not support Diffserv or there is no knowledge
	management capabilities of the downstream domain, and no agreement in		of the traffic management capabilities of the downstream domain, and
	place. In such cases, Section 4 of [RFC2475] suggests that the		no agreement in place. In such cases, Section 4 of [RFC2475]
	upstream domain opportunistically re-mark traffic with a Class		suggests that the upstream domain opportunistically re-mark traffic
	Selector Codepoint or DSCP 0 (Default) under the assumption that		with a Class Selector Codepoint or DSCP 0 (Default) under the
	traffic so marked would be handled in a predictable way by the		assumption that traffic so marked would be handled in a predictable
	downstream domain.		way by the downstream domain.
	In the case of a network that supports the NQB PHB (and carries		In the case of a network that supports the NQB PHB (and carries
	traffic marked with the recommended NQB DSCP value), the same		traffic marked with the recommended DSCP value 45 (decimal)), the
	concerns apply. In particular, since the recommended NQB DSCP value		same concerns apply. In particular, since the recommended NQB DSCP
	could be given high priority in some non-DS-compliant network		value 45 (decimal) could be given high priority in some non-DS-
	equipment (e.g., legacy Wi-Fi APs as described in Section 7.3.1), it		compliant network equipment (e.g., legacy Wi-Fi APs as described in
	is RECOMMENDED that the operator of the upstream domain implement one		Section 7.3.1), it is RECOMMENDED that the operator of the upstream
	of the following safeguards before delivering traffic into a non-DS-		domain implement one of the following safeguards before delivering
	capable domain:		traffic into a non-DS-capable domain:
	1. One option for such a safeguard is to re-mark NQB traffic to DSCP		1. One option for such a safeguard is to re-mark NQB traffic to DSCP
	0 (Default) (or another Class Selector DSCP) before delivering		0 (Default) (or another Class Selector DSCP) before delivering
	traffic into a non-DS-capable domain, in accordance with the		traffic into a non-DS-capable domain, in accordance with the
	suggestion in Section 4 of [RFC2475]. Network equipment designed		suggestion in Section 4 of [RFC2475]. Network equipment designed
	for such environments SHOULD, by default, re-mark NQB traffic to		for such environments SHOULD, by default, re-mark NQB traffic to
	DSCP 0 (Default) and SHOULD support the ability to change and		DSCP 0 (Default) and SHOULD support the ability to change and
	disable this re-marking. Re-marking NQB traffic to DSCP 0		disable this re-marking. Re-marking NQB traffic to DSCP 0
	(Default) could be considered the "safest" approach since the		(Default) could be considered the "safest" approach since the
	upstream domain can thereby ensure that NQB traffic is not given		upstream domain can thereby ensure that NQB traffic is not given
	skipping to change at line 1117 ¶		skipping to change at line 1118 ¶
	[IEEE802-11] generally supports either four or eight transmit queues		[IEEE802-11] generally supports either four or eight transmit queues
	and four sets of associated EDCA parameters (corresponding to the		and four sets of associated EDCA parameters (corresponding to the
	four Wi-Fi Multimedia (WMM) Access Categories) that are used to		four Wi-Fi Multimedia (WMM) Access Categories) that are used to
	enable differentiated medium access characteristics. The four WMM		enable differentiated medium access characteristics. The four WMM
	Access Categories, referred to as Voice Access Category (AC_VO),		Access Categories, referred to as Voice Access Category (AC_VO),
	Video Access Category (AC_VI), Best Effort Access Category (AC_BE),		Video Access Category (AC_VI), Best Effort Access Category (AC_BE),
	and Background Access Category (AC_BK), provide four levels of		and Background Access Category (AC_BK), provide four levels of
	prioritized access to the wireless medium. As discussed in		prioritized access to the wireless medium. As discussed in
	[RFC8325], it has been a common practice for Wi-Fi implementations to		[RFC8325], it has been a common practice for Wi-Fi implementations to
	use a default DSCP to User Priority (UP) mapping that utilizes the		use a default DSCP to User Priority (UP) mapping that utilizes the
	most significant three bits of the DS field to select "User		most significant three bits of the DSCP field to select "User
	Priority", which is then mapped to the four WMM Access Categories.		Priority", which is then mapped to the four WMM Access Categories.
	[RFC8325] also provides an alternative mapping that more closely		[RFC8325] also provides an alternative mapping that more closely
	aligns with the DSCP recommendations provided by the IETF. In the		aligns with the DSCP recommendations provided by the IETF. In the
	case of some managed Wi-Fi equipment, this mapping can be controlled		case of some managed Wi-Fi equipment, this mapping can be controlled
	by the network operator, e.g., via TR-369 [TR-369].		by the network operator, e.g., via TR-369 [TR-369].
	In addition to the requirements provided in other sections of this		In addition to the requirements provided in other sections of this
	document, to support the NQB PHB, Wi-Fi equipment (including		document, to support the NQB PHB, Wi-Fi equipment (including
	equipment compliant with [RFC8325]) SHOULD map the NQB DSCP 45		equipment compliant with [RFC8325]) SHOULD map the DSCP value 45
	(decimal) into a separate queue in the same Access Category as the		(decimal) into a separate queue in the same Access Category as the
	queue that carries Default traffic (i.e., the Best Effort Access		queue that carries Default traffic (i.e., the Best Effort Access
	Category). It is RECOMMENDED that Wi-Fi equipment provide a separate		Category). It is RECOMMENDED that Wi-Fi equipment provide a separate
	queue in UP 0 and map the NQB DSCP 45 (decimal) to that queue. If a		queue in UP 0 and map the DSCP value 45 (decimal) to that queue. If
	separate queue in UP 0 cannot be provided (due to hardware		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)		limitations, etc.), a Wi-Fi device MAY map the DSCP value 45
	to UP 3.		(decimal) to UP 3.
	7.3.1. Interoperability with Existing Wi-Fi Networks		7.3.1. Interoperability with Existing Wi-Fi Networks
	While some existing Wi-Fi equipment might be capable (in some cases		While some existing Wi-Fi equipment might be capable (in some cases
	via firmware update) of supporting the NQB PHB requirements, many		via firmware update) of supporting the NQB PHB requirements, many
	currently deployed devices cannot be configured in this way. As a		currently deployed devices cannot be configured in this way. As a
	result, the remainder of this section discusses interoperability with		result, the remainder of this section discusses interoperability with
	these existing Wi-Fi networks, as opposed to PHB compliance.		these existing Wi-Fi networks, as opposed to PHB compliance.
	Since this equipment is widely deployed, and the Wi-Fi link can		Since this equipment is widely deployed, and the Wi-Fi link can
	skipping to change at line 1166 ¶		skipping to change at line 1167 ¶
	equal to that used for Default traffic (Section 5.1)		equal to that used for Default traffic (Section 5.1)
	The DSCP value 45 (decimal) is recommended for NQB (see Section 4).		The DSCP value 45 (decimal) is recommended for NQB (see Section 4).
	This maps NQB to UP 5 using the default mapping, which is in the		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		Video Access Category. While this choice of DSCP enables these Wi-Fi
	systems to support the NQB PHB requirement for separate queuing,		systems to support the NQB PHB requirement for separate queuing,
	existing Wi-Fi devices generally utilize EDCA parameters that result		existing Wi-Fi devices generally utilize EDCA parameters that result
	in statistical prioritization of the Video Access Category above the		in statistical prioritization of the Video Access Category above the
	Best Effort Access Category. In addition, this equipment does not		Best Effort Access Category. In addition, this equipment does not
	support the remaining NQB PHB recommendations in Section 5. The		support the remaining NQB PHB recommendations in Section 5. The
	rationale for the choice of DSCP 45 (decimal) as well as its		rationale for the choice of DSCP value 45 (decimal) as well as its
	ramifications and remedies for its limitations are discussed further		ramifications and remedies for its limitations are discussed further
	below.		below.
	The choice of separated queuing rather than equal forwarding		The choice of separated queuing rather than equal forwarding
	preference in existing Wi-Fi networks was motivated by the following:		preference in existing Wi-Fi networks was motivated by the following:
	* Separate queuing is necessary in order to provide a benefit for		* Separate queuing is necessary in order to provide a benefit for
	traffic marked with the NQB DSCP.		traffic marked with the NQB DSCP.
	* The arrangement of queues in Wi-Fi equipment is typically fixed,		* The arrangement of queues in Wi-Fi equipment is typically fixed,
	skipping to change at line 1201 ¶		skipping to change at line 1202 ¶
	* Several existing client applications that are compatible with the		* Several existing client applications that are compatible with the
	NQB sender requirements already select the Video Access Category;		NQB sender requirements already select the Video Access Category;
	thus, they would not see a degradation in performance by		thus, they would not see a degradation in performance by
	transitioning to the NQB DSCP, regardless of whether the network		transitioning to the NQB DSCP, regardless of whether the network
	supported the PHB.		supported the PHB.
	* Application instances on Wi-Fi client devices are already free to		* Application instances on Wi-Fi client devices are already free to
	choose any Access Category that they wish, regardless of their		choose any Access Category that they wish, regardless of their
	sending behavior, without any policing of usage. So, the choice		sending behavior, without any policing of usage. So, the choice
	of using DSCP 45 (decimal) for NQB creates no new avenues for non-		of using DSCP value 45 (decimal) for NQB creates no new avenues
	NQB-compliant client applications to exploit the prioritization		for non-NQB-compliant client applications to exploit the
	function in Wi-Fi.		prioritization function in Wi-Fi.
	* For application traffic that originates outside of the Wi-Fi		* For application traffic that originates outside of the Wi-Fi
	network, and, thus, is transmitted by the Access Point, the choice		network, and, thus, is transmitted by the Access Point, the choice
	of DSCP 45 does create a potential for abuse by non-compliant		of DSCP value 45 (decimal) does create a potential for abuse by
	applications. However, opportunities exist in the network		non-compliant applications. However, opportunities exist in the
	components upstream of the Wi-Fi Access Point to police the usage		network components upstream of the Wi-Fi Access Point to police
	of the NQB DSCP and potentially re-mark traffic that is considered		the usage of the NQB DSCP and potentially re-mark traffic that is
	non-compliant, as is recommended in Section 6.4.1. Furthermore,		considered non-compliant, as is recommended in Section 6.4.1.
	it is reasonable to expect that ISPs currently manage the DSCPs on		Furthermore, it is reasonable to expect that ISPs currently manage
	traffic destined to their customers' networks and will continue to		the DSCPs on traffic destined to their customers' networks and
	do so whether or not they support NQB. This includes the practice		will continue to do so whether or not they support NQB. This
	in residential broadband networks of re-marking the DS field to		includes the practice in residential broadband networks of re-
	zero on all traffic. Any change to these practices done to enable		marking the DSCP field to zero on all traffic. Any change to
	the NQB DSCP to pass through could be done alongside the		these practices done to enable the NQB DSCP to pass through could
	implementation of the recommendations in Section 6.4.1.		be done alongside the implementation of the recommendations in
			Section 6.4.1.
	The choice of Video Access Category rather than the Voice Access		The choice of Video Access Category rather than the Voice Access
	Category was motivated by the desire to minimize the potential for		Category was motivated by the desire to minimize the potential for
	degradation of Best Effort Access Category traffic. The choice of		degradation of Best Effort Access Category traffic. The choice of
	Video Access Category rather than the Background Access Category was		Video Access Category rather than the Background Access Category was
	motivated by the much greater potential of degradation to NQB traffic		motivated by the much greater potential of degradation to NQB traffic
	that would be caused by the vast majority of traffic in most Wi-Fi		that would be caused by the vast majority of traffic in most Wi-Fi
	networks, which utilizes the Best Effort Access Category.		networks, which utilizes the Best Effort Access Category.
	As stated above, the use of DSCP 45 (decimal) for NQB is not expected		As stated above, the use of DSCP value 45 (decimal) for NQB is not
	to create incentives for abuse by non-compliant applications in the		expected to create incentives for abuse by non-compliant applications
	Wi-Fi uplink direction. The fact that the NQB DSCP brings with it		in the Wi-Fi uplink direction. The fact that the NQB DSCP brings
	the potential for degradation of non-compliant applications (traffic		with it the potential for degradation of non-compliant applications
	protection and/or a shallow queue resulting in reordering and/or		(traffic protection and/or a shallow queue resulting in reordering
	packet loss at some hop along the path) plus the existence of		and/or packet loss at some hop along the path) plus the existence of
	multiple other DSCP values that don't carry the risk of degradation		multiple other DSCP values that don't carry the risk of degradation
	and that could be readily used to obtain prioritization (AC_VI or		and that could be readily used to obtain prioritization (AC_VI or
	even AC_VO) leads to the conclusion that NQB non-compliant		even AC_VO) leads to the conclusion that NQB non-compliant
	applications that are seeking prioritization in the Wi-Fi uplink		applications that are seeking prioritization in the Wi-Fi uplink
	would be better off selecting one of those other DSCPs. This		would be better off selecting one of those other DSCPs. This
	conclusion is not expected to be disturbed by network support for NQB		conclusion is not expected to be disturbed by network support for NQB
	increasing the likelihood of DSCP 45 traffic traversing network		increasing the likelihood of DSCP value 45 (decimal) traffic
	boundaries without change to the DSCP, as that likelihood of		traversing network boundaries without change to the DSCP, as that
	increased network boundary traversal is balanced by a likelihood of		likelihood of increased network boundary traversal is balanced by a
	NQB traffic encountering the traffic-limiting aspects of NQB support,		likelihood of NQB traffic encountering the traffic-limiting aspects
	traffic protection, and shallow buffers, which limit the potential		of NQB support, traffic protection, and shallow buffers, which limit
	for abuse.		the potential for abuse.
	In the case of traffic originating outside of the Wi-Fi network, the		In the case of traffic originating outside of the Wi-Fi network, the
	prioritization of traffic marked with the NQB DSCP via the Video		prioritization of traffic marked with the NQB DSCP via the Video
	Access Category (if left unchanged) could potentially erode the		Access Category (if left unchanged) could potentially erode the
	principle of alignment of incentives discussed in Section 5. In		principle of alignment of incentives discussed in Section 5. In
	order to preserve the incentives principle for NQB, Wi-Fi systems MAY		order to preserve the incentives principle for NQB, Wi-Fi systems MAY
	be configured such that the EDCA parameters for the Video Access		be configured such that the EDCA parameters for the Video Access
	Category match those of the Best Effort Access Category, which will		Category match those of the Best Effort Access Category, which will
	mean AC_VI is at the same priority level as AC_BE. These changes		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, the		might not be possible on all Access Points; in any case, the
	requirements and recommendations in Section 6.4.1 would apply in this		requirements and recommendations in Section 6.4.1 would apply in this
	situation.		situation.
	Systems that utilize [RFC8325] but cannot provide a separate AC_BE		Systems that utilize [RFC8325] but cannot provide a separate AC_BE
	queue for NQB traffic SHOULD map the NQB DSCP 45 (decimal) (or the		queue for NQB traffic SHOULD map the DSCP value 45 (decimal) (or the
	locally determined alternative) to UP 5 in the Video Access Category		locally determined alternative) to UP 5 in the Video Access Category
	as well (see Section 7.3.2).		as well (see Section 7.3.2).
	7.3.2. The Updates to RFC 8325		7.3.2. The Updates to RFC 8325
	Section 4.2.9 of [RFC8325] describes the recommendation for the		Section 4.2.9 of [RFC8325] describes the recommendation for the
	handling of Standard service class traffic that carries the Default		handling of Standard service class traffic that carries the Default
	DSCP. This update to [RFC8325] changes the title of Section 4.2.9 of		DSCP. This update to [RFC8325] changes the title of Section 4.2.9 of
	[RFC8325] from "Standard" to "Standard and Non-Queue-Building". This		[RFC8325] from "Standard" to "Standard and Non-Queue-Building". This
	update additionally adds a paragraph at the end of Section 4.2.9 of		update additionally adds a paragraph at the end of Section 4.2.9 of
	[RFC8325] as follows:		[RFC8325] as follows:
	| RFC 9956 defines a shallow-buffered, best-effort service for		| RFC 9956 defines a shallow-buffered, best-effort service for
	| traffic marked with the NQB DSCP 45 (decimal) and recommends the		| traffic described as Non-Queue-Building and recommends the
	| following treatment in Wi-Fi equipment. It is RECOMMENDED that		| following treatment in Wi-Fi equipment. It is RECOMMENDED that
	| Wi-Fi equipment map the NQB DSCP 45 (decimal) into a separate		| Wi-Fi equipment map Non-Queue-Building traffic into a separate
	| queue in the same Access Category as the queue that carries		| queue in the same Access Category as the queue that carries
	| Default traffic (i.e., the Best Effort Access Category). It is		| Default traffic (i.e., the Best Effort Access Category). It is
	| RECOMMENDED that Wi-Fi equipment provide a separate queue in UP 0		| RECOMMENDED that Wi-Fi equipment provide a separate queue in UP 0
	| and map the NQB DSCP 45 (decimal) to that queue. If a separate		| and map Non-Queue-Building traffic to that queue. If a separate
	| queue in UP 0 cannot be provided (due to hardware limitations,		| 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.		| etc.), a Wi-Fi device MAY map Non-Queue-Building traffic to UP 3.
	| If neither of these options provides a separate queue from Default		| If neither of these options provides a separate queue from Default
	| traffic, it is RECOMMENDED that Wi-Fi equipment map the NQB DSCP		| traffic, it is RECOMMENDED that Wi-Fi equipment map Non-Queue-
	| 45 (decimal) to UP 5 (which corresponds to the default mapping		| Building traffic to UP 5 (which corresponds to the default mapping
	| described in Section 2.3). RFC 9956 provides additional		| described in Section 2.3). RFC 9956 provides additional
	| recommendations and requirements for support of the NQB PHB that		| recommendations and requirements for support of the NQB PHB that
	| aren't available in the QoS model described in Section 6 but		| aren't available in the QoS model described in Section 6 but
	| nonetheless could be supported in implementations.		| nonetheless could be supported in implementations.
	In another update to [RFC8325] captured below, a new row for "Non-		In another update to [RFC8325] captured below, a new row for "Non-
	Queue-Building" traffic is inserted between the existing "Low-Latency		Queue-Building" traffic is inserted between the existing "Low-Latency
	Data" and "OAM" rows in Figure 1 of [RFC8325] as follows:		Data" and "OAM" rows in Figure 1 of [RFC8325] as follows:
	+===============+======+==========+==================================+		+===============+======+==========+==================================+
	| IETF Diffserv | PHB |Reference | IEEE 802.11 |		| IETF Diffserv | PHB |Reference | IEEE 802.11 |
	| Service Class | | RFC |User Priority| Access Category |		| Service Class | | RFC |User Priority| Access Category |
	|===============+======+==========+=============+====================|		|===============+======+==========+=============+====================|
			| ... | ... | ... | ... | ... |
			+---------------+------+----------+-------------+--------------------+
	| 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 9956 | 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)|
	+---------------+------+----------+-------------+--------------------+		+---------------+------+----------+-------------+--------------------+
	A third update adds the following sentence to the end of the first		A third update adds the following sentence to the end of the first
	paragraph in Section 5.3 of [RFC8325]:		paragraph in Section 5.3 of [RFC8325]:
	| An exception to this is the NQB DSCP 45 (decimal), which encodes		| An exception to this is the NQB DSCP value 45 (decimal), which
	| for best-effort service.		| encodes for best-effort service.
	8. IANA Considerations		8. IANA Considerations
	IANA has assigned the Differentiated Services Field Codepoint (DSCP)		IANA has assigned the Differentiated Services Field Codepoint (DSCP)
	45 from the "Differentiated Services Field Codepoints (DSCP)"		45 from the "Differentiated Services Field Codepoints (DSCP)"
	registry (https://www.iana.org/assignments/dscp-registry/) ("DSCP		registry (https://www.iana.org/assignments/dscp-registry/) ("DSCP
	Pool 3 Codepoints", Codepoint Space xxxx01, Standards Action		Pool 3 Codepoints", Codepoint Space xxxx01, Standards Action
	([RFC8126]) for NQB behavior.		([RFC8126]) for NQB behavior.
	IANA has updated this registry as follows:		IANA has updated this registry as follows:
	skipping to change at line 1390 ¶		skipping to change at line 1394 ¶
	shallow buffer) as intended motivates limiting the effects of shallow		shallow buffer) as intended motivates limiting the effects of shallow
	buffer overrun via per-user provisioning limits that prevent queue		buffer overrun via per-user provisioning limits that prevent queue
	overrun effects from affecting other users (see Section 5.1).		overrun effects from affecting other users (see Section 5.1).
	Notwithstanding the above, the choice of DSCP for NQB does allow		Notwithstanding the above, the choice of DSCP for NQB does allow
	existing Wi-Fi networks to readily (and by default) support some of		existing Wi-Fi networks to readily (and by default) support some of
	the PHB requirements, but without a traffic protection function, and		the PHB requirements, but without a traffic protection function, and
	(when left in the default state) by giving NQB traffic higher		(when left in the default state) by giving NQB traffic higher
	priority than QB traffic. This is not considered to be a compliant		priority than QB traffic. This is not considered to be a compliant
	implementation of the PHB. These existing Wi-Fi networks currently		implementation of the PHB. These existing Wi-Fi networks currently
	provide priority to half of the DSCP space, whether or not 45		provide priority to half of the DSCP space, whether or not the DSCP
	(decimal) is assigned to the NQB DSCP. While the NQB DSCP value		value 45 (decimal) is assigned to the NQB DSCP. While the DSCP value
	could also be abused to gain priority on such links, the potential		45 (decimal) could also be abused to gain priority on such links, the
	presence of traffic protection functions in other hops along the path		potential presence of traffic protection functions in other hops
	(which likely act on the NQB DSCP value alone) would make it less		along the path (which likely act on the DSCP value 45 (decimal)
	attractive for such abuse than any of the other 31 DSCP values that		alone) would make it less attractive for such abuse than any of the
	are given priority.		other 31 DSCP values that are given priority.
	This document discusses the potential use of the NQB DSCP and NQB PHB		This document discusses the potential use of the NQB DSCP and NQB PHB
	in network technologies that are standardized in other SDOs. Any		in network technologies that are standardized in other SDOs. Any
	security considerations that relate to deployment and operation of		security considerations that relate to deployment and operation of
	NQB solely in specific network technologies are not discussed here.		NQB solely in specific network technologies are not discussed here.
	NQB uses the DS field. The design of DS does not include integrity		NQB uses the DS field. The design of Diffserv does not include
	protection for the DSCP; thus, it is possible for the DSCP to be		integrity protection for the DSCP; thus, it is possible for the DSCP
	changed by an on-path attacker. The NQB PHB and associated DSCP		to be changed by an on-path attacker. The NQB PHB and associated
	don't change this. While re-marking DSCPs is permitted for various		DSCP don't change this. While re-marking DSCPs is permitted for
	reasons (some are discussed in this document, others can be found in		various reasons (some are discussed in this document, others can be
	[RFC2474] and [RFC2475]), if done maliciously, this might negatively		found in [RFC2474] and [RFC2475]), if done maliciously, this might
	affect the QoS of the tampered microflow. Nonetheless, an on-path		negatively affect the QoS of the tampered microflow. Nonetheless, an
	attacker can also alter other mutable fields in the IP header (e.g.,		on-path attacker can also alter other mutable fields in the IP header
	the TTL), which can wreak much more havoc than just altering QoS		(e.g., the TTL), which can wreak much more havoc than just altering
	treatment.		QoS treatment.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	skipping to change at line 1645 ¶		skipping to change at line 1649 ¶
	Amendment 4 Corrigendum 2, July 2025,		Amendment 4 Corrigendum 2, July 2025,
	<https://usp.technology/specification/index.html>.		<https://usp.technology/specification/index.html>.
	[WikipediaBufferbloat]		[WikipediaBufferbloat]
	Wikipedia, "Bufferbloat", May 2025,		Wikipedia, "Bufferbloat", May 2025,
	<https://en.wikipedia.org/w/		<https://en.wikipedia.org/w/
	index.php?title=Bufferbloat&oldid=1292250296>.		index.php?title=Bufferbloat&oldid=1292250296>.
	Appendix A. DSCP Re-marking Policies		Appendix A. DSCP Re-marking Policies
	Some network operators typically bleach (zero out) the DS field on		Some network operators typically bleach (zero out) the DSCP field on
	ingress into their network (see [RFC9435], [Custura], and [Barik])		ingress into their network (see [RFC9435], [Custura], and [Barik])
	and, in some cases, apply their own DSCP for internal use. Bleaching		and, in some cases, apply their own DSCP for internal use. Bleaching
	the NQB DSCP is not expected to cause harm to Default traffic, but it		the DSCP value 45 (decimal) is not expected to cause harm to Default
	will severely limit the ability to provide NQB treatment. Reports on		traffic, but it will severely limit the ability to provide NQB
	existing deployments of DSCP manipulation (see [Custura] and [Barik])		treatment. Reports on existing deployments of DSCP manipulation (see
	categorize the re-marking behaviors into the following policies:		[Custura] and [Barik]) categorize the re-marking behaviors into the
	bleach all traffic (set DSCP to zero); set the top three bits (the		following policies: bleach all traffic (set DSCP to zero); set the
	former Precedence bits) on all traffic to 0b000, 0b001, or 0b010; set		top three bits (the former Precedence bits) on all traffic to 0b000,
	the low three bits on all traffic to 0b000; or re-mark all traffic to		0b001, or 0b010; set the low three bits on all traffic to 0b000; or
	a particular (non-zero) DSCP value.		re-mark all traffic to a particular (non-zero) DSCP value.
	Regarding the DSCP value 45 (decimal), there were no observations of		Regarding the DSCP value 45 (decimal), there were no observations of
	DSCP manipulation reported in which traffic was marked 45 (decimal)		DSCP manipulation reported in which traffic was marked with the DSCP
	by any of these policies. Thus, it appears that these re-marking		value 45 (decimal) by any of these policies. Thus, it appears that
	policies would be unlikely to result in QB traffic being marked as		these re-marking policies would be unlikely to result in QB traffic
	NQB (45). In terms of the fate of traffic marked with the NQB DSCP		being marked as NQB. In terms of the fate of traffic marked with the
	that is subjected to one of these policies, it would be		DSCP value 45 (decimal) that is subjected to one of these policies,
	indistinguishable from some subset (possibly all) of other traffic.		it would be indistinguishable from some subset (possibly all) of
	In the policies where all traffic is re-marked using the same (zero		other traffic. In the policies where all traffic is re-marked using
	or non-zero) DSCP, the ability for a subsequent network hop to		the same (zero or non-zero) DSCP value, the ability for a subsequent
	differentiate NQB traffic via DSCP would clearly be lost entirely.		network hop to differentiate NQB traffic via DSCP would clearly be
			lost entirely.
	In the policies where the top three bits are overwritten (see		In the policies where the top three bits are overwritten (see
	Section 4.2 of [RFC9435]), the NQB DSCP (45) would receive the same		Section 4.2 of [RFC9435]), the DSCP value 45 (decimal) would receive
	marking as would the currently unassigned Pool 3 DSCPs (5, 13, 21,		the same marking as would the currently unassigned Pool 3 DSCP values
	29, 37, 53, and 61), with all of these DSCPs getting re-marked to		(5, 13, 21, 29, 37, 53, and 61), with all of these DSCP values
	DSCP = 5, 13, or 21 (depending on the overwrite value used). Since		getting re-marked to DSCP value = 5, 13, or 21 (depending on the
	none of the DSCPs in the preceding lists are currently assigned by		overwrite value used). Since none of the DSCP values in the
	IANA, and they all are reserved for Standards Action, it is believed		preceding lists are currently assigned by IANA, and they all are
	that they are not widely used currently; however, this could vary		reserved for Standards Action, it is believed that they are not
	based on local-usage and could change in the future. If networks in		widely used currently; however, this could vary based on local-usage
	which this sort of re-marking occurs or networks downstream classify		and could change in the future. If networks in which this sort of
	the resulting DSCP (i.e., 5, 13, or 21) to the NQB PHB or re-mark		re-marking occurs or networks downstream classify the resulting DSCP
	such traffic as 45 (decimal), they risk giving NQB treatment to other		(i.e., 5, 13, or 21) to the NQB PHB or re-mark such traffic with DSCP
	traffic that was not originally marked as NQB. In addition, as		value 45 (decimal), they risk giving NQB treatment to other traffic
	described in Section 6 of [RFC9435] future assignments of these		that was not originally marked as NQB. In addition, as described in
	0bxxx101 DSCPs would need to be made with consideration of the		Section 6 of [RFC9435] future assignments of these 0bxxx101 DSCPs
	potential that they all are treated as NQB in some networks.		would need to be made with consideration of the potential that they
			all are treated as NQB in some networks.
	For the policy in which the low three bits are set to 0b000, the NQB		For the policy in which the low three bits are set to 0b000, the DSCP
	DSCP value 45 (decimal) would be re-marked to CS5 and would be		value 45 (decimal) would be re-marked to CS5 and would be
	indistinguishable from CS5, VA, and EF (and the currently unassigned		indistinguishable from CS5, VA, and EF (and the currently unassigned
	DSCPs 41, 42, and 43). Traffic marked using the existing		DSCP values 41, 42, and 43). Traffic marked using the existing
	standardized DSCPs in this list are likely to share the same general		standardized DSCPs in this list are likely to share the same general
	properties as NQB traffic (non-capacity-seeking and very low data		properties as NQB traffic (non-capacity-seeking and very low data
	rate, relatively low data rate, and consistent data rate).		rate, relatively low data rate, and consistent data rate).
	Similarly, any future recommended usage for DSCPs 41, 42, 43 would		Similarly, any future recommended usage for DSCP values 41, 42, 43
	likely be somewhat compatible with NQB treatment, assuming that IP		would likely be somewhat compatible with NQB treatment, assuming that
	Precedence compatibility (see Section 1.5.4 of [RFC4594]) is		IP Precedence compatibility (see Section 1.5.4 of [RFC4594]) is
	maintained in the future. Here there might be an opportunity for a		maintained in the future. Here there might be an opportunity for a
	node to provide the NQB PHB or the CS5 PHB to CS5-marked traffic and		node to provide the NQB PHB or the CS5 PHB to CS5-marked traffic and
	retain some of the benefits of NQB marking. This could be another		retain some of the benefits of NQB marking. This could be another
	motivation to classify CS5-marked traffic into the NQB queue (as		motivation to classify CS5-marked traffic into the NQB queue (as
	discussed in Section 6.3).		discussed in Section 6.3).
	Appendix B. Comparison with Expedited Forwarding		Appendix B. Comparison with Expedited Forwarding
	The EF definition [RFC3246] provides the following text to describe		The EF definition [RFC3246] provides the following text to describe
	the EF PHB forwarding behavior:		the EF PHB forwarding behavior:
	skipping to change at line 1749 ¶		skipping to change at line 1755 ¶
	forwarding rate available to the PHB. Section 5.2 discusses the		forwarding rate available to the PHB. Section 5.2 discusses the
	recommended mechanism for handling excess traffic in NQB. While EF		recommended mechanism for handling excess traffic in NQB. While EF
	relies on rate policing and dropping of excess traffic at the domain		relies on rate policing and dropping of excess traffic at the domain
	border, this is only one option for NQB. NQB primarily recommends		border, this is only one option for NQB. NQB primarily recommends
	traffic protection located at each potential bottleneck, where actual		traffic protection located at each potential bottleneck, where actual
	queuing can be detected and where excess traffic can be reclassified		queuing can be detected and where excess traffic can be reclassified
	into the Default PHB rather than dropping it. Local traffic		into the Default PHB rather than dropping it. Local traffic
	protection is more feasible for NQB, given the focus is on access		protection is more feasible for NQB, given the focus is on access
	networks, where one node is typically designed to be the known		networks, where one node is typically designed to be the known
	bottleneck where traffic control functions all reside. In contrast,		bottleneck where traffic control functions all reside. In contrast,
	EF is presumed to follow the DS architecture [RFC2475] for core		EF is presumed to follow the Diffserv architecture [RFC2475] for core
	networks, where traffic conditioning is delegated to border nodes in		networks, where traffic conditioning is delegated to border nodes in
	order to simplify high-capacity interior nodes. Further, NQB		order to simplify high-capacity interior nodes. Further, NQB
	recommends a microflow-based mechanism to limit the performance		recommends a microflow-based mechanism to limit the performance
	impact of excess traffic to those microflows causing potential		impact of excess traffic to those microflows causing potential
	congestion of the NQB queue, whereas EF ignores microflow properties.		congestion of the NQB queue, whereas EF ignores microflow properties.
	Note that, under congestion, low loss for NQB-conformant flows is		Note that, under congestion, low loss for NQB-conformant flows is
	only ensured if such a mechanism is operational. Note also that this		only ensured if such a mechanism is operational. Note also that this
	mechanism for NQB operates at the available forwarding rate for the		mechanism for NQB operates at the available forwarding rate for the
	PHB (which could vary based on other traffic load) as opposed to a		PHB (which could vary based on other traffic load) as opposed to a
	configured guaranteed rate, as in EF.		configured guaranteed rate, as in EF.
	skipping to change at line 1783 ¶		skipping to change at line 1789 ¶
	places a pre-condition that each microflow be relatively low data		places a pre-condition that each microflow be relatively low data
	rate and sent in a smooth (non-bursty) manner. In actual practice,		rate and sent in a smooth (non-bursty) manner. In actual practice,
	EF traffic is oftentimes prioritized over Default traffic. This		EF traffic is oftentimes prioritized over Default traffic. This
	contrasts with NQB traffic, which is to be treated with the same		contrasts with NQB traffic, which is to be treated with the same
	forwarding precedence as Default (and sometimes aggregated with		forwarding precedence as Default (and sometimes aggregated with
	Default).		Default).
	Appendix C. Impact on Higher Layer Protocols		Appendix C. Impact on Higher Layer Protocols
	The NQB PHB itself has no impact on higher layer protocols because it		The NQB PHB itself has no impact on higher layer protocols because it
	only isolates NQB traffic from non-NQB. However, traffic protection		only isolates NQB traffic from QB traffic. However, traffic
	of the PHB can have unintended side effects on higher layer		protection of the PHB can have unintended side effects on higher
	protocols. Traffic protection introduces the possibility that		layer protocols. Traffic protection introduces the possibility that
	microflows classified into the NQB queue could experience out-of-		microflows classified into the NQB queue could experience out-of-
	order delivery or packet loss if their behavior is not consistent		order delivery or packet loss if their behavior is not consistent
	with the NQB sender requirements. Out-of-order delivery could be		with the NQB sender requirements. Out-of-order delivery could be
	particularly likely if the traffic protection algorithm makes		particularly likely if the traffic protection algorithm makes
	decisions on a packet-by-packet basis. In this scenario, a microflow		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		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		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 and some of them either discarded or redirected to the QB
	queue. In the case of redirection, depending on the queuing delay		queue. In the case of redirection, depending on the queuing delay
	and scheduling within the network element, this could result in		and scheduling within the network element, this could result in
	packets being delivered out of order. As a result, the use of the		packets being delivered out of order. As a result, the use of the
	NQB DSCP by a higher layer protocol carries some risk that an		NQB DSCP by a higher layer protocol carries some risk that an
	increased amount of out-of-order delivery or packet loss will be		increased amount of out-of-order delivery or packet loss will be
	experienced. This characteristic provides one disincentive for		experienced. This characteristic provides one disincentive for
	incorrectly setting the NQB DSCP on traffic that doesn't comply with		incorrectly setting the NQB DSCP on traffic that doesn't comply with
	the NQB sender requirements.		the NQB sender requirements.
	Appendix D. Alternative DS Codepoints		Appendix D. Alternative Diffserv Codepoints
	In networks where the DSCP 45 (decimal) is already in use for another		In networks where the DSCP value 45 (decimal) is already in use for
	(e.g., a local-use) purpose or where specialized PHBs are available		another (e.g., a local-use) purpose or where specialized PHBs are
	that can meet specific application requirements (e.g., a guaranteed-		available that can meet specific application requirements (e.g., a
	delay path for voice traffic), use of another DSCP value could be		guaranteed-delay path for voice traffic), use of another DSCP value
	preferred.		could be preferred.
	In end systems where the choice of using DSCP 45 (decimal) is not		In end systems where the choice of using DSCP value 45 (decimal) is
	available to the application, the CS5 DSCP (40 decimal) could be used		not available to the application, the CS5 DSCP (40 decimal) could be
	as a fallback. See Section 6.3 for rationale as to why this choice		used as a fallback. See Section 6.3 for rationale as to why this
	could be fruitful.		choice could be fruitful.
	Acknowledgements		Acknowledgements
	Thanks to Gorry Fairhurst, Diego Lopez, Stuart Cheshire, Brian		Thanks to Gorry Fairhurst, Diego Lopez, Stuart Cheshire, Brian
	Carpenter, Bob Briscoe, Greg Skinner, Toke Hoeiland-Joergensen, Luca		Carpenter, Bob Briscoe, Greg Skinner, Toke Hoeiland-Joergensen, Luca
	Muscariello, David Black, Jerome Henry, Steven Blake, Jonathan		Muscariello, David Black, Jerome Henry, Steven Blake, Jonathan
	Morton, Roland Bless, Kevin Smith, Martin Dolly, and Kyle Rose for		Morton, Roland Bless, Kevin Smith, Martin Dolly, and Kyle Rose for
	their review comments. Thanks also to Gorry Fairhurst and Ana		their review comments. Thanks also to Gorry Fairhurst and Ana
	Custura for their input on selection of appropriate DSCPs. Thanks to		Custura for their input on selection of appropriate DSCPs. Thanks to
	the following for IESG reviews and comments: Mohamed Boucadair, Ketan		the following for IESG reviews and comments: Mohamed Boucadair, Ketan
End of changes. 52 change blocks.
	207 lines changed or deleted		213 lines changed or added
This html diff was produced by rfcdiff 1.48.