rfc9956v3.txt		rfc9956.txt
	skipping to change at line 165 ¶		skipping to change at line 165 ¶
	(such as Proportional Integral Controller Enhanced (PIE) [RFC8033],		(such as Proportional Integral Controller Enhanced (PIE) [RFC8033],
	DOCSIS-PIE [RFC8034], PI2 [RFC9332], or CoDel [RFC8289]) can improve		DOCSIS-PIE [RFC8034], PI2 [RFC9332], or CoDel [RFC8289]) can improve
	the QoE for delay-sensitive applications, but there are practical		the QoE for delay-sensitive applications, but there are practical
	limits to the amount of improvement that can be achieved without		limits to the amount of improvement that can be achieved without
	impacting the throughput of capacity-seeking applications. For		impacting the throughput of capacity-seeking applications. For
	example, AQMs generally allow a significant amount of queue depth		example, AQMs generally allow a significant amount of queue depth
	variation to accommodate the behaviors of congestion control		variation to accommodate the behaviors of congestion control
	algorithms such as Reno and CUBIC. If the AQM attempted to control		algorithms such as Reno and CUBIC. If the AQM attempted to control
	the queue depth much more tightly, applications using those		the queue depth much more tightly, applications using those
	algorithms would not fully utilize the link. Alternatively, flow-		algorithms would not fully utilize the link. Alternatively, flow-
	queuing systems, such as fq_codel [RFC8290] can be employed to		queuing systems, such as fq_codel [RFC8290], can be employed to
	isolate microflows from one another; however, they are not		isolate microflows from one another; however, they are not
	appropriate for all bottleneck links due to reasons that include		appropriate for all bottleneck links due to reasons that include
	complexity.		complexity.
	The NQB PHB supports differentiating between these two classes of		The NQB PHB supports differentiating between these two classes of
	traffic in bottleneck links and queuing them separately so that both		traffic in bottleneck links and queuing them separately so that both
	classes can deliver satisfactory QoE for their applications. In		classes can deliver satisfactory QoE for their applications. In
	particular, the NQB PHB provides a shallow-buffered, best-effort		particular, the NQB PHB provides a shallow-buffered, best-effort
	service as a complement to a Default (see [RFC2474]) deep-buffered,		service as a complement to a Default (see [RFC2474]) deep-buffered,
	best-effort service. This PHB is designed for broadband access		best-effort service. This PHB is designed for broadband access
	skipping to change at line 307 ¶		skipping to change at line 307 ¶
	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 Diffserv series, the closest similarity is to the		PHBs in the Diffserv series, the closest similarity is to the
	Expedited Forwarding (EF) PHB [RFC3246], which also intends to enable		Expedited Forwarding (EF) PHB [RFC3246], which also intends to enable
	services that provide low loss, low delay, and low-delay variation.		services that provide low loss, low delay, and low-delay variation.
	Unlike EF, NQB has no requirement for a guaranteed minimum rate, nor		Unlike EF, NQB has no requirement for a guaranteed minimum rate, nor
	does have a requirement to police incoming traffic to such a rate:		does it have a requirement to police incoming traffic to such a rate:
	NQB is 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 Diffserv Service Classes, NQB traffic		In nodes that support multiple Diffserv Service Classes, NQB traffic
	is intended to be handled as a part of the Default treatment.		is intended to be handled as a part of the Default treatment.
	Traffic assigned to this class does not receive better forwarding		Traffic assigned to this class does not receive better forwarding
	treatment (e.g., prioritization) with respect to other classes, AFxx,		treatment (e.g., prioritization) with respect to other classes, AFxx,
	EF, etc. Of course, traffic marked as NQB could (like other Default		EF, etc. Of course, traffic marked as NQB could (like other Default
	traffic) receive better forwarding treatment with respect to Lower-		traffic) receive better forwarding treatment with respect to Lower-
	skipping to change at line 386 ¶		skipping to change at line 386 ¶
	application itself rather than by network capacity: these microflows		application itself rather than by network capacity: these microflows
	send at a data rate of no more than about 1% of the "typical" network		send at a data rate of no more than about 1% of the "typical" network
	path capacity. In addition, these microflows are required to be sent		path capacity. In addition, these microflows are required to be sent
	in a smooth (i.e., paced) manner, where the number of IP bytes sent		in a smooth (i.e., paced) manner, where the number of IP bytes sent
	in any time interval "T" is less than or equal to (R * T) + MTU,		in any time interval "T" is less than or equal to (R * T) + MTU,
	where "R" is the maximum rate described in the preceding sentence,		where "R" is the maximum rate described in the preceding sentence,
	expressed in bytes-per-second. For example, at the time of writing,		expressed in bytes-per-second. For example, at the time of writing,
	access network data rates are typically on the order of 50 Mbps or		access network data rates are typically on the order of 50 Mbps or
	more in the Internet (see Section 6.6 for a discussion of cases where		more in the Internet (see Section 6.6 for a discussion of cases where
	this isn't true): this implies 500 kbps as an upper limit. Note that		this isn't true): this implies 500 kbps as an upper limit. Note that
	microflows are unidirectional while application traffic is often		microflows are unidirectional, while application traffic is often
	bidirectional (i.e., an application instance might consist of one or		bidirectional (i.e., an application instance might consist of one or
	more microflows in each direction). For a particular application, it		more microflows in each direction). For a particular application, it
	could be the case that some of its microflows are eligible to be		could be the case that some of its microflows are eligible to be
	marked with the NQB DSCP while others are not. For example, an		marked with the NQB DSCP while others are not. For example, an
	interactive video streaming application might consist of a high-		interactive video streaming application might consist of a high-
	bandwidth video stream (not eligible for NQB marking) in one		bandwidth video stream (not eligible for NQB marking) in one
	direction and a low-bandwidth control stream (eligible for NQB		direction and a low-bandwidth control stream (eligible for NQB
	marking) in the other.		marking) in the other.
	Microflows marked with the NQB DSCP are expected to comply with		Microflows marked with the NQB DSCP are expected to comply with
	skipping to change at line 633 ¶		skipping to change at line 633 ¶
	overflows the shallow buffer provided for NQB traffic; this is		overflows the shallow buffer provided for NQB traffic; this is
	expected to result in redirecting the excess packets to the QB queue		expected to result in redirecting the excess packets to the QB queue
	or discarding them. Both actions degrade service for not only the		or discarding them. Both actions degrade service for not only the
	mis-marked QB traffic, but also for any correctly marked NQB traffic.		mis-marked QB traffic, but also for any correctly marked NQB traffic.
	This will likely cause a significant degradation of service for NQB		This will likely cause a significant degradation of service for NQB
	traffic. Even if mis-marked QB traffic does not cause buffer		traffic. Even if mis-marked QB traffic does not cause buffer
	overflow, the queue that forms results in QB traffic obtaining the		overflow, the queue that forms results in QB traffic obtaining the
	reduced loss and delay benefits of the NQB service while causing		reduced loss and delay benefits of the NQB service while causing
	queuing delay for all the other microflows that are sharing the		queuing delay for all the other microflows that are sharing the
	queue. These increased abilities of QB traffic to damage the NQB		queue. These increased abilities of QB traffic to damage the NQB
	service in the absence of a traffic protection function needs to be		service in the absence of a traffic protection function need 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 Diffserv contexts. Traffic		Conditioning implemented in other Diffserv contexts. Traffic
	skipping to change at line 706 ¶		skipping to change at line 706 ¶
	potential for out-of-order delivery. As a third option, the decision		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		could be made to take action on all the future packets of the
	microflow, though sufficient logic would be needed to ensure that a		microflow, though sufficient logic would be needed to ensure that a
	future microflow (e.g., with the same 5-tuple) isn't misidentified as		future microflow (e.g., with the same 5-tuple) isn't misidentified as
	the current offending microflow.		the current offending microflow.
	In the case of a traffic protection algorithm that discards offending		In the case of a traffic protection algorithm that discards offending
	traffic, similar levels of hysteresis could be considered. In this		traffic, similar levels of hysteresis could be considered. In this
	case, it is RECOMMENDED that the decision thresholds be set higher		case, it is RECOMMENDED that the decision thresholds be set higher
	than in the case of designs that reclassify since the degradation of		than in the case of designs that reclassify since the degradation of
	communications caused by the packet being discarded are likely to be		communications caused by the packet being discarded is likely to be
	greater than the degradation caused by out-of-order delivery.		greater than the degradation caused by out-of-order delivery.
	The traffic protection function described here might require that the		The traffic protection function described here might require that the
	network element maintain microflow state. The traffic protection		network element maintain microflow state. The traffic protection
	function MUST be designed such that the node implementing the NQB PHB		function MUST be designed such that the node implementing the NQB PHB
	does not fail (e.g., crash) in the case that the microflow state is		does not fail (e.g., crash) in the case that the microflow state is
	exhausted. This might be accomplished simply by controlling/limiting		exhausted. This might be accomplished simply by controlling/limiting
	the resources dedicated to tracking misbehaving flows.		the resources dedicated to tracking misbehaving flows.
	Some networks might prefer to implement a Traffic Conditioning		Some networks might prefer to implement a Traffic Conditioning
	skipping to change at line 1048 ¶		skipping to change at line 1048 ¶
	Alternatively, operators of networks with lower rate links MAY choose		Alternatively, operators of networks with lower rate links MAY choose
	to disable NQB support (and thus aggregate traffic marked with the		to disable NQB support (and thus aggregate traffic marked with the
	NQB DSCP with Default traffic) on these lower rate links. For links		NQB DSCP with Default traffic) on these lower rate links. For links
	that have a data rate that is less than 10% of "typical" path rates,		that have a data rate that is less than 10% of "typical" path rates,
	it is RECOMMENDED that the NQB PHB be disabled and that traffic		it is RECOMMENDED that the NQB PHB be disabled and that traffic
	marked with the NQB DSCP is therefore carried using the Default PHB		marked with the NQB DSCP is therefore carried using the Default PHB
	(without being re-marked to the Default DSCP (0)).		(without being re-marked to the Default DSCP (0)).
	7. Mapping NQB to Standards of Other SDOs		7. Mapping NQB to Standards of Other SDOs
	This section provide recommendations for the support of the NQB PHB		This section provides recommendations for the support of the NQB PHB
	in certain use cases. This section is not exhaustive.		in certain use cases. This section is not exhaustive.
	7.1. DOCSIS Access Networks		7.1. DOCSIS Access Networks
	Residential cable broadband Internet services are commonly configured		Residential cable broadband Internet services are commonly configured
	with a single bottleneck link (the access network link) upon which		with a single bottleneck link (the access network link) upon which
	the service definition is applied. The service definition, typically		the service definition is applied. The service definition, typically
	an upstream/downstream data rate tuple, is implemented as a		an upstream/downstream data rate tuple, is implemented as a
	configured pair of rate shapers that are applied to the user's		configured pair of rate shapers that are applied to the user's
	traffic. In such networks, the QoS that each application receives,		traffic. In such networks, the QoS that each application receives,
	skipping to change at line 1457 ¶		skipping to change at line 1457 ¶
	[Barik] Barik, R., Welzl, M., Elmokashfi, A., Dreibholz, T., and		[Barik] Barik, R., Welzl, M., Elmokashfi, A., Dreibholz, T., and
	S. Gjessing, "Can WebRTC QoS Work? A DSCP Measurement		S. Gjessing, "Can WebRTC QoS Work? A DSCP Measurement
	Study", 30th International Teletraffic Congress (ITC 30),		Study", 30th International Teletraffic Congress (ITC 30),
	DOI 10.1109/ITC30.2018.00034, September 2018,		DOI 10.1109/ITC30.2018.00034, September 2018,
	<https://gitlab2.informatik.uni-wuerzburg.de/itc-		<https://gitlab2.informatik.uni-wuerzburg.de/itc-
	conference/itc-publications-public/-/raw/master/itc30/		conference/itc-publications-public/-/raw/master/itc30/
	Barik18ITC30.pdf?inline=true>.		Barik18ITC30.pdf?inline=true>.
	[BBR-CC] Cardwell, N., Ed., Swett, I., Ed., and J. Beshay, Ed.,		[BBR-CC] Cardwell, N., Ed., Swett, I., Ed., and J. Beshay, Ed.,
	"BBR Congestion Control", Work in Progress, Internet-		"BBR Congestion Control", Work in Progress, Internet-
	Draft, draft-ietf-ccwg-bbr-04, 20 October 2025,		Draft, draft-ietf-ccwg-bbr-05, 2 March 2026,
	<https://datatracker.ietf.org/doc/html/draft-ietf-ccwg-		<https://datatracker.ietf.org/doc/html/draft-ietf-ccwg-
	bbr-04>.		bbr-04>.
	[Cardwell2017]		[Cardwell2017]
	Cardwell, N., Cheng, Y., Gunn, C. S., Yeganeh, S. H., and		Cardwell, N., Cheng, Y., Gunn, C. S., Yeganeh, S. H., and
	V. Jacobson, "BBR: Congestion-Based Congestion Control",		V. Jacobson, "BBR: Congestion-Based Congestion Control",
	Communications of the ACM, vol. 60, no. 2, pp. 58-66,		Communications of the ACM, vol. 60, no. 2, pp. 58-66,
	DOI 10.1145/3009824, February 2017,		DOI 10.1145/3009824, February 2017,
	<https://doi.org/10.1145/3009824>.		<https://doi.org/10.1145/3009824>.
End of changes. 7 change blocks.
	7 lines changed or deleted		7 lines changed or added
This html diff was produced by rfcdiff 1.48.