draft-ietf-tsvwg-le-phb-04.txt   draft-ietf-tsvwg-le-phb-05.txt 
Internet Engineering Task Force R. Bless Internet Engineering Task Force R. Bless
Internet-Draft Karlsruhe Institute of Technology (KIT) Internet-Draft Karlsruhe Institute of Technology (KIT)
Obsoletes: 3662 (if approved) March 5, 2018 Obsoletes: 3662 (if approved) July 3, 2018
Updates: 4594,8325 (if approved) Updates: 4594,8325 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: September 6, 2018 Expires: January 4, 2019
A Lower Effort Per-Hop Behavior (LE PHB) A Lower Effort Per-Hop Behavior (LE PHB)
draft-ietf-tsvwg-le-phb-04 draft-ietf-tsvwg-le-phb-05
Abstract Abstract
This document specifies properties and characteristics of a Lower This document specifies properties and characteristics of a Lower
Effort (LE) per-hop behavior (PHB). The primary objective of this LE Effort (LE) per-hop behavior (PHB). The primary objective of this LE
PHB is to protect best-effort (BE) traffic (packets forwarded with PHB is to protect best-effort (BE) traffic (packets forwarded with
the default PHB) from LE traffic in congestion situations, i.e., when the default PHB) from LE traffic in congestion situations, i.e., when
resources become scarce, best-effort traffic has precedence over LE resources become scarce, best-effort traffic has precedence over LE
traffic and may preempt it. There are numerous uses for this PHB, traffic and may preempt it. Alternatively, packets forwarded by the
e.g., for background traffic of low precedence, such as bulk data LE PHB can be associated with a scavenger service class, i.e., they
transfers with low priority in time, non time-critical backups, scavenge otherwise unused resources only. There are numerous uses
larger software updates, web search engines while gathering for this PHB, e.g., for background traffic of low precedence, such as
bulk data transfers with low priority in time, non time-critical
backups, larger software updates, web search engines while gathering
information from web servers and so on. This document recommends a information from web servers and so on. This document recommends a
standard DSCP value for the LE PHB. This specification updates the standard DSCP value for the LE PHB. This specification obsoletes RFC
DSCP recommended in RFC 4594 and RFC 8325 to use the DSCP assigned in 3662 and updates the DSCP recommended in RFC 4594 and RFC 8325 to use
this specification. the DSCP assigned in this specification.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://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 September 6, 2018. This Internet-Draft will expire on January 4, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
skipping to change at page 2, line 41 skipping to change at page 2, line 41
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3
4. PHB Description . . . . . . . . . . . . . . . . . . . . . . . 5 4. PHB Description . . . . . . . . . . . . . . . . . . . . . . . 5
5. Traffic Conditioning Actions . . . . . . . . . . . . . . . . 6 5. Traffic Conditioning Actions . . . . . . . . . . . . . . . . 6
6. Recommended DS Codepoint . . . . . . . . . . . . . . . . . . 6 6. Recommended DS Codepoint . . . . . . . . . . . . . . . . . . 6
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 7 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 7
8. Remarking to other DSCPs/PHBs . . . . . . . . . . . . . . . . 7 8. Remarking to other DSCPs/PHBs . . . . . . . . . . . . . . . . 8
9. The Update to RFC 4594 . . . . . . . . . . . . . . . . . . . 8 9. The Update to RFC 4594 . . . . . . . . . . . . . . . . . . . 8
10. The Update to RFC 8325 . . . . . . . . . . . . . . . . . . . 10 10. The Update to RFC 8325 . . . . . . . . . . . . . . . . . . . 10
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 11. The Update to draft-ietf-tsvwg-rtcweb-qos . . . . . . . . . . 10
12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 13. Security Considerations . . . . . . . . . . . . . . . . . . . 12
13.1. Normative References . . . . . . . . . . . . . . . . . . 11 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
13.2. Informative References . . . . . . . . . . . . . . . . . 11 14.1. Normative References . . . . . . . . . . . . . . . . . . 12
Appendix A. History of the LE PHB . . . . . . . . . . . . . . . 13 14.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 13 Appendix A. History of the LE PHB . . . . . . . . . . . . . . . 15
Appendix C. Change History . . . . . . . . . . . . . . . . . . . 13 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 15
Appendix D. Note to RFC Editor . . . . . . . . . . . . . . . . . 15 Appendix C. Change History . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 Appendix D. Note to RFC Editor . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
This document defines a Differentiated Services per-hop behavior This document defines a Differentiated Services per-hop behavior
[RFC2474] called "Lower Effort" (LE), which is intended for traffic [RFC2474] called "Lower Effort" (LE), which is intended for traffic
of sufficiently low urgency that all other traffic takes precedence of sufficiently low urgency that all other traffic takes precedence
over the LE traffic in consumption of network link bandwidth. Low over the LE traffic in consumption of network link bandwidth. Low
urgency traffic has a low priority for timely forwarding, which does urgency traffic has a low priority for timely forwarding, which does
not necessarily imply that it is generally of minor importance. From not necessarily imply that it is generally of minor importance. From
this viewpoint, it can be considered as a network equivalent to a this viewpoint, it can be considered as a network equivalent to a
background priority for processes in an operating system. There may background priority for processes in an operating system. There may
or may not be memory (buffer) resources allocated for this type of or may not be memory (buffer) resources allocated for this type of
traffic. traffic.
Some networks carry traffic for which delivery is considered Some networks carry traffic for which delivery is considered
optional; that is, packets of this type of traffic ought to consume optional; that is, packets of this type of traffic ought to consume
network resources only when no other traffic is present. network resources only when no other traffic is present. In this
Alternatively, the effect of this type of traffic on all other point of view, packets forwarded by the LE PHB scavenge otherwise
network traffic is strictly limited ("no harm" property). This is unused resources only, which led to the name "scavenger service" in
distinct from "best-effort" (BE) traffic since the network makes no early Internet2 deployments (Appendix A). Other commonly used names
commitment to deliver LE packets. In contrast, BE traffic receives for LE PHB type services are "Lower-than-best-effort" or "Less-than-
an implied "good faith" commitment of at least some available network best-effort". Alternatively, the effect of this type of traffic on
resources. This document proposes a Lower Effort Differentiated all other network traffic is strictly limited ("no harm" property).
Services per-hop behavior (LE PHB) for handling this "optional" This is distinct from "best-effort" (BE) traffic since the network
traffic in a differentiated services node. makes no commitment to deliver LE packets. In contrast, BE traffic
receives an implied "good faith" commitment of at least some
available network resources. This document proposes a Lower Effort
Differentiated Services per-hop behavior (LE PHB) for handling this
"optional" traffic in a differentiated services node.
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. Applicability 3. Applicability
skipping to change at page 4, line 7 skipping to change at page 4, line 12
even starvation (i.e., long interruptions due to significant or even even starvation (i.e., long interruptions due to significant or even
complete packet loss). Therefore, an application sending an LE complete packet loss). Therefore, an application sending an LE
marked flow needs to be able to tolerate short or (even very) long marked flow needs to be able to tolerate short or (even very) long
interruptions due to the presence of severe congestion conditions interruptions due to the presence of severe congestion conditions
during the transmission of the flow. Thus, there ought to be an during the transmission of the flow. Thus, there ought to be an
expectation that packets of the LE PHB could be excessively delayed expectation that packets of the LE PHB could be excessively delayed
or dropped when any other traffic is present. The LE PHB is suitable or dropped when any other traffic is present. The LE PHB is suitable
for sending traffic of low urgency across a Differentiated Services for sending traffic of low urgency across a Differentiated Services
(DS) domain or DS region. (DS) domain or DS region.
LE traffic SHOULD be congestion controlled (i.e., use a congestion Just like best-effort traffic, LE traffic SHOULD be congestion
controlled transport or implement a congestion control method controlled (i.e., use a congestion controlled transport or implement
[RFC8085]). Since LE traffic could be starved completely for a an appropriate congestion control method [RFC8085]). Since LE
longer period of time, transport protocols or applications (and their traffic could be starved completely for a longer period of time,
related congestion control mechanisms) SHOULD be able to detect and transport protocols or applications (and their related congestion
react to such a situation and ought to resume the transfer as soon as control mechanisms) SHOULD be able to detect and react to such a
possible. Congestion control is not only useful to let the flows situation and ought to resume the transfer as soon as possible.
within the LE behavior aggregate adapt to the available bandwidth Congestion control is not only useful to let the flows within the LE
that may be highly fluctuating, but is also essential if LE traffic behavior aggregate adapt to the available bandwidth that may be
is mapped to the default PHB in DS domains that do not support LE. highly fluctuating, but is also essential if LE traffic is mapped to
the default PHB in DS domains that do not support LE.
Use of the LE PHB might assist a network operator in moving certain Use of the LE PHB might assist a network operator in moving certain
kinds of traffic or users to off-peak times. Alternatively, or in kinds of traffic or users to off-peak times. Alternatively, or in
addition, packets can be designated for the LE PHB when the goal is addition, packets can be designated for the LE PHB when the goal is
to protect all other packet traffic from competition with the LE to protect all other packet traffic from competition with the LE
aggregate while not completely banning LE traffic from the network. aggregate while not completely banning LE traffic from the network.
An LE PHB SHOULD NOT be used for a customer's "normal internet" An LE PHB SHOULD NOT be used for a customer's "normal Internet"
traffic nor should packets be "downgraded" to the LE PHB instead of traffic nor should packets be "downgraded" to the LE PHB instead of
being dropped, particularly when the packets are unauthorized being dropped, particularly when the packets are unauthorized
traffic. The LE PHB is expected to have applicability in networks traffic. The LE PHB is expected to have applicability in networks
that have at least some unused capacity at certain periods. that have at least some unused capacity at certain periods.
The LE PHB allows networks to protect themselves from selected types The LE PHB allows networks to protect themselves from selected types
of traffic as a complement to giving preferential treatment to other of traffic as a complement to giving preferential treatment to other
selected traffic aggregates. LE ought not to be used for the general selected traffic aggregates. LE ought not to be used for the general
case of downgraded traffic, but could be used by design, e.g., to case of downgraded traffic, but could be used by design, e.g., to
protect an internal network from untrusted external traffic sources. protect an internal network from untrusted external traffic sources.
skipping to change at page 5, line 5 skipping to change at page 5, line 11
traffic, they will not harm traffic from non-LE behavior aggregates. traffic, they will not harm traffic from non-LE behavior aggregates.
A further related use case is mentioned in [RFC3754]: preliminary A further related use case is mentioned in [RFC3754]: preliminary
forwarding of non-admitted multicast traffic. forwarding of non-admitted multicast traffic.
There is no intrinsic reason to limit the applicability of the LE PHB There is no intrinsic reason to limit the applicability of the LE PHB
to any particular application or type of traffic. It is intended as to any particular application or type of traffic. It is intended as
an additional traffic engineering tool for network administrators. an additional traffic engineering tool for network administrators.
For instance, it can be used to fill protection capacity of For instance, it can be used to fill protection capacity of
transmission links that is otherwise unused. Some network providers transmission links that is otherwise unused. Some network providers
keep link utilization below 50% to ensure that all traffic is keep link utilization below 50% to ensure that all traffic is
forwarded without loss after rerouting caused by a link failure. LE forwarded without loss after rerouting caused by a link failure (cf.
marked traffic can utilize the normally unused capacity and will be Section 6 of [RFC3439]). LE marked traffic can utilize the normally
preempted automatically in case of link failure when 100% of the link unused capacity and will be preempted automatically in case of link
capacity is required for all other traffic. Ideally, applications failure when 100% of the link capacity is required for all other
mark their packets as LE traffic, since they know the urgency of traffic. Ideally, applications mark their packets as LE traffic,
flows. since they know the urgency of flows.
Example uses for the LE PHB: Example uses for the LE PHB:
o For traffic caused by world-wide web search engines while they o For traffic caused by world-wide web search engines while they
gather information from web servers. gather information from web servers.
o For software updates or dissemination of new releases of operating o For software updates or dissemination of new releases of operating
systems. systems.
o For reporting errors or telemetry data from operating systems or o For reporting errors or telemetry data from operating systems or
skipping to change at page 6, line 30 skipping to change at page 6, line 36
precedence of packets. There is no incentive for DS domains to precedence of packets. There is no incentive for DS domains to
distrust this initial marking, because letting LE traffic enter a DS distrust this initial marking, because letting LE traffic enter a DS
domain causes no harm. Thus, any policing such as limiting the rate domain causes no harm. Thus, any policing such as limiting the rate
of LE traffic is not necessary at the DS boundary. of LE traffic is not necessary at the DS boundary.
As for most other PHBs an initial classification and marking can be As for most other PHBs an initial classification and marking can be
also performed at the first DS boundary node according to the DS also performed at the first DS boundary node according to the DS
domain's own policies (e.g., as protection measure against untrusted domain's own policies (e.g., as protection measure against untrusted
sources). However, non-LE traffic (e.g., BE traffic) SHOULD NOT be sources). However, non-LE traffic (e.g., BE traffic) SHOULD NOT be
remarked to LE on a regular basis without consent or knowledge of the remarked to LE on a regular basis without consent or knowledge of the
user. See also remarks with respect to downgrading in Section 3. user. See also remarks with respect to downgrading in Section 3 and
Section 8.
6. Recommended DS Codepoint 6. Recommended DS Codepoint
The RECOMMENDED codepoint for the LE PHB is '000001'. The RECOMMENDED codepoint for the LE PHB is '000001'.
Earlier specifications [RFC4594] recommended to use CS1 as codepoint Earlier specifications [RFC4594] recommended to use CS1 as codepoint
(as mentioned in [RFC3662]). This is problematic since it may cause (as mentioned in [RFC3662]). This is problematic since it may cause
a priority inversion in DiffServ domains that treat CS1 as originally a priority inversion in DiffServ domains that treat CS1 as originally
proposed in [RFC2474], resulting in forwarding LE packets with higher proposed in [RFC2474], resulting in forwarding LE packets with higher
precedence than BE packets. Existing implementations SHOULD precedence than BE packets. Existing implementations SHOULD
transition to use the unambiguous LE codepoint '000001' whenever transition to use the unambiguous LE codepoint '000001' whenever
possible. possible.
This particular codepoint was chosen due to measurements on the This particular codepoint was chosen due to measurements on the
currently observable DSCP remarking behavior in the Internet. Since currently observable DSCP remarking behavior in the Internet
some network domains set the former IP precedence bits to zero, it is
possible that some other standardized DSCPs get mapped to the LE PHB [ietf99-secchi]. Since some network domains set the former IP
DSCP if it were taken from the DSCP standards action pool 1 (xxxxx0). precedence bits to zero, it is possible that some other standardized
DSCPs get mapped to the LE PHB DSCP if it were taken from the DSCP
standards action pool 1 (xxxxx0).
7. Deployment Considerations 7. Deployment Considerations
In order to enable LE support, DS nodes typically only need In order to enable LE support, DS nodes typically only need
o A BA classifier (Behavior Aggregate classifier, see [RFC2475]) o A BA classifier (Behavior Aggregate classifier, see [RFC2475])
that classifies packets according to the LE DSCP that classifies packets according to the LE DSCP
o A dedicated LE queue o A dedicated LE queue
skipping to change at page 8, line 9 skipping to change at page 8, line 15
8. Remarking to other DSCPs/PHBs 8. Remarking to other DSCPs/PHBs
"DSCP bleaching", i.e., setting the DSCP to '000000' (default PHB) is "DSCP bleaching", i.e., setting the DSCP to '000000' (default PHB) is
NOT RECOMMENDED for this PHB. This may cause effects that are in NOT RECOMMENDED for this PHB. This may cause effects that are in
contrast to the original intent in protecting BE traffic from LE contrast to the original intent in protecting BE traffic from LE
traffic (no harm property). In the case that a DS domain does not traffic (no harm property). In the case that a DS domain does not
support the LE PHB, its nodes SHOULD treat LE marked packets with the support the LE PHB, its nodes SHOULD treat LE marked packets with the
default PHB instead (by mapping the LE DSCP to the default PHB), but default PHB instead (by mapping the LE DSCP to the default PHB), but
they SHOULD do so without remarking to DSCP '000000'. The reason for they SHOULD do so without remarking to DSCP '000000'. The reason for
this is that later traversed DS domains may then have still the this is that later traversed DS domains may then have still the
possibility to treat such packets according the LE PHB. possibility to treat such packets according to the LE PHB.
Operators of DS domains that forward LE traffic within the BE Operators of DS domains that forward LE traffic within the BE
aggregate need to be aware of the implications, i.e., induced aggregate need to be aware of the implications, i.e., induced
congestion situations and quality-of-service degradation of the congestion situations and quality-of-service degradation of the
original BE traffic. In this case, the LE property of not harming original BE traffic. In this case, the LE property of not harming
other traffic is no longer fulfilled. To limit the impact in such other traffic is no longer fulfilled. To limit the impact in such
cases, traffic policing of the LE aggregate MAY be used. cases, traffic policing of the LE aggregate MAY be used.
In case LE marked packets are effectively carried within the default In case LE marked packets are effectively carried within the default
PHB (i.e., forwarded as best-effort traffic) they get a better PHB (i.e., forwarded as best-effort traffic) they get a better
forwarding treatment than expected. For some applications and forwarding treatment than expected. For some applications and
services, it is favorable if the transmission is finished earlier services, it is favorable if the transmission is finished earlier
than expected. However, in some cases it may be against the original than expected. However, in some cases it may be against the original
intention of the LE PHB user to strictly send the traffic only if intention of the LE PHB user to strictly send the traffic only if
otherwise unused resources are available, i.e., LE traffic may otherwise unused resources are available. In case LE traffic is
compete with BE traffic for the same resources and thus adversely mapped to the default PHB, LE traffic may compete with BE traffic for
affect the original BE aggregate. In some cases users want to be the same resources and thus adversely affect the original BE
sure that their LE marked traffic actually fulfills the "no harm" aggregate. Applications that want to ensure the lower precedence
property. Applications that want to ensure the lower precedence compared to BE traffic even in such cases SHOULD use additionally a
compared to BE traffic SHOULD use additionally a corresponding Lower- corresponding Lower-than-Best-Effort transport protocol [RFC6297],
than-Best-Effort transport protocol [RFC6297], e.g., LEDBAT e.g., LEDBAT [RFC6817].
[RFC6817].
A DS domain that still uses DSCP CS1 for marking LE traffic A DS domain that still uses DSCP CS1 for marking LE traffic
(including Low Priority-Data as defined in [RFC4594] or the old (including Low Priority-Data as defined in [RFC4594] or the old
definition in [RFC3662]) SHOULD remark traffic to the LE DSCP definition in [RFC3662]) SHOULD remark traffic to the LE DSCP
'000001' at the egress to the next DS domain. This increases the '000001' at the egress to the next DS domain. This increases the
probability that the DSCP is preserved end-to-end, whereas a CS1 probability that the DSCP is preserved end-to-end, whereas a CS1
marked packet may be remarked by the default DSCP if the next domain marked packet may be remarked by the default DSCP if the next domain
is applying DiffServ-intercon [RFC8100]. is applying DiffServ-intercon [RFC8100].
9. The Update to RFC 4594 9. The Update to RFC 4594
skipping to change at page 10, line 9 skipping to change at page 10, line 14
o This document removes the following line of RFC 4594, o This document removes the following line of RFC 4594,
Section 4.10: "The RECOMMENDED DSCP marking is CS1 (Class Selector Section 4.10: "The RECOMMENDED DSCP marking is CS1 (Class Selector
1)." and replaces this with the following text: "The RECOMMENDED 1)." and replaces this with the following text: "The RECOMMENDED
DSCP marking is LE (Lower Effort)." DSCP marking is LE (Lower Effort)."
10. The Update to RFC 8325 10. The Update to RFC 8325
Section 4.2.10 of RFC 8325 [RFC8325] specifies "therefore, it is Section 4.2.10 of RFC 8325 [RFC8325] specifies "therefore, it is
RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to UP 1" RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to UP 1"
which is updated to ""therefore, it is RECOMMENDED to map Low- which is updated to "therefore, it is RECOMMENDED to map Low-Priority
Priority Data traffic marked with LE DSCP or CS1 DSCP to UP 1 Data traffic marked with LE DSCP or CS1 DSCP to UP 1"
This update to RFC 8325 removes the following entry from figure 1: This update to RFC 8325 removes the following entry from figure 1:
+---------------+------+----------+-------------+--------------------+ +---------------+------+----------+-------------+--------------------+
| Low-Priority | CS1 | RFC 3662 | 1 | AC_BK (Background) | | Low-Priority | CS1 | RFC 3662 | 1 | AC_BK (Background) |
| Data | | | | | | Data | | | | |
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
and replaces this by the following entry: and replaces this by the following entry:
+---------------+------+----------+-------------+--------------------+ +---------------+------+----------+-------------+--------------------+
| Low-Priority | LE | RFCXXXX | 1 | AC_BK (Background) | | Low-Priority | LE | RFCXXXX | 1 | AC_BK (Background) |
| Data | | | | | | Data | | | | |
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
11. IANA Considerations 11. The Update to draft-ietf-tsvwg-rtcweb-qos
Section 5 of [I-D.ietf-tsvwg-rtcweb-qos] describes the Recommended
DSCP Values for WebRTC Applications
This update to [I-D.ietf-tsvwg-rtcweb-qos] replaces all occurences of
CS1 with LE in Table 1:
+------------------------+-------+------+-------------+-------------+
| Flow Type | Very | Low | Medium | High |
| | Low | | | |
+------------------------+-------+------+-------------+-------------+
| Audio | LE | DF | EF (46) | EF (46) |
| | (1) | (0) | | |
| | | | | |
| Interactive Video with | LE | DF | AF42, AF43 | AF41, AF42 |
| or without Audio | (1) | (0) | (36, 38) | (34, 36) |
| | | | | |
| Non-Interactive Video | LE | DF | AF32, AF33 | AF31, AF32 |
| with or without Audio | (1) | (0) | (28, 30) | (26, 28) |
| | | | | |
| Data | LE | DF | AF11 | AF21 |
| | (1) | (0) | | |
+------------------------+-------+------+-------------+-------------+
and updates the following paragraph:
"The above table assumes that packets marked with CS1 are treated as
"less than best effort", such as the LE behavior described in
[RFC3662]. However, the treatment of CS1 is implementation
dependent. If an implementation treats CS1 as other than "less than
best effort", then the actual priority (or, more precisely, the per-
hop-behavior) of the packets may be changed from what is intended.
It is common for CS1 to be treated the same as DF, so applications
and browsers using CS1 cannot assume that CS1 will be treated
differently than DF [RFC7657]. However, it is also possible per
[RFC2474] for CS1 traffic to be given better treatment than DF, thus
caution should be exercised when electing to use CS1. This is one of
the cases where marking packets using these recommendations can make
things worse."
as follows:
"The above table assumes that packets marked with LE are treated as
lower effort (i.e., "less than best effort"), such as the LE behavior
described in [RFCXXXX]. However, the treatment of LE is
implementation dependent. If an implementation treats LE as other
than "less than best effort", then the actual priority (or, more
precisely, the per- hop-behavior) of the packets may be changed from
what is intended. It is common for LE to be treated the same as DF,
so applications and browsers using LE cannot assume that LE will be
treated differently than DF [RFC7657]."
12. IANA Considerations
This document assigns the Differentiated Services Field Codepoint This document assigns the Differentiated Services Field Codepoint
(DSCP) '000001' from the Differentiated Services Field Codepoints (DSCP) '000001' from the Differentiated Services Field Codepoints
(DSCP) registry (https://www.iana.org/assignments/dscp-registry/dscp- (DSCP) registry (https://www.iana.org/assignments/dscp-registry/dscp-
registry.xhtml) (Pool 3, Codepoint Space xxxx01, Standards Action) to registry.xhtml) (Pool 3, Codepoint Space xxxx01, Standards Action) to
the LE PHB. This document suggests to use a DSCP from Pool 3 in the LE PHB. This document suggests to use a DSCP from Pool 3 in
order to avoid problems for other PHB marked flows to become order to avoid problems for other PHB marked flows to become
accidentally remarked as LE PHB, e.g., due to partial DSCP bleaching. accidentally remarked as LE PHB, e.g., due to partial DSCP bleaching.
See [I-D.ietf-tsvwg-iana-dscp-registry] for the request to re- See [I-D.ietf-tsvwg-iana-dscp-registry] for the request to re-
classify Pool 3 for Standards Action. classify Pool 3 for Standards Action.
skipping to change at page 10, line 48 skipping to change at page 12, line 27
IANA is requested to update the registry as follows: IANA is requested to update the registry as follows:
o Name: LE o Name: LE
o Value (Binary): 000001 o Value (Binary): 000001
o Value (Decimal): 1 o Value (Decimal): 1
o Reference: [RFC number of this memo] o Reference: [RFC number of this memo]
12. Security Considerations 13. Security Considerations
There are no specific security exposures for this PHB. Since it There are no specific security exposures for this PHB. Since it
defines a new class of low forwarding priority, remarking other defines a new class of low forwarding priority, remarking other
traffic as LE traffic may lead to quality-of-service degradation of traffic as LE traffic may lead to quality-of-service degradation of
such traffic. Thus, any attacker that is able to modify the DSCP of such traffic. Thus, any attacker that is able to modify the DSCP of
a packet to LE may carry out a downgrade attack. See the general a packet to LE may carry out a downgrade attack. See the general
security considerations in [RFC2474] and [RFC2475]. security considerations in [RFC2474] and [RFC2475].
With respect to privacy, an attacker could use the information from With respect to privacy, an attacker could use the information from
the DSCP to infer that the transferred (probably even encrypted) the DSCP to infer that the transferred (probably even encrypted)
content is considered of low priority or low urgency by a user, in content is considered of low priority or low urgency by a user, in
case the DSCP was set on the user's request. However, this disclosed case the DSCP was set on the user's request. However, this disclosed
information is only useful if some form of identification happened at information is only useful if some form of identification happened at
the same time, see [RFC6973] for further details on general privacy the same time, see [RFC6973] for further details on general privacy
threats. threats.
13. References 14. References
13.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://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,
<http://www.rfc-editor.org/info/rfc2474>. <http://www.rfc-editor.org/info/rfc2474>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<http://www.rfc-editor.org/info/rfc2475>. <http://www.rfc-editor.org/info/rfc2475>.
13.2. Informative References 14.2. Informative References
[carlberg-lbe-2001]
Carlberg, K., Gevros, P., and J. Crowcroft, "Lower than
best effort: a design and implementation", SIGCOMM
Computer Communications Review Volume 31, Issue 2
supplement, April 2001,
<https://doi.org/10.1145/844193.844208>.
[chown-lbe-2003]
Chown, T., Ferrari, T., Leinen, S., Sabatino, R., Simar,
N., and S. Venaas, "Less than Best Effort: Application
Scenarios and Experimental Results", In Proceedings of the
Second International Workshop on Quality of Service in
Multiservice IP Networks (QoS-IP 2003), Lecture Notes in
Computer Science, vol 2601. Springer, Berlin,
Heidelberg Pages 131-144, February 2003,
<https://doi.org/10.1007/3-540-36480-3_10>.
[draft-bless-diffserv-lbe-phb-00] [draft-bless-diffserv-lbe-phb-00]
Bless, R. and K. Wehrle, "A Lower Than Best-Effort Per-Hop Bless, R. and K. Wehrle, "A Lower Than Best-Effort Per-Hop
Behavior", draft-bless-diffserv-lbe-phb-00 (work in Behavior", draft-bless-diffserv-lbe-phb-00 (work in
progress), September 1999, <https://tools.ietf.org/html/ progress), September 1999, <https://tools.ietf.org/html/
draft-bless-diffserv-lbe-phb-00>. draft-bless-diffserv-lbe-phb-00>.
[I-D.ietf-tsvwg-iana-dscp-registry] [I-D.ietf-tsvwg-iana-dscp-registry]
Fairhurst, G., "IANA Assignment of DSCP Pool 3 (xxxx01) Fairhurst, G., "IANA Assignment of DSCP Pool 3 (xxxx01)
Values to require Publication of a Standards Track or Best Values to require Publication of a Standards Track or Best
Current Practice RFC", draft-ietf-tsvwg-iana-dscp- Current Practice RFC", draft-ietf-tsvwg-iana-dscp-
registry-00 (work in progress), February 2018. registry-08 (work in progress), June 2018.
[I-D.ietf-tsvwg-rtcweb-qos]
Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP
Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb-
qos-18 (work in progress), August 2016.
[ietf99-secchi]
Secchi, R., Venne, A., and A. Custura, "Measurements
concerning the DSCP for a LE PHB", Presentation held at
99th IETF Meeting, TSVWG, Prague , July 2017,
<https://datatracker.ietf.org/meeting/99/materials/slides-
99-tsvwg-sessb-31measurements-concerning-the-dscp-for-a-
le-phb-00>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<http://www.rfc-editor.org/info/rfc3168>. <http://www.rfc-editor.org/info/rfc3168>.
[RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural
Guidelines and Philosophy", RFC 3439,
DOI 10.17487/RFC3439, December 2002,
<https://www.rfc-editor.org/info/rfc3439>.
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
Per-Domain Behavior (PDB) for Differentiated Services", Per-Domain Behavior (PDB) for Differentiated Services",
RFC 3662, DOI 10.17487/RFC3662, December 2003, RFC 3662, DOI 10.17487/RFC3662, December 2003,
<http://www.rfc-editor.org/info/rfc3662>. <http://www.rfc-editor.org/info/rfc3662>.
[RFC3754] Bless, R. and K. Wehrle, "IP Multicast in Differentiated [RFC3754] Bless, R. and K. Wehrle, "IP Multicast in Differentiated
Services (DS) Networks", RFC 3754, DOI 10.17487/RFC3754, Services (DS) Networks", RFC 3754, DOI 10.17487/RFC3754,
April 2004, <http://www.rfc-editor.org/info/rfc3754>. April 2004, <http://www.rfc-editor.org/info/rfc3754>.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
skipping to change at page 12, line 36 skipping to change at page 14, line 49
2011, <http://www.rfc-editor.org/info/rfc6297>. 2011, <http://www.rfc-editor.org/info/rfc6297>.
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
"Low Extra Delay Background Transport (LEDBAT)", RFC 6817, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
DOI 10.17487/RFC6817, December 2012, DOI 10.17487/RFC6817, December 2012,
<http://www.rfc-editor.org/info/rfc6817>. <http://www.rfc-editor.org/info/rfc6817>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013, <https://www.rfc- DOI 10.17487/RFC6973, July 2013,
editor.org/info/rfc6973>. <https://www.rfc-editor.org/info/rfc6973>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection [RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection
Classes and Practice", RFC 8100, DOI 10.17487/RFC8100, Classes and Practice", RFC 8100, DOI 10.17487/RFC8100,
March 2017, <http://www.rfc-editor.org/info/rfc8100>. March 2017, <http://www.rfc-editor.org/info/rfc8100>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8325] Szigeti, T., Henry, J., and F. Baker, "Mapping Diffserv to [RFC8325] Szigeti, T., Henry, J., and F. Baker, "Mapping Diffserv to
IEEE 802.11", RFC 8325, DOI 10.17487/RFC8325, February IEEE 802.11", RFC 8325, DOI 10.17487/RFC8325, February
2018, <https://www.rfc-editor.org/info/rfc8325>. 2018, <https://www.rfc-editor.org/info/rfc8325>.
Appendix A. History of the LE PHB Appendix A. History of the LE PHB
A first version of this PHB was suggested by Roland Bless and Klaus A first version of this PHB was suggested by Roland Bless and Klaus
Wehrle in 1999 [draft-bless-diffserv-lbe-phb-00]. After some Wehrle in September 1999 [draft-bless-diffserv-lbe-phb-00], named "A
discussion in the DiffServ Working Group Brian Carpenter and Kathie Lower Than Best-Effort Per-Hop Behavior". After some discussion in
Nichols proposed a bulk handling per-domain behavior and believed a the DiffServ Working Group Brian Carpenter and Kathie Nichols
PHB was not necessary. Eventually, Lower Effort was specified as proposed a "bulk handling" per-domain behavior and believed a PHB was
per-domain behavior and finally became [RFC3662]. More detailed not necessary. Eventually, "Lower Effort" was specified as per-
domain behavior and finally became [RFC3662]. More detailed
information about its history can be found in Section 10 of information about its history can be found in Section 10 of
[RFC3662]. [RFC3662].
There are several other names in use for this type of PHB or
associated service classes. Well-known is the QBone Scavenger
Service (QBSS) that was proposed in March 2001 within the Internet2
QoS Working Group. Alternative names are "Lower-than-best-effort"
[carlberg-lbe-2001] or "Less-than-best-effort" [chown-lbe-2003].
Appendix B. Acknowledgments Appendix B. Acknowledgments
Since text is borrowed from earlier Internet-Drafts and RFCs the co- Since text is borrowed from earlier Internet-Drafts and RFCs the co-
authors of previous specifications are acknowledged here: Kathie authors of previous specifications are acknowledged here: Kathie
Nichols and Klaus Wehrle. David Black and Ruediger Geib provided Nichols and Klaus Wehrle. David Black, Gorry Fairhurst, and Ruediger
helpful comments and suggestions. Geib provided helpful comments and suggestions.
Appendix C. Change History Appendix C. Change History
This section briefly lists changes between Internet-Draft versions This section briefly lists changes between Internet-Draft versions
for convenience. for convenience.
Changes in Version 05:
o added scavenger service class into abstract
o added some more history
o added reference for "Myth of Over-Provisioning" in RFC3439 and
references to presentations w.r.t. codepoint choices
o added text to update draft-ietf-tsvwg-rtcweb-qos
o revised text on congestion control in case of remarking to BE
o added reference to DSCP measurement talk @IETF99
o small typo fixes
Changes in Version 04: Changes in Version 04:
o Several editorial changes according to review from Gorry Fairhurst o Several editorial changes according to review from Gorry Fairhurst
o Changed the section structure a bit (moved subsections 1.1 and 1.2 o Changed the section structure a bit (moved subsections 1.1 and 1.2
into own sections 3 and 7 respectively) into own sections 3 and 7 respectively)
o updated section 2 on requirements language o updated section 2 on requirements language
o added updates to RFC 8325 o added updates to RFC 8325
 End of changes. 31 change blocks. 
81 lines changed or deleted 203 lines changed or added

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