draft-ietf-tsvwg-nqb-04.txt   draft-ietf-tsvwg-nqb-05.txt 
Transport Area Working Group G. White Transport Area Working Group G. White
Internet-Draft CableLabs Internet-Draft CableLabs
Intended status: Standards Track T. Fossati Intended status: Standards Track T. Fossati
Expires: August 26, 2021 ARM Expires: 8 September 2021 ARM
February 22, 2021 7 March 2021
A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated
Services Services
draft-ietf-tsvwg-nqb-04 draft-ietf-tsvwg-nqb-05
Abstract Abstract
This document specifies properties and characteristics of a Non- This document specifies properties and characteristics of a Non-
Queue-Building Per-Hop Behavior (NQB PHB). The purpose of this NQB Queue-Building Per-Hop Behavior (NQB PHB). The purpose of this NQB
PHB is to provide a separate queue that enables low latency and, when PHB is to provide a separate queue that enables low latency and, when
possible, low loss for application-limited traffic flows that would possible, low loss for application-limited traffic flows that would
ordinarily share a queue with capacity-seeking traffic. This PHB is ordinarily share a queue with capacity-seeking traffic. This PHB is
implemented without prioritization and without rate policing, making implemented without prioritization and without rate policing, making
it suitable for environments where the use of either these features it suitable for environments where the use of either these features
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 26, 2021. This Internet-Draft will expire on 8 September 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Overview: Non-Queue-Building Flows . . . . . . . . . . . . . 3 3. Non-Queue-Building Behavior . . . . . . . . . . . . . . . . . 4
4. The NQB PHB and its Relationship to the DiffServ Architecture 4 4. The NQB PHB and its Relationship to the DiffServ
Architecture . . . . . . . . . . . . . . . . . . . . . . 4
5. DSCP Marking of NQB Traffic . . . . . . . . . . . . . . . . . 5 5. DSCP Marking of NQB Traffic . . . . . . . . . . . . . . . . . 5
5.1. End-to-end usage and DSCP Re-marking . . . . . . . . . . 6 5.1. End-to-end usage and DSCP Re-marking . . . . . . . . . . 6
5.2. Aggregation of the NQB PHB with other DiffServ PHBs . . . 8 5.2. Aggregation of the NQB PHB with other DiffServ PHBs . . . 8
6. Non-Queue-Building PHB Requirements . . . . . . . . . . . . . 8 6. Non-Queue-Building PHB Requirements . . . . . . . . . . . . . 9
7. Impact on Higher Layer Protocols . . . . . . . . . . . . . . 10 7. Impact on Higher Layer Protocols . . . . . . . . . . . . . . 10
8. The NQB PHB and Tunnels . . . . . . . . . . . . . . . . . . . 10 8. The NQB PHB and Tunnels . . . . . . . . . . . . . . . . . . . 10
9. Relationship to L4S . . . . . . . . . . . . . . . . . . . . . 10 9. Relationship to L4S . . . . . . . . . . . . . . . . . . . . . 11
10. Configuration and Management . . . . . . . . . . . . . . . . 11 10. Configuration and Management . . . . . . . . . . . . . . . . 11
11. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 11 11. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 11
11.1. DOCSIS Access Networks . . . . . . . . . . . . . . . . . 11 11.1. DOCSIS Access Networks . . . . . . . . . . . . . . . . . 11
11.2. Mobile Networks . . . . . . . . . . . . . . . . . . . . 11 11.2. Mobile Networks . . . . . . . . . . . . . . . . . . . . 12
11.3. WiFi Networks . . . . . . . . . . . . . . . . . . . . . 12 11.3. WiFi Networks . . . . . . . . . . . . . . . . . . . . . 12
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
14. Security Considerations . . . . . . . . . . . . . . . . . . . 14 14. Security Considerations . . . . . . . . . . . . . . . . . . . 14
15. Informative References . . . . . . . . . . . . . . . . . . . 14 15. Informative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
This document defines a Differentiated Services (DS) per-hop behavior This document defines a Differentiated Services (DS) per-hop behavior
(PHB) called "Non-Queue-Building Per-Hop Behavior" (NQB PHB), which (PHB) called "Non-Queue-Building Per-Hop Behavior" (NQB PHB), which
is intended to enable networks to provide low latency and low loss is intended to enable networks to provide low latency and low loss
for traffic flows that are relatively low data rate and that do not for traffic flows that are relatively low data rate and that do not
themselves materially contribute to queueing delay and loss. Such themselves materially contribute to queueing delay and loss. Such
Non-Queue-Building flows (for example: interactive voice and video, Non-Queue-Building flows (for example: interactive voice and video,
gaming, machine to machine applications) are application limited gaming, machine to machine applications) are application limited
skipping to change at page 3, line 46 skipping to change at page 4, line 5
applications. applications.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Overview: Non-Queue-Building Flows 3. Non-Queue-Building Behavior
There are many applications that send traffic at relatively low data There are many applications that send traffic at relatively low data
rates and/or in a fairly smooth and consistent manner such that they rates and/or in a fairly smooth and consistent manner such that they
are highly unlikely to exceed the available capacity of the network are highly unlikely to exceed the available capacity of the network
path between source and sink. These applications do not cause queues path between source and sink. These applications do not cause queues
to form in network buffers, but nonetheless can be subjected to to form in network buffers, but nonetheless can be subjected to
packet delay and delay variation as a result of sharing a network packet delay and delay variation as a result of sharing a network
buffer with applications that do cause queues. Many of these buffer with applications that do cause queues to form. Many of these
applications are negatively affected by excessive packet delay and applications are negatively affected by excessive packet delay and
delay variation. Such applications are ideal candidates to be queued delay variation. Such applications are ideal candidates to be queued
separately from the capacity-seeking applications that are the cause separately from the applications that are the cause of queue buildup,
of queue buildup, latency and loss. latency and loss.
These Non-queue-building (NQB) flows are typically UDP flows that These Non-queue-building (NQB) flows are typically UDP flows that
don't seek the capacity of the link (examples: online games, voice don't seek the capacity of the link (examples: online games, voice
chat, DNS lookups, real-time IoT analytics data). Here the data rate chat, DNS lookups, real-time IoT analytics data). Here the data rate
is limited by the application itself rather than by network capacity is limited by the application itself rather than by network capacity
- in many cases these applications only send a few packets per RTT. - in many cases these applications only send a few packets per RTT.
In contrast, Queue-building (QB) flows include traffic which uses TCP In contrast, Queue-building (QB) flows include traffic which uses TCP
or QUIC, with Cubic, Reno or other TCP congestion controllers. or QUIC, with Cubic, Reno or other TCP congestion control algorithms
that probe for the link capacity and induce latency and loss as a
result.
4. The NQB PHB and its Relationship to the DiffServ Architecture 4. The NQB PHB and its 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 [RFC2475] with the intention that it allows traffic to be marked in
manner that conveys the performance requirements of that traffic manner that conveys the performance requirements of that traffic
either quantitatively or in a relative sense (i.e. priority). The either quantitatively or in a relative sense (i.e. priority). The
architecture defines the use of the DiffServ field [RFC2474] for this architecture defines the use of the DiffServ field [RFC2474] for this
purpose, and numerous RFCs have been written that describe purpose, and numerous RFCs have been written that describe
recommended interpretations of the values (DiffServ Code Points) of recommended interpretations of the values (DiffServ Code Points) of
skipping to change at page 6, line 23 skipping to change at page 6, line 31
mismarking its traffic. Thus, a useful property of nodes that mismarking its traffic. Thus, a useful property of nodes that
support separate queues for NQB and QB flows would be that for NQB support separate queues for NQB and QB flows would be that for NQB
flows, the NQB queue provides better performance than the QB queue; flows, the NQB queue provides better performance than the QB queue;
and for QB flows, the QB queue provides better performance than the and for QB flows, the QB queue provides better performance than the
NQB queue. By adhering to these principles, there is no incentive NQB queue. By adhering to these principles, there is no incentive
for senders to mismark their traffic as NQB, and further, any for senders to mismark their traffic as NQB, and further, any
mismarking can be identified by the network. mismarking can be identified by the network.
Along these lines, nodes that do not support the NQB PHB SHOULD treat Along these lines, nodes that do not support the NQB PHB SHOULD treat
NQB marked traffic the same as traffic marked "Default", and SHOULD NQB marked traffic the same as traffic marked "Default", and SHOULD
preserve the NQB marking. Shallow-buffered backbone and core network preserve the NQB marking. In shallow-buffered backbone and core
switches, and nodes that do not typically experience congestion, network switches, and nodes that do not typically experience
treating NQB marked traffic the same as "Default" may be sufficient congestion, treating NQB marked traffic the same as "Default" may be
to preserve latency performance for NQB traffic. sufficient to preserve latency performance for NQB traffic.
5.1. End-to-end usage and DSCP Re-marking 5.1. End-to-end usage and DSCP Re-marking
In contrast to some existing standard PHBs, many of which are In contrast to some existing standard PHBs, many of which are
typically only meaningful within a DiffServ Domain (e.g. an AS or an typically only meaningful within a DiffServ Domain (e.g. an AS or an
enterprise network), this PHB is expected to be used end-to-end enterprise network), this PHB is expected to be used end-to-end
across the Internet, wherever suitable operator agreements apply. across the Internet, wherever suitable operator agreements apply.
Under the [RFC2474] model, this requires that the corresponding DSCP Under the [RFC2474] model, this requires that the corresponding DSCP
is recognized by all operators and mapped across their boundaries is recognized by all operators and mapped across their boundaries
accordingly. accordingly.
Some network operators typically bleach (zero out) the DiffServ field Absent an explicit agreement to the contrary, networks that support
on ingress into their network [Custura][Barik], and in some cases the NQB PHB SHOULD preserve a DSCP marking distinction between NQB
apply their own DSCP for internal usage. Bleaching the NQB DSCP is traffic and Default traffic when forwarding via an interconnect from
not expected to cause harm to default traffic, but it will severely or to another network. To facilitate the default treatment of NQB
limit the ability to provide NQB treatment end-to-end. Absent an traffic in backbones and core networks, networks SHOULD remap NQB
explicit agreement to the contrary, networks that support the NQB PHB traffic (DSCP 42) to DSCP 2 prior to interconnection, unless agreed
SHOULD preserve a DSCP marking distinction between NQB traffic and otherwise between the interconnecting partners. The fact that this
Default traffic when forwarding via an interconnect from or to PHB is intended for end-to-end usage does not preclude networks from
another network. To facilitate the default treatment of NQB traffic mapping the NQB DSCP to a value other than 42 or 2 for internal
in backbones and core networks, networks SHOULD remap NQB traffic usage, as long as the appropriate NQB DSCP is restored when
(DSCP 42) to DSCP 2 prior to interconnection, unless agreed otherwise forwarding to another network. Additionally, it is not precluded for
between the interconnecting partners. The fact that this DSCP is
intended for end-to-end usage does not preclude networks from mapping
the NQB DSCP to a value other than 42 or 2 for internal usage, as
long as the appropriate NQB DSCP is restored when forwarding to
another network. Additionally, it is not precluded for
interconnecting networks to negotiate (via an SLA or some other interconnecting networks to negotiate (via an SLA or some other
agreement) a different DSCP to use to signal NQB across the agreement) a different DSCP to use to signal NQB across the
interconnect. interconnect.
In order to enable interoperability with WiFi equipment (as discussed In order to enable interoperability with WiFi equipment, networks
in Section 11.3) networks SHOULD remap NQB traffic (e.g. DSCP 2) to SHOULD remap NQB traffic (e.g. DSCP 2) to DSCP 42 prior to a
DSCP 42 prior to a customer access link. customer access link, subject to the safeguards described in
Section 11.3.
Reports on existing deployments of DSCP manipulation [Custura][Barik] Thus, this document recommends two DSCPs to designate NQB, the value
categorize the remarking behaviors into the following six policies: 42 for use by hosts and in WiFi networks, and the value 2 for use
bleach all traffic (set DSCP to zero), set the top three bits (the across network interconnections.
former Precedence bits) on all traffic to 0b000, 0b001, or 0b010, set
the low three bits on all traffic to 0b000, or remark all traffic to Some network operators typically bleach (zero out) the DiffServ field
a particular (non-zero) DSCP value. on ingress into their network [Custura][Barik], and in some cases
apply their own DSCP for internal usage. Bleaching the NQB DSCP is
not expected to cause harm to default traffic, but it will severely
limit the ability to provide NQB treatment end-to-end. Reports on
existing deployments of DSCP manipulation [Custura][Barik] categorize
the remarking behaviors into the following six policies: bleach all
traffic (set DSCP to zero), set the top three bits (the former
Precedence bits) on all traffic to 0b000, 0b001, or 0b010, set the
low three bits on all traffic to 0b000, or remark all traffic to a
particular (non-zero) DSCP value.
Regarding the DSCP value of 42, there were no observations of DSCP Regarding the DSCP value of 42, there were no observations of DSCP
manipulation reported in which traffic was marked 42 by any of these manipulation reported in which traffic was marked 42 by any of these
policies. Thus it appears that these remarking policies would be policies. Thus it appears that these remarking policies would be
unlikely to result in QB traffic being marked as NQB (42). In terms unlikely to result in QB traffic being marked as NQB (42). In terms
of the fate of NQB-marked traffic that is subjected to one of these of the fate of NQB-marked traffic that is subjected to one of these
policies, the result would be that NQB marked traffic would be policies, the result would be that NQB marked traffic would be
indistinguishable from some subset (possibly all) of other traffic. indistinguishable from some subset (possibly all) of other traffic.
In the policies where all traffic is remarked using the same (zero or In the policies where all traffic is remarked using the same (zero or
non-zero) DSCP, the ability for a subsequent network hop to non-zero) DSCP, the ability for a subsequent network hop to
skipping to change at page 9, line 12 skipping to change at page 9, line 23
building traffic separate from the queue used for queue-building building traffic separate from the queue used for queue-building
traffic. traffic.
NQB traffic, in aggregate, SHOULD NOT be rate limited or rate policed NQB traffic, in aggregate, SHOULD NOT be rate limited or rate policed
separately from queue-building traffic of equivalent importance. separately from queue-building traffic of equivalent importance.
The NQB queue SHOULD be given equal priority compared to queue- The NQB queue SHOULD be given equal priority compared to queue-
building traffic of equivalent importance. The node SHOULD provide a building traffic of equivalent importance. The node SHOULD provide a
scheduler that allows QB and NQB traffic of equivalent importance to scheduler that allows QB and NQB traffic of equivalent importance to
share the link in a fair manner, e.g. a deficit round-robin scheduler share the link in a fair manner, e.g. a deficit round-robin scheduler
with equal weights. with equal weights. Compliance with these recommendations helps to
ensure that there are no incentives for QB traffic to be mismarked as
NQB.
A node supporting the NQB PHB SHOULD treat traffic marked as Default A node supporting the NQB PHB SHOULD treat traffic marked as Default
(DSCP=0) as QB traffic having equivalent importance to the NQB marked (DSCP=0) as QB traffic having equivalent importance to the NQB marked
traffic. A node supporting the NQB DSCP MUST support the ability to traffic. A node supporting the NQB DSCP MUST support the ability to
configure the classification criteria that are used to identify QB configure the classification criteria that are used to identify QB
and NQB traffic having equivalent importance. and NQB traffic having equivalent importance.
The NQB queue SHOULD have a buffer size that is significantly smaller The NQB queue SHOULD have a buffer size that is significantly smaller
than the buffer provided for QB traffic. It is expected that most QB than the buffer provided for QB traffic. It is expected that most QB
traffic is optimized to make use of a relatively deep buffer (e.g. on traffic is optimized to make use of a relatively deep buffer (e.g. on
skipping to change at page 9, line 47 skipping to change at page 10, line 11
To prevent this situation from harming the performance of the real To prevent this situation from harming the performance of the real
NQB flows, network elements that support differentiating NQB traffic NQB flows, network elements that support differentiating NQB traffic
SHOULD support a "traffic protection" function that can identify QB SHOULD support a "traffic protection" function that can identify QB
flows that are mismarked as NQB, and reclassify those flows/packets flows that are mismarked as NQB, and reclassify those flows/packets
to the QB queue. Such a function SHOULD be implemented in an to the QB queue. Such a function SHOULD be implemented in an
objective and verifiable manner, basing its decisions upon the objective and verifiable manner, basing its decisions upon the
behavior of the flow rather than on application-layer constructs. behavior of the flow rather than on application-layer constructs.
One example algorithm can be found in One example algorithm can be found in
[I-D.briscoe-docsis-q-protection]. There are some situations where [I-D.briscoe-docsis-q-protection]. There are some situations where
such function may not be necessary. For example, a network element such function may not be necessary. For example, a network element
designed for use in controlled environments, e.g. enterprise LAN may designed for use in controlled environments (e.g. enterprise LAN) may
not require a traffic protection function. Similarly, flow queueing not require a traffic protection function. Similarly, flow queueing
systems obviate the need for an explicit traffic protection function. systems obviate the need for an explicit traffic protection function.
Additionally, some networks may prefer to police the application of Additionally, some networks may prefer to police the application of
the NQB DSCP at the ingress edge, so that in-network traffic the NQB DSCP at the ingress edge, so that in-network traffic
protection is not needed. protection is not needed.
7. Impact on Higher Layer Protocols 7. Impact on Higher Layer Protocols
Network elements that support the NQB PHB and that support traffic Network elements that support the NQB PHB and that support traffic
protection as discussed in the previous section introduce the protection as discussed in the previous section introduce the
skipping to change at page 10, line 34 skipping to change at page 10, line 47
describes a "uniform model" in which the inner DSCP is copied to the describes a "uniform model" in which the inner DSCP is copied to the
outer header at encapsulation, and the outer DSCP is copied to the outer header at encapsulation, and the outer DSCP is copied to the
inner header at decapsulation. It also describes a "pipe model" in inner header at decapsulation. It also describes a "pipe model" in
which the outer DSCP is not copied to the inner header at which the outer DSCP is not copied to the inner header at
decapsulation. Both models can be used in conjunction with the NQB decapsulation. Both models can be used in conjunction with the NQB
PHB. In the case of the pipe model, any DSCP manipulation (re- PHB. In the case of the pipe model, any DSCP manipulation (re-
marking) of the outer header by intermediate nodes would be discarded marking) of the outer header by intermediate nodes would be discarded
at tunnel egress, potentially improving the possibility of achieving at tunnel egress, potentially improving the possibility of achieving
NQB treatment in subsequent nodes. NQB treatment in subsequent nodes.
As is discussed in [RFC2983] tunnel protocols that are sensitive to As is discussed in [RFC2983], tunnel protocols that are sensitive to
reordering can result in undesirable interactions if multiple DSCP reordering can result in undesirable interactions if multiple DSCP
PHBs are signaled for traffic within a tunnel instance. This is true PHBs are signaled for traffic within a tunnel instance. This is true
for NQB marked traffic as well. If a tunnel contains a mix of QB and for NQB marked traffic as well. If a tunnel contains a mix of QB and
NQB traffic, and this is reflected in the outer DSCP in a network NQB traffic, and this is reflected in the outer DSCP in a network
that supports the NQB PHB, it would be necessary to avoid a that supports the NQB PHB, it would be necessary to avoid a
reordering-sensitive tunnel protocol in order to avoid these reordering-sensitive tunnel protocol in order to avoid these
undesirable interactions. undesirable interactions.
9. Relationship to L4S 9. Relationship to L4S
skipping to change at page 12, line 11 skipping to change at page 12, line 30
QCI 7, in addition to the default EPS bearer; or a Data Radio Bearer QCI 7, in addition to the default EPS bearer; or a Data Radio Bearer
with 5QI 7 in a 5G system (see Table 5.7.4-1: Standardized 5QI to QoS with 5QI 7 in a 5G system (see Table 5.7.4-1: Standardized 5QI to QoS
characteristics mapping in [SA-5G]). characteristics mapping in [SA-5G]).
A packet carrying the NQB DSCP SHOULD be routed through the dedicated A packet carrying the NQB DSCP SHOULD be routed through the dedicated
low-latency EPS bearer. A packet that has no associated NQB marking low-latency EPS bearer. A packet that has no associated NQB marking
SHOULD be routed through the default EPS bearer. SHOULD be routed through the default EPS bearer.
11.3. WiFi Networks 11.3. WiFi Networks
WiFi networking equipment compliant with 802.11e generally supports WiFi networking equipment compliant with 802.11e/n/ac generally
either four or eight transmit queues and four sets of associated supports either four or eight transmit queues and four sets of
Enhanced Multimedia Distributed Control Access (EDCA) parameters associated Enhanced Multimedia Distributed Control Access (EDCA)
(corresponding to the four WiFi Multimedia (WMM) Access Categories) parameters (corresponding to the four WiFi Multimedia (WMM) Access
that are used to enable differentiated media access characteristics. Categories) that are used to enable differentiated media access
characteristics.
In addition to the requirements provided in other sections of this
document, to support the NQB PHB, WiFi equipment SHOULD map the NQB
codepoint 42 into a separate queue that shares an Access Category
with default traffic (i.e. the Best Effort Access Category).
While some WiFi equipment may be capable (in some cases via firmware While some WiFi equipment may be capable (in some cases via firmware
update) of supporting the NQB PHB requirements by providing a update) of supporting the NQB PHB requirements, many currently
separate queue for NQB marked traffic that shares an Access Category deployed devices cannot be configured in this way. As a result the
with default traffic, many currently deployed devices cannot be remainder of this section discusses interoperability with these
configured in this way. existing WiFi networks, as opposed to PHB compliance.
Implementations typically utilize the IP DSCP field to select a WiFi implementations typically utilize the IP DSCP field to select a
transmit queue, but should be considered as Non-Differentiated transmit queue, but should be considered as Non-Differentiated
Services-Compliant Nodes as described in Section 4 of [RFC2475] Services-Compliant Nodes as described in Section 4 of [RFC2475]
because in widely deployed WiFi networks, this transmit queue because in widely deployed WiFi networks, this transmit queue
selection is a local implementation characteristic that is not part selection is a local implementation characteristic that is not part
of a consistently operated DiffServ domain or region. As a result of a consistently operated DiffServ domain or region. As discussed
this document discusses interoperability with these existing WiFi in [RFC8325], most existing WiFi implementations use a default DSCP
networks, in addition to PHB compliance. to User Priority mapping that utilizes the most significant three
bits of the DiffServ Field to select "User Priority" which is then
As discussed in [RFC8325], most existing WiFi implementations use a mapped to the four WMM Access Categories. [RFC8325] also provides an
default DSCP to User Priority mapping that utilizes the most alternative mapping that more closely aligns with the DSCP
significant three bits of the DiffServ Field to select "User recommendations provided by the IETF.
Priority" which is then mapped to the four WMM Access Categories. In
order to increase the likelihood that NQB traffic is provided a
separate queue from QB traffic in existing WiFi equipment, the 42
code point is preferred for NQB. This would map NQB to UP_5 which is
in the "Video" Access Category. Similarly, systems that utilize
[RFC8325], SHOULD map the NQB code point to UP_5 in the "Video"
Access Category.
While the DSCP to User Priority mapping can enable WiFi systems to In order to increase the likelihood that NQB traffic is provided a
support the NQB PHB requirement for segregated queuing, many separate queue from QB traffic in existing WiFi equipment that uses
currently deployed WiFi systems may not be capable of supporting the the default mapping, the 42 code point is recommended for NQB. This
remaining NQB PHB requirements in Section 6. This is discussed maps NQB to UP_5 which is in the "Video" Access Category. Similarly,
further below. systems that utilize [RFC8325], SHOULD map the recommended NQB code
point 42 to UP_5 in the "Video" Access Category. While this DSCP to
User Priority mapping can enable WiFi systems to support the NQB PHB
requirement for segregated queuing, many currently deployed WiFi
systems may not be capable of supporting the remaining NQB PHB
requirements in Section 6. This is discussed further below.
Existing WiFi devices are unlikely to support a traffic protection Existing WiFi devices are unlikely to support a traffic protection
algorithm, so traffic mismarked as NQB is not likely to be detected algorithm, so traffic mismarked as NQB is not likely to be detected
and remedied by such devices. and remedied by such devices.
Furthermore, in their default configuration, existing WiFi devices Furthermore, in their default configuration, existing WiFi devices
utilize EDCA parameters that result in statistical prioritization of utilize EDCA parameters that result in statistical prioritization of
the "Video" Access Category above the "Best Effort" Access Category. the "Video" Access Category above the "Best Effort" Access Category.
If left unchanged, this would violate the NQB PHB requirement for If left unchanged, this would violate the NQB PHB requirement for
equal prioritization, and could erode the principle of alignment of equal prioritization, and could erode the principle of alignment of
incentives. In order to preserve the incentives principle, WiFi incentives. In order to preserve the incentives principle for NQB,
systems SHOULD configure the EDCA parameters for the Video Access WiFi systems SHOULD configure the EDCA parameters for the Video
Category to match those of the Best Effort Access Category. Access Category to match those of the Best Effort Access Category.
In cases where a network operator is delivering traffic into an In cases where a network operator is delivering traffic into an
unmanaged WiFi network outside of their control (e.g. a residential unmanaged WiFi network outside of their control (e.g. a residential
ISP delivering traffic to a customer's home network), the network ISP delivering traffic to a customer's home network), the network
operator should presume that the existing WiFi equipment does not operator should presume that the existing WiFi equipment does not
support the safeguards that are provided by the NQB PHB requirements, support the safeguards that are provided by the NQB PHB requirements,
and thus should take precautions to prevent issues. When the data and thus should take precautions to prevent issues. When the data
rate of the access network segment is less than the expected data rate of the access network segment is less than the expected data
rate of the WiFi network, this is unlikely to be an issue. However, rate of the WiFi network, this is unlikely to be an issue. However,
if the access network rate exceeds the expected rate of the WiFi if the access network rate exceeds the expected rate of the WiFi
network, the operator SHOULD deploy a policing function on NQB marked network, the operator SHOULD deploy a policing function on NQB marked
traffic that minimizes the potential for starvation of traffic marked traffic that minimizes the potential for negative impacts on traffic
Default, for example by limiting the rate of such traffic to a set marked Default, for example by limiting the rate of such traffic to a
fraction of the customer's service rate. set fraction of the customer's service rate.
As an additional safeguard, and to prevent the inadvertent As an additional safeguard, and to prevent the inadvertent
introduction of problematic traffic into unmanaged WiFi networks, introduction of problematic traffic into unmanaged WiFi networks,
network equipment that is intended to deliver traffic into unmanaged network equipment that is intended to deliver traffic into unmanaged
WiFi networks (e.g. an access network gateway for a residential ISP) WiFi networks (e.g. an access network gateway for a residential ISP)
MUST by default ensure that NQB traffic is marked with a DSCP that MUST by default ensure that NQB traffic is marked with a DSCP that
selects the "Best Effort" Access Category. Such equipment MUST selects the "Best Effort" Access Category. Such equipment MUST
support the ability to configure the remapping, so that (when support the ability to configure the remapping, so that (when
appropriate safeguards are in place) traffic can be delivered as NQB- appropriate safeguards are in place) traffic can be delivered as NQB-
marked. marked.
skipping to change at page 14, line 42 skipping to change at page 15, line 21
[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", ITC 30, September 2018. Study", ITC 30, September 2018.
[Custura] Custura, A., Venne, A., and G. Fairhurst, "Exploring DSCP [Custura] Custura, A., Venne, A., and G. Fairhurst, "Exploring DSCP
modification pathologies in mobile edge networks", TMA , modification pathologies in mobile edge networks", TMA ,
2017. 2017.
[I-D.briscoe-docsis-q-protection] [I-D.briscoe-docsis-q-protection]
Briscoe, B. and G. White, "Queue Protection to Preserve Briscoe, B. and G. White, "Queue Protection to Preserve
Low Latency", draft-briscoe-docsis-q-protection-00 (work Low Latency", Work in Progress, Internet-Draft, draft-
in progress), July 2019. briscoe-docsis-q-protection-00, 8 July 2019,
<http://www.ietf.org/internet-drafts/draft-briscoe-docsis-
q-protection-00.txt>.
[I-D.ietf-tsvwg-aqm-dualq-coupled] [I-D.ietf-tsvwg-aqm-dualq-coupled]
Schepper, K., Briscoe, B., and G. White, "DualQ Coupled Schepper, K., Briscoe, B., and G. White, "DualQ Coupled
AQMs for Low Latency, Low Loss and Scalable Throughput AQMs for Low Latency, Low Loss and Scalable Throughput
(L4S)", draft-ietf-tsvwg-aqm-dualq-coupled-13 (work in (L4S)", Work in Progress, Internet-Draft, draft-ietf-
progress), November 2020. tsvwg-aqm-dualq-coupled-13, 15 November 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-aqm-
dualq-coupled-13.txt>.
[I-D.ietf-tsvwg-ecn-l4s-id] [I-D.ietf-tsvwg-ecn-l4s-id]
Schepper, K. and B. Briscoe, "Identifying Modified Schepper, K. and B. Briscoe, "Identifying Modified
Explicit Congestion Notification (ECN) Semantics for Explicit Congestion Notification (ECN) Semantics for
Ultra-Low Queuing Delay (L4S)", draft-ietf-tsvwg-ecn-l4s- Ultra-Low Queuing Delay (L4S)", Work in Progress,
id-12 (work in progress), November 2020. Internet-Draft, draft-ietf-tsvwg-ecn-l4s-id-12, 15
November 2020, <http://www.ietf.org/internet-drafts/draft-
ietf-tsvwg-ecn-l4s-id-12.txt>.
[I-D.ietf-tsvwg-l4s-arch] [I-D.ietf-tsvwg-l4s-arch]
Briscoe, B., Schepper, K., Bagnulo, M., and G. White, "Low Briscoe, B., Schepper, K., Bagnulo, M., and G. White, "Low
Latency, Low Loss, Scalable Throughput (L4S) Internet Latency, Low Loss, Scalable Throughput (L4S) Internet
Service: Architecture", draft-ietf-tsvwg-l4s-arch-08 (work Service: Architecture", Work in Progress, Internet-Draft,
in progress), November 2020. draft-ietf-tsvwg-l4s-arch-08, 15 November 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-l4s-
arch-08.txt>.
[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>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
 End of changes. 32 change blocks. 
101 lines changed or deleted 122 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/