rfc9956v1.txt   rfc9956.txt 
skipping to change at line 30 skipping to change at line 30
low-data-rate, application-limited traffic microflows, which would low-data-rate, application-limited traffic microflows, which would
ordinarily share a queue with bursty and capacity-seeking traffic, to ordinarily share a queue with bursty and capacity-seeking traffic, to
avoid the delay, delay variation and loss caused by such traffic. avoid the delay, delay variation and loss caused by such traffic.
This PHB is implemented without prioritization and can be implemented This PHB is implemented without prioritization and can be implemented
without rate policing, making it suitable for environments where the without rate policing, making it suitable for environments where the
use of these features is restricted. The NQB PHB has been developed use of 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 and core segments are discussed. This document mobile network radio/core segments are discussed in this document.
recommends a specific Differentiated Services Code Point (DSCP) to This document recommends a specific Differentiated Services Code
identify Non-Queue-Building microflows and updates the guidance in Point (DSCP) to identify Non-Queue-Building microflows and updates
RFC 8325 on mapping differentiated services (Diffserv) to IEEE 802.11 the guidance in RFC 8325 on mapping Differentiated Services
for this codepoint. (Diffserv) to IEEE 802.11 for this codepoint.
Status of This Memo Status of This Memo
This is an Internet Standards Track document. This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841. Internet Standards is available in Section 2 of RFC 7841.
skipping to change at line 108 skipping to change at line 108
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 Diffserv Code Points Appendix D. Alternative Diffserv Code Points
Acknowledgements Acknowledgements
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
This document defines a Differentiated Services per-hop behavior This document defines a Diffserv PHB called the "Non-Queue-Building
(PHB) called the "Non-Queue-Building Per-Hop Behavior" (or "NQB Per-Hop Behavior" (or "NQB PHB"). The NQB PHB isolates traffic
PHB"), which isolates traffic microflows (application-to-application microflows (application-to-application flows, see Section 1.2 of
flows, see Section 1.2 of [RFC2475]) that are relatively low data [RFC2475]) that have relatively low data rates and that do not,
rate and that do not themselves materially contribute to queuing themselves, materially contribute to queuing delay and loss. This
delay and loss, allowing them to avoid the queuing delay and losses isolation allows these traffic microflows to avoid the queuing delay
caused by other traffic. Non-Queue-Building microflows such as and losses caused by other traffic.
interactive voice, game sync packets, certain machine-to-machine
applications, DNS lookups, and some real-time Internet of Things Non-Queue-Building microflows such as interactive voice, game sync
(IoT) analytics data are low-data-rate, application-limited packets, certain machine-to-machine applications, DNS lookups, and
microflows. These can be distinguished from bursty traffic some real-time Internet of Things (IoT) analytics data are low-data-
microflows and high-data-rate traffic microflows managed by a classic rate, application-limited microflows. These can be distinguished
congestion control algorithm (both of which cause queuing delay and from bursty traffic microflows and high-data-rate traffic microflows
loss). The term "classic congestion control" is defined in [RFC9330] managed by a classic congestion control algorithm (both of which
to mean congestion control that coexists with standard Reno cause queuing delay and loss). The term "classic congestion control"
congestion control [RFC5681]. In this document, we will use "Queue- is defined in [RFC9330] to mean congestion control that coexists with
Building" (or "QB") to refer to microflows that cause queuing delay standard Reno congestion control [RFC5681]. In this document, we
and loss. See Section 1.2 of [RFC2475] for definitions of other will use "Queue-Building" (or "QB") to refer to microflows that cause
terminology used in this document. queuing delay and loss. See Section 1.2 of [RFC2475] for definitions
of other terminology used in this document.
In accordance with IETF guidance in [RFC2914] and [RFC8085], most In accordance with IETF guidance in [RFC2914] and [RFC8085], most
packets carried by access networks are managed by an end-to-end packets carried by access networks are managed by an end-to-end
congestion control algorithm. Many of the commonly deployed congestion control algorithm. Many of the commonly deployed
congestion control algorithms, such as Reno [RFC5681], Cubic congestion control algorithms, such as Reno [RFC5681], CUBIC
[RFC9438], or BBR [BBR-CC], are designed to seek the available [RFC9438], or BBR [BBR-CC], are designed to seek the available
capacity of the path from sender to receiver (which can frequently be capacity of the path from sender to receiver (which can frequently be
the access network link capacity). In doing so, they generally the access network link capacity). In doing so, they generally
overshoot the available capacity, causing a queue to build up at the overshoot the available capacity, causing a queue to build up at the
bottleneck link. This queue buildup results in variable delay and bottleneck link. This queue buildup results in variable delay and
packet loss that can affect all the applications that are sharing the packet loss that can affect all the applications that are sharing the
bottleneck link. Moreover, many bottleneck links implement a bottleneck link. Moreover, many bottleneck links implement a
relatively deep buffer (100 ms or more) (see [Gettys2012], relatively deep buffer (100 ms or more) (see [Gettys2012],
[Cardwell2017], [WikipediaBufferbloat], and [BBR-CC]) in order to [Cardwell2017], [WikipediaBufferbloat], and [BBR-CC]) in order to
enable these congestion control algorithms to use the link enable these congestion control algorithms to use the link
efficiently, which exacerbates the delay and delay variation efficiently, which exacerbates the delay and delay variation
experienced. experienced.
In contrast to applications that frequently cause queuing delay, In contrast to applications that frequently cause queuing delay,
there are a variety of relatively low data rate applications that do there are a variety of relatively low data rate applications that do
not materially contribute to queuing delay and loss; nonetheless, not materially contribute to queuing delay and loss; nonetheless,
they are subjected to it by sharing the same bottleneck link in the they are subjected to it by sharing the same bottleneck link. Many
access network. Many of these applications can be sensitive to delay of these applications can be sensitive to delay or delay variation,
or delay variation, as well as packet loss; thus, they produce a poor as well as packet loss; thus, they produce a poor Quality of
quality of experience in such conditions. Experience in such conditions.
Active Queue Management (AQM) mechanisms intended for single queues Active Queue Management (AQM) mechanisms intended for single queues
(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 quality of experience for delay-sensitive applications, but there the Quality of Experience for delay-sensitive applications, but there
are practical limits to the amount of improvement that can be are practical limits to the amount of improvement that can be
achieved without impacting the throughput of capacity-seeking achieved without impacting the throughput of capacity-seeking
applications. For example, AQMs generally allow a significant amount applications. For example, AQMs generally allow a significant amount
of queue depth variation to accommodate the behaviors of congestion of queue depth 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 control 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 quality of experience for their classes can deliver satisfactory Quality of Experience for their
applications. In particular, the NQB PHB provides a shallow- applications. In particular, the NQB PHB provides a shallow-
buffered, best-effort service as a complement to a Default (see buffered, best-effort service as a complement to a Default (see
[RFC2474]) deep-buffered, best-effort service. This PHB is designed [RFC2474]) deep-buffered, best-effort service. This PHB is designed
for broadband access network links, where there is minimal for broadband access network links (where there is minimal
aggregation of traffic, and especially when buffers are deep (see aggregation of traffic), especially when buffers are deep (see
Section 3.4). The applicability of this PHB to lower-speed links is Section 3.4). The applicability of this PHB to lower-rate links is
discussed in Section 6.6. discussed in Section 6.6.
To be clear, a network implementing the NQB PHB solely provides To be clear, a network implementing the NQB PHB solely provides
isolation for traffic classified as behaving in conformance with the isolation for traffic classified as behaving in conformance with the
behaviors discussed in Section 3.1. A node supporting the NQB PHB behaviors discussed in Section 3.1. A node supporting the NQB PHB
makes no guarantees on delay or data rate for NQB-marked microflows makes no guarantees on delay or data rate for NQB-marked microflows
(beyond the delay bound provided by the shallow buffer), it is the (beyond the delay bound provided by the shallow buffer), it is the
NQB senders' behavior itself that results in low delay and low loss. NQB senders' behavior itself that results in low delay and low loss.
Sections 6 and 7 of this document provide guidance for network Sections 6 and 7 of this document provide guidance for network
skipping to change at line 227 skipping to change at line 228
that tend to cause large and/or standing queues to form. These that tend to cause large and/or standing queues to form. These
applications typically implement a response to network congestion applications typically implement a response to network congestion
that consists of discontinuing (or significantly reducing) that consists of discontinuing (or significantly reducing)
transmissions. These applications can be negatively affected by transmissions. These applications can be negatively affected by
excessive delay and delay variation. Such applications are ideal excessive delay and delay variation. Such applications are ideal
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, Queue-Building (QB) microflows include those that probe In contrast, Queue-Building (QB) microflows include those that probe
for link capacity and induce delay and loss as a result, for example, for link capacity and induce delay and loss as a result, for example,
microflows that use Cubic, Reno, or other TCP/QUIC congestion control microflows that use CUBIC, Reno, or other TCP/QUIC congestion control
algorithms in a capacity-seeking manner. Other types of QB algorithms in a capacity-seeking manner. Other types of QB
microflows include those that send at a high burst rate even if the microflows include those that send at a high burst rate even if the
long-term average data rate is much lower. long-term average data rate is much lower.
3.2. Relationship to the Diffserv Architecture 3.2. Relationship to the Diffserv Architecture
The IETF has defined the Differentiated Services architecture The IETF has defined the Differentiated Services architecture
[RFC2475] with the intention that it allows traffic to be marked in a [RFC2475] with the intention that it allows traffic to be marked in a
manner that conveys the performance requirements of that traffic manner that conveys the performance requirements of that traffic
either qualitatively or in a relative sense (e.g., priority). The either qualitatively or in a relative sense (e.g., priority). The
skipping to change at line 312 skipping to change at line 313
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 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 treated 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-
Effort (LE) [RFC8622] (e.g., the NQB queue could be emptied in a Effort (LE) [RFC8622] (e.g., the NQB queue could be emptied in a
priority 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
skipping to change at line 335 skipping to change at line 336
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
of [RFC9332]) is considered sufficient to support the NQB PHB of [RFC9332]) is considered sufficient to support the NQB PHB
requirement of fair allocation of capacity between the QB and NQB requirement of fair allocation of capacity between the QB and NQB
queues (Section 5). Note that these requirements, in turn, require queues (Section 5). Note that these requirements, in turn, require
compliance with all the requirements in Section 5 of [RFC9331]. compliance with all the requirements in Section 5 of [RFC9331].
Applications that comply with both the NQB sender requirements in Applications that comply with both the NQB sender requirements in
Section 4 and the L4S "Prague" requirements in Section 4 of [RFC9331] Section 4 and the "Prague L4S requirements" in Section 4 of [RFC9331]
could mark their packets both with the NQB DSCP and with the ECT(1) could mark their packets both with the NQB DSCP and with the ECT(1)
value. value.
In nodes that support both the NQB PHB and L4S, the L4S network In nodes that support both the NQB PHB and L4S, the L4S network
functions SHOULD treat packets marked with the NQB DSCP and ECT(1) or functions SHOULD treat packets marked with the NQB DSCP and ECT(1) or
CE the same as packets marked with the Default DSCP and the same CE the same as packets marked with the Default DSCP and the same
Explicit Congestion Notification (ECN) value. Here, "L4S network Explicit Congestion Notification (ECN) value. Here, "L4S network
functions" refers to the L4S Network Node functions (see Section 5 of functions" refers to the L4S Network Node functions (see Section 5 of
[RFC9331]), and any mechanisms designed to protect the L4S queue [RFC9331]), and any mechanisms designed to protect the L4S queue
(such as those discussed in Section 8.2 of [RFC9330]). The (such as those discussed in Section 8.2 of [RFC9330]). The
skipping to change at line 397 skipping to change at line 398
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
existing guidance for safe deployment on the Internet, including the existing guidance for safe deployment on the Internet, including the
guidance around response to network congestion, for example the guidance related to response to network congestion, for example the
requirements in [RFC8085] and Section 2 of [RFC3551] (also see the requirements in [RFC8085] and Section 2 of [RFC3551] (also see the
circuit breaker limits in Section 4.3 of [RFC8083] and the circuit breaker limits in Section 4.3 of [RFC8083] and the
description of inelastic pseudowires in Section 4 of [RFC7893]). The description of inelastic pseudowires in Section 4 of [RFC7893]). The
fact that a microflow's data rate is low relative to typical network fact that a microflow's data rate is low relative to typical network
capacities is no guarantee that sufficient capacity exists in any capacities is no guarantee that sufficient capacity exists in any
particular network, and it is the responsibility of the application particular network, and it is the responsibility of the application
to detect and react appropriately if the network capacity is to detect and react appropriately if the network capacity is
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
skipping to change at line 515 skipping to change at line 516
them could result in a discernible benefit for mis-marked traffic (to them could result in a discernible benefit for mis-marked traffic (to
the detriment of other traffic). In network nodes that are rarely the detriment of other traffic). In network nodes that are rarely
bottlenecks, these recommendations are less critical. bottlenecks, these recommendations are less critical.
In the DRR example above, equal scheduling weights is only an In the DRR example above, equal scheduling weights is only an
example. Ideally, the DRR weight would be chosen to match the example. Ideally, the DRR weight would be chosen to match the
highest fraction of capacity that NQB-compliant flows are likely to highest fraction of capacity that NQB-compliant flows are likely to
use on a particular network segment. Given that NQB-compliant flows use on a particular network segment. Given that NQB-compliant flows
are not capacity seeking (in contrast to QB flows, which can be), and are not capacity seeking (in contrast to QB flows, which can be), and
since DRR allows unused capacity in one class to be used by traffic since DRR allows unused capacity in one class to be used by traffic
in the other, providing a higher-than-necessary NQB scheduler weight in the other, providing a higher-than-needed NQB scheduler weight
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.
skipping to change at line 863 skipping to change at line 864
bottleneck, perhaps because it was too complex to manage traffic bottleneck, perhaps because it was too complex to manage traffic
contracts and conditioning. Candidate service classes for this contracts and conditioning. Candidate service classes for this
aggregation would include those that carry low-data-rate inelastic aggregation would include those that carry low-data-rate inelastic
traffic that has low to very-low tolerance for loss, delay, and/or traffic that has low to very-low tolerance for loss, delay, and/or
delay variation. Operators would need to use their own judgment delay variation. Operators would need to use their own judgment
based on the actual traffic characteristics in their networks in based on the actual traffic characteristics in their networks in
deciding whether or not to aggregate other service classes / DSCPs deciding whether or not to aggregate other service classes / DSCPs
with NQB. For networks that use the service class definitions from with NQB. For networks that use the service class definitions from
[RFC4594], this could include Telephony (EF/VA), Signaling (CS5), and [RFC4594], this could include Telephony (EF/VA), Signaling (CS5), and
possibly Real-Time Interactive (CS4) (depending on data rate). In possibly Real-Time Interactive (CS4) (depending on data rate). In
the preceding sentence, "VA" and "CSx" refer to Voice-Admit the preceding sentence, "VA" and "CSx" refer to VOICE-ADMIT
([RFC5865]) and Class Selector ([RFC2474]), respectively. In some ([RFC5865]) and Class Selector ([RFC2474]), respectively. In some
networks, equipment limitations may necessitate aggregating a range networks, equipment limitations may necessitate aggregating a range
of DSCPs (e.g., traffic marked with DSCPs 40-47 (decimal), i.e., of DSCPs (e.g., traffic marked with DSCPs 40-47 (decimal), i.e.,
those whose three most significant bits are 0b101). As noted in those whose three most significant bits are 0b101). As noted in
Section 4, the choice of the DSCP value 45 (decimal) is motivated in Section 4, the choice of the DSCP value 45 (decimal) is motivated in
part by the desire to make this aggregation simpler in network part by the desire to make this aggregation simpler in network
equipment that can classify packets via comparing the DSCP value to a equipment that can classify packets via comparing the DSCP value to a
range of configured values. range of configured values.
A node providing only a NQB queue and a Default queue may obtain an A node providing only a NQB queue and a Default queue may obtain an
skipping to change at line 916 skipping to change at line 917
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 Diffserv is delivering traffic to network operator that supports Diffserv is delivering traffic to
another network domain (e.g., a network outside of their another network domain (e.g., a network outside of their
administrative control) where there is an understanding that the administrative control) where there is an understanding that the
downstream domain does not support Diffserv or there is no knowledge downstream domain does not support Diffserv or there is no knowledge
of the traffic management capabilities of the downstream domain, and of the traffic management capabilities of the downstream domain, and
no agreement in place. In such cases, Section 4 of [RFC2475] no agreement in place. In such cases, Section 4 of [RFC2475]
suggests that the upstream domain opportunistically re-mark traffic suggests that the upstream domain opportunistically re-mark traffic
with a Class Selector codepoint or DSCP 0 (Default) under the with a Class Selector Codepoint or DSCP 0 (Default) under the
assumption that traffic so marked would be handled in a predictable assumption that traffic so marked would be handled in a predictable
way by the 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 NQB DSCP value), the same
concerns apply. In particular, since the recommended NQB DSCP value concerns apply. In particular, since the recommended NQB DSCP value
could be given high priority in some non-DS-compliant network could be given high priority in some non-DS-compliant network
equipment (e.g., legacy Wi-Fi APs as described in Section 7.3.1), it equipment (e.g., legacy Wi-Fi APs as described in Section 7.3.1), it
is RECOMMENDED that the operator of the upstream domain implement one is RECOMMENDED that the operator of the upstream domain implement one
of the following safeguards before delivering traffic into a non-DS- of the following safeguards before delivering traffic into a non-DS-
skipping to change at line 1064 skipping to change at line 1065
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 quality of service that each traffic. In such networks, the quality of service that each
application receives, and as a result, the quality of experience that application receives, and as a result, the Quality of Experience that
it generates for the user is influenced by the characteristics of the it generates for the user is influenced by the characteristics of the
access network link. access network link.
To support the NQB PHB, cable broadband services would need to be To support the NQB PHB, cable broadband services would need to be
configured to provide a separate queue for traffic marked with the configured to provide a separate queue for traffic marked with the
NQB DSCP. The NQB queue would need to be configured to share the NQB DSCP. The NQB queue would need to be configured to share the
service's rate shaped capacity with the queue for QB traffic. service's rate shaped capacity with the queue for QB traffic.
Further discussion about support of the NQB PHB in DOCSIS networks Further discussion about support of the NQB PHB in DOCSIS networks
can be found in [LOW_LATENCY_DOCSIS]. can be found in [LOW_LATENCY_DOCSIS].
7.2. Mobile Networks 7.2. Mobile Networks
Historically, 3GPP mobile networks have utilized "bearers" to Historically, 3GPP mobile networks have utilized "bearers" to
encapsulate each user's user plane traffic through the radio and core encapsulate each user's user plane traffic through the radio access
networks. A "dedicated bearer" can be allocated a Quality of Service and core networks. Bearers are also associated with a Quality of
(QoS) to apply any prioritization to its microflows at queues and Service (QoS) that determines how packets are prioritized at queues
radio schedulers. Typically, an LTE operator provides a dedicated and radio schedulers. In LTE networks, these are EPS bearers, part
bearer for IP Multimedia Subsystems (IMS) VoLTE (Voice over LTE) of the Evolved Packet System (EPS), which comprises the core and
traffic, which is prioritized in order to meet regulatory obligations access network architecture. Typically, an LTE operator provides a
for call completion rates, and a "best effort" default bearer for dedicated EPS bearer for IP Multimedia Subsystem (IMS) Voice over LTE
Internet traffic. The "best effort" bearer provides no guarantees; (VoLTE) traffic to meet regulatory obligations for call completion
hence, its buffering characteristics are not compatible with low- rates, and a best-effort default EPS bearer for Internet traffic.
latency traffic. The 5G radio and core systems offer more This default EPS bearer is typically non-Guaranteed Bit Rate (non-
flexibility over bearer allocation, meaning bearers can be allocated GBR) and provides no guarantees; its buffering characteristics
per traffic type (e.g., loss-tolerant, low-latency, etc.); hence, generally are not compatible with low-latency traffic. In 5G
they support more suitable treatment of Internet real-time networks, similar functionality is provided using QoS flows within a
microflows. PDU Session in the core network, which are mapped to Data Radio
Bearers (DRBs) on the radio network. 5G systems offer more
flexibility in QoS handling, allowing traffic to be treated according
to type (e.g., loss-tolerant, low-latency); hence, they support more
suitable treatment of Internet real-time microflows.
To support the NQB PHB, the mobile network could be configured to To support the NQB PHB, an LTE network could be configured to provide
give User Equipment (UE, the mobile device used by the subscriber) a the User Equipment (UE, the subscriber's device) with a dedicated
dedicated, low-latency, non-GBR (non-Guaranteed Bit Rate), EPS low-latency, non-GBR EPS bearer, in addition to the default EPS
(Evolved Packet System, the core and access network architecture used bearer. For example, this dedicated EPS bearer could use QCI 7 (QoS
in LTE) bearer, e.g., one with QCI 7 (QoS Class Identifier 7, which Class Identifier 7), which is typically used for low-latency, non-GBR
is typically used for low-latency, non-GBR services), in addition to services. Alternatively, in a 5G system, a Data Radio Bearer (DRB)
the default EPS bearer. Alternatively, in a 5G system, a Data Radio with 5QI 7 (5G QoS Identifier 7, also used for low-latency traffic),
Bearer with 5QI 7 (5G QoS Identifier 7), similarly used for low- could be provisioned (see Table 5.7.4-1: Standardized 5QI to QoS
latency traffic, could be provisioned (see Table 5.7.4-1: characteristics mapping in [SA-5G]).
Standardized 5QI to QoS characteristics mapping in [SA-5G]).
A packet carrying the NQB DSCP could then be routed through this A packet carrying the NQB DSCP could then be routed through this
dedicated low-latency EPS bearer, while a packet that has no dedicated low-latency path, while packets without the NQB marking
associated NQB marking would be routed through the default EPS would be routed through the default bearer.
bearer.
7.3. Wi-Fi Networks 7.3. Wi-Fi Networks
Wi-Fi networking equipment compliant with 802.11e/n/ac/ax Wi-Fi networking equipment compliant with 802.11e/n/ac/ax
[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 Enhanced Distributed Channel Access and four sets of associated Enhanced Distributed Channel Access
(EDCA) parameters (corresponding to the four Wi-Fi Multimedia (WMM) (EDCA) parameters (corresponding to the four Wi-Fi Multimedia (WMM)
Access Categories) that are used to enable differentiated medium Access Categories) that are used to enable differentiated medium
access characteristics. The four WMM Access Categories, referred to access characteristics. The four WMM Access Categories, referred to
as Voice Access Category (AC_VO), Video Access Category (AC_VI), Best as Voice Access Category (AC_VO), Video Access Category (AC_VI), Best
skipping to change at line 1165 skipping to change at line 1168
not both) of the following characteristics: not both) of the following characteristics:
* the NQB PHB requirement for separate queuing of NQB traffic from * the NQB PHB requirement for separate queuing of NQB traffic from
Default traffic (Section 5.1) Default traffic (Section 5.1)
* the recommendation to treat NQB traffic with forwarding preference * the recommendation to treat NQB traffic with forwarding preference
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- Video Access Category. While this choice of DSCP enables these Wi-Fi
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 in statistical prioritization of the Video Access Category above the
the "Best Effort" Access Category. In addition, this equipment does Best Effort Access Category. In addition, this equipment does not
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 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.
skipping to change at line 1266 skipping to change at line 1269
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 NQB DSCP 45 (decimal) (or the
locally determined alternative) to UP 5 in the "Video" Access locally determined alternative) to UP 5 in the Video Access Category
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:
 End of changes. 22 change blocks. 
77 lines changed or deleted 80 lines changed or added

This html diff was produced by rfcdiff 1.48.