draft-ietf-tsvwg-le-phb-10.txt   rfc8622.txt 
Internet Engineering Task Force R. Bless Internet Engineering Task Force (IETF) R. Bless
Internet-Draft Karlsruhe Institute of Technology (KIT) Request for Comments: 8622 KIT
Obsoletes: 3662 (if approved) March 11, 2019 Obsoletes: 3662 June 2019
Updates: 4594,8325 (if approved) Updates: 4594, 8325
Intended status: Standards Track Category: Standards Track
Expires: September 12, 2019 ISSN: 2070-1721
A Lower Effort Per-Hop Behavior (LE PHB) for Differentiated Services A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services
draft-ietf-tsvwg-le-phb-10
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 Per-Hop Behavior (LE 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, BE traffic has precedence over LE traffic
traffic and may preempt it. Alternatively, packets forwarded by the and may preempt it. Alternatively, packets forwarded by the LE PHB
LE PHB can be associated with a scavenger service class, i.e., they can be associated with a scavenger service class, i.e., they scavenge
scavenge otherwise unused resources only. There are numerous uses otherwise-unused resources only. There are numerous uses for this
for this PHB, e.g., for background traffic of low precedence, such as PHB, e.g., for background traffic of low precedence, such as bulk
bulk data transfers with low priority in time, non time-critical data transfers with low priority in time, non-time-critical backups,
backups, larger software updates, web search engines while gathering 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 obsoletes RFC standard Differentiated Services Code Point (DSCP) value for the LE
3662 and updates the DSCP recommended in RFC 4594 and RFC 8325 to use PHB.
the DSCP assigned in this specification.
Status of This Memo This specification obsoletes RFC 3662 and updates the DSCP
recommended in RFCs 4594 and 8325 to use the DSCP assigned in this
specification.
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on September 12, 2019. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8622.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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/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
skipping to change at page 2, line 34 skipping to change at page 2, line 34
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
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 . . . . . . . . . . . . . . . . . . . . . . . 6 4. PHB Description .................................................6
5. Traffic Conditioning Actions . . . . . . . . . . . . . . . . 7 5. Traffic-Conditioning Actions ....................................7
6. Recommended DS Codepoint . . . . . . . . . . . . . . . . . . 7 6. Recommended DSCP ................................................7
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 7 7. Deployment Considerations .......................................8
8. Remarking to other DSCPs/PHBs . . . . . . . . . . . . . . . . 8 8. Re-marking to Other DSCPs/PHBs ..................................9
9. Multicast Considerations . . . . . . . . . . . . . . . . . . 9 9. Multicast Considerations .......................................10
10. The Update to RFC 4594 . . . . . . . . . . . . . . . . . . . 10 10. The Updates to RFC 4594 .......................................11
11. The Update to RFC 8325 . . . . . . . . . . . . . . . . . . . 12 11. The Updates to RFC 8325 .......................................12
12. The Update to draft-ietf-tsvwg-rtcweb-qos . . . . . . . . . . 12 12. IANA Considerations ...........................................13
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 13. Security Considerations .......................................14
14. Security Considerations . . . . . . . . . . . . . . . . . . . 14 14. References ....................................................15
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 14.1. Normative References .....................................15
15.1. Normative References . . . . . . . . . . . . . . . . . . 15 14.2. Informative References ...................................15
15.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. History of the LE PHB .................................18
Appendix A. History of the LE PHB . . . . . . . . . . . . . . . 17 Acknowledgments ...................................................18
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 18 Author's Address ..................................................18
Appendix C. Change History . . . . . . . . . . . . . . . . . . . 18
Appendix D. Note to RFC Editor . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
This document defines a Differentiated Services per-hop behavior This document defines a Differentiated Services (DS) per-hop behavior
[RFC2474] called "Lower Effort" (LE), which is intended for traffic [RFC2474] called "Lower-Effort Per-Hop Behavior" (LE PHB), which is
of sufficiently low urgency that all other traffic takes precedence intended for traffic of sufficiently low urgency that all other
over the LE traffic in consumption of network link bandwidth. Low traffic takes precedence over the LE traffic in consumption of
urgency traffic has a low priority for timely forwarding, which does network link bandwidth. Low-urgency traffic has a low priority for
not necessarily imply that it is generally of minor importance. From timely forwarding; note, however, that this does not necessarily
this viewpoint, it can be considered as a network equivalent to a imply that it is generally of minor importance. From this viewpoint,
background priority for processes in an operating system. There may it can be considered as a network equivalent to a background priority
or may not be memory (buffer) resources allocated for this type of for processes in an operating system. There may or may not be memory
traffic. (buffer) resources allocated for this type of traffic.
Some networks carry packets that ought to consume network resources Some networks carry packets that ought to consume network resources
only when no other traffic is demanding them. In this point of view, only when no other traffic is demanding them. From this point of
packets forwarded by the LE PHB scavenge otherwise unused resources view, packets forwarded by the LE PHB scavenge otherwise-unused
only, which led to the name "scavenger service" in early Internet2 resources only; this led to the name "scavenger service" in early
deployments (see Appendix A). Other commonly used names for LE PHB Internet2 deployments (see Appendix A). Other commonly used names
type services are "Lower-than-best-effort" or "Less-than-best- for LE PHB types of services are "Lower than best effort"
effort". In summary, with the mentioned feature above, the LE PHB [Carlberg-LBE-2001] or "Less than best effort" [Chown-LBE-2003]. In
has two important properties: it should scavenge residual capacity summary, with the above-mentioned feature, the LE PHB has two
and it must be preemptable by the default PHB (or other elevated important properties: it should scavenge residual capacity, and it
PHBs) in case they need more resources. Consequently, the effect of must be preemptable by the default PHB (or other elevated PHBs) in
this type of traffic on all other network traffic is strictly limited case they need more resources. Consequently, the effect of this type
("no harm" property). This is distinct from "best-effort" (BE) of traffic on all other network traffic is strictly limited (the
traffic since the network makes no commitment to deliver LE packets. "no harm" property). This is distinct from "Best-Effort" (BE)
traffic, since the network makes no commitment to deliver LE packets.
In contrast, BE traffic receives an implied "good faith" commitment In contrast, BE traffic receives an implied "good faith" commitment
of at least some available network resources. This document proposes of at least some available network resources. This document proposes
a Lower Effort Differentiated Services per-hop behavior (LE PHB) for an LE DS PHB for handling this "optional" traffic in a DS node.
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
14 [RFC2119][RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Applicability 3. Applicability
A Lower Effort PHB is applicable for many applications that otherwise An LE PHB is applicable for many applications that otherwise use BE
use best-effort delivery. More specifically, it is suitable for delivery. More specifically, it is suitable for traffic and services
traffic and services that can tolerate strongly varying throughput that can tolerate strongly varying throughput for their data flows,
for their data flows, especially periods of very low throughput or especially periods of very low throughput or even starvation (i.e.,
even starvation (i.e., long interruptions due to significant or even long interruptions due to significant or even complete packet loss).
complete packet loss). Therefore, an application sending an LE Therefore, an application sending an LE-marked flow needs to be able
marked flow needs to be able to tolerate short or (even very) long to tolerate short or (even very) long interruptions due to the
interruptions due to the presence of severe congestion conditions presence of severe congestion conditions during the transmission of
during the transmission of the flow. Thus, there ought to be an the flow. Thus, there ought to be an expectation that packets of the
expectation that packets of the LE PHB could be excessively delayed LE PHB could be excessively delayed or dropped when any other traffic
or dropped when any other traffic is present. It is application- is present. Whether or not a lack of progress is considered to be a
dependent when a lack of progress is considered being a failure failure is application dependent (e.g., if a transport connection
(e.g., if a transport connection fails due to timing out, the fails due to timing out, the application may try several times to
application may try several times to re-establish the transport reestablish the transport connection in order to resume the
connection in order to resume the application session before finally application session before finally giving up). The LE PHB is
giving up). The LE PHB is suitable for sending traffic of low suitable for sending traffic of low urgency across a DS domain or DS
urgency across a Differentiated Services (DS) domain or DS region. region.
Just like best-effort traffic, LE traffic SHOULD be congestion Just like BE traffic, LE traffic SHOULD be congestion controlled
controlled (i.e., use a congestion controlled transport or implement (i.e., use a congestion controlled transport or implement an
an appropriate congestion control method [RFC2914] [RFC8085]). Since appropriate congestion control method [RFC2914] [RFC8085]). Since LE
LE traffic could be starved completely for a longer period of time, traffic could be starved completely for a longer period of time,
transport protocols or applications (and their related congestion transport protocols or applications (and their related congestion
control mechanisms) SHOULD be able to detect and react to such a control mechanisms) SHOULD be able to detect and react to such a
starvation situation. An appropriate reaction would be to resume the starvation situation. An appropriate reaction would be to resume the
transfer instead of aborting it, i.e., an LE optimized transport transfer instead of aborting it, i.e., an LE-optimized transport
ought to use appropriate retry strategies (e.g., exponential back-off ought to use appropriate retry strategies (e.g., exponential back-off
with an upper bound) as well as corresponding retry and timeout with an upper bound) as well as corresponding retry and timeout
limits in order to avoid the loss of the connection due to the limits in order to avoid the loss of the connection due to the
mentioned starvation periods. While it is desirable to achieve a above-mentioned starvation periods. While it is desirable to achieve
quick resumption of the transfer as soon as resources become a quick resumption of the transfer as soon as resources become
available again, it may be difficult to achieve this in practice. In available again, it may be difficult to achieve this in practice. In
lack of a transport protocol and congestion control that are adapted the case of a lack of a transport protocol and congestion control
to LE, applications can also use existing common transport protocols that are adapted to LE, applications can also use existing common
and implement session resumption by trying to re-establish failed transport protocols and implement session resumption by trying to
connections. Congestion control is not only useful to let the flows reestablish failed connections. Congestion control is not only
within the LE behavior aggregate adapt to the available bandwidth useful for letting the flows within the LE Behavior Aggregate (BA)
that may be highly fluctuating, but is also essential if LE traffic adapt to the available bandwidth, which may be highly fluctuating; it
is mapped to the default PHB in DS domains that do not support LE. is also essential if LE traffic is mapped to the default PHB in DS
In this case, use of background transport protocols, e.g., similar to domains that do not support LE. In this case, the use of background
LEDBAT [RFC6817], is expedient. transport protocols, e.g., similar to Low Extra Delay Background
Transport (LEDBAT) [RFC6817], is expedient.
Use of the LE PHB might assist a network operator in moving certain The use of the LE PHB might assist a network operator in moving
kinds of traffic or users to off-peak times. Furthermore, packets certain kinds of traffic or users to off-peak times. Furthermore,
can be designated for the LE PHB when the goal is to protect all packets can be designated for the LE PHB when the goal is to protect
other packet traffic from competition with the LE aggregate while not all other packet traffic from competition with the LE aggregate while
completely banning LE traffic from the network. An LE PHB SHOULD NOT not completely banning LE traffic from the network. An LE PHB
be used for a customer's "normal Internet" traffic and packets SHOULD SHOULD NOT be used for a customer's "normal Internet" traffic and
NOT be "downgraded" to the LE PHB instead of being dropped, packets SHOULD NOT be "downgraded" to the LE PHB instead of being
particularly when the packets are unauthorized traffic. The LE PHB dropped, particularly when the packets are unauthorized traffic. The
is expected to have applicability in networks that have at least some LE PHB is expected to have applicability in networks that have at
unused capacity at certain periods. least some unused capacity during 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 be used for the general
case of downgraded traffic, but could be used by design, e.g., to case of downgraded traffic, but it 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.
In this case there is no way for attackers to preempt internal (non In this case, there is no way for attackers to preempt internal
LE) traffic by flooding. Another use case in this regard is (non-LE) traffic by flooding. Another use case in this regard is the
forwarding of multicast traffic from untrusted sources. Multicast forwarding of multicast traffic from untrusted sources. Multicast
forwarding is currently enabled within domains only for specific forwarding is currently enabled within domains only for specific
sources within a domain, but not for sources from anywhere in the sources within a domain -- not for sources from anywhere in the
Internet. A major problem is that multicast routing creates traffic Internet. One major problem is that multicast routing creates
sources at (mostly) unpredictable branching points within a domain, traffic sources at (mostly) unpredictable branching points within a
potentially leading to congestion and packet loss. In the case of domain, potentially leading to congestion and packet loss. In the
multicast traffic packets from untrusted sources are forwarded as LE case where multicast traffic packets from untrusted sources are
traffic, they will not harm traffic from non-LE behavior aggregates. forwarded as LE traffic, they will not harm traffic from non-LE BAs.
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 (cf. forwarded without loss after rerouting caused by a link failure (cf.
Section 6 of [RFC3439]). LE marked traffic can utilize the normally Section 6 of [RFC3439]). LE-marked traffic can utilize the normally
unused capacity and will be preempted automatically in case of link unused capacity and will be preempted automatically in the case of
failure when 100% of the link capacity is required for all other link failure when 100% of the link capacity is required for all other
traffic. Ideally, applications mark their packets as LE traffic, traffic. Ideally, applications mark their packets as LE traffic,
since they know the urgency of flows. Since LE traffic may be because they know the urgency of flows. Since LE traffic may be
starved for longer periods of time it is probably less suitable for starved for longer periods of time, it is probably less suitable for
real-time and interactive applications. real-time and interactive applications.
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
applications. applications.
o For backup traffic or non-time critical synchronization or o For backup traffic, non-time-critical synchronization, or
mirroring traffic. mirroring traffic.
o For content distribution transfers between caches. o For content distribution transfers between caches.
o For preloading or prefetching objects from web sites. o For preloading or prefetching objects from web sites.
o For network news and other "bulk mail" of the Internet. o For network news and other "bulk mail" of the Internet.
o For "downgraded" traffic from some other PHB when this does not o For "downgraded" traffic from some other PHB when this does not
violate the operational objectives of the other PHB. violate the operational objectives of the other PHB.
o For multicast traffic from untrusted (e.g., non-local) sources. o For multicast traffic from untrusted (e.g., non-local) sources.
4. PHB Description 4. PHB Description
The LE PHB is defined in relation to the default PHB (best-effort). The LE PHB is defined in relation to the default PHB (BE). A packet
A packet forwarded with the LE PHB SHOULD have lower precedence than forwarded with the LE PHB SHOULD have lower precedence than packets
packets forwarded with the default PHB, i.e., in the case of forwarded with the default PHB, i.e., in the case of congestion,
congestion, LE marked traffic SHOULD be dropped prior to dropping any LE-marked traffic SHOULD be dropped prior to dropping any default PHB
default PHB traffic. Ideally, LE packets would be forwarded only traffic. Ideally, LE packets would be forwarded only when no packet
when no packet with any other PHB is awaiting transmission. This with any other PHB is awaiting transmission. This means that in the
means that in case of link resource contention LE traffic can be case of link resource contention LE traffic can be starved
starved completely, which may not be always desired by the network completely, which may not always be desired by the network operator's
operator's policy. The used scheduler to implement the LE PHB may policy. A scheduler used to implement the LE PHB may reflect this
reflect this policy accordingly. policy accordingly.
A straightforward implementation could be a simple priority scheduler A straightforward implementation could be a simple priority scheduler
serving the default PHB queue with higher priority than the lower- serving the default PHB queue with higher priority than the LE PHB
effort PHB queue. Alternative implementations may use scheduling queue. Alternative implementations may use scheduling algorithms
algorithms that assign a very small weight to the LE class. This, that assign a very small weight to the LE class. This, however,
however, could sometimes cause better service for LE packets compared could sometimes cause better service for LE packets compared to BE
to BE packets in cases when the BE share is fully utilized and the LE packets in cases when the BE share is fully utilized and the LE share
share not. is not.
If a dedicated LE queue is not available, an active queue management If a dedicated LE queue is not available, an active queue management
mechanism within a common BE/LE queue could also be used. This could mechanism within a common BE/LE queue could also be used. This could
drop all arriving LE packets as soon as certain queue length or drop all arriving LE packets as soon as certain queue length or
sojourn time thresholds are exceeded. sojourn time thresholds are exceeded.
Since congestion control is also useful within the LE traffic class, Since congestion control is also useful within the LE traffic class,
Explicit Congestion Notification (ECN) [RFC3168] SHOULD be used for Explicit Congestion Notification (ECN) [RFC3168] SHOULD be used for
LE packets, too. More specifically, an LE implementation SHOULD also LE packets, too. More specifically, an LE implementation SHOULD also
apply CE marking for ECT marked packets and transport protocols used apply Congestion Experienced (CE) marking for ECT-marked packets
for LE SHOULD support and employ ECN. For more information on the ("ECT" stands for ECN-Capable Transport), and transport protocols
benefits of using ECN see [RFC8087]. used for LE SHOULD support and employ ECN. For more information on
the benefits of using ECN, see [RFC8087].
5. Traffic Conditioning Actions 5. Traffic-Conditioning Actions
If possible, packets SHOULD be pre-marked in DS-aware end systems by If possible, packets SHOULD be pre-marked in DS-aware end systems by
applications due to their specific knowledge about the particular applications due to their specific knowledge about the particular
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
also performed at the first DS boundary node according to the DS also be 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 a protection measure against
sources). However, non-LE traffic (e.g., BE traffic) SHOULD NOT be untrusted sources). However, non-LE traffic (e.g., BE traffic)
remarked to LE. Remarking traffic from another PHB results in that SHOULD NOT be re-marked to LE. Re-marking traffic from another PHB
traffic being "downgraded". This changes the way the network treats results in that traffic being "downgraded". This changes the way the
this traffic and it is important not to violate the operational network treats this traffic, and it is important not to violate the
objectives of the original PHB. See also remarks with respect to operational objectives of the original PHB. See Sections 3 and 8 for
downgrading in Section 3 and Section 8. notes related to downgrading.
6. Recommended DS Codepoint 6. Recommended DSCP
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 (e.g., [RFC4594]) recommended the use of Class
(as mentioned in [RFC3662]). This is problematic since it may cause Selector 1 (CS1) as the codepoint (as mentioned in [RFC3662]). This
a priority inversion in Diffserv domains that treat CS1 as originally is problematic, since it may cause a priority inversion in Diffserv
proposed in [RFC2474], resulting in forwarding LE packets with higher domains that treat CS1 as originally proposed in [RFC2474], resulting
precedence than BE packets. Existing implementations SHOULD in forwarding LE packets with higher precedence than BE packets.
transition to use the unambiguous LE codepoint '000001' whenever Existing implementations SHOULD transition to use the unambiguous LE
possible. codepoint '000001' whenever 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 currently observable Differentiated Services Code Point (DSCP)
[ietf99-secchi]. Since some network domains set the former IP re-marking behavior in the Internet [IETF99-Secchi]. Since some
precedence bits to zero, it is possible that some other standardized network domains set the former IP Precedence bits to zero, it is
DSCPs get mapped to the LE PHB DSCP if it were taken from the DSCP possible that some other standardized DSCPs get mapped to the LE PHB
standards action pool 1 (xxxxx0). DSCP if it were taken from the DSCP Standards Action Pool 1 (xxxxx0)
[RFC2474] [RFC8436].
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 (see [RFC2475]) that classifies packets according
that classifies packets according to the LE DSCP to the LE DSCP
o A dedicated LE queue o A dedicated LE queue
o A suitable scheduling discipline, e.g., simple priority queueing o A suitable scheduling discipline, e.g., simple priority queueing
Alternatively, implementations could use active queue management Alternatively, implementations could use active queue management
mechanisms instead of a dedicated LE queue, e.g., dropping all mechanisms instead of a dedicated LE queue, e.g., dropping all
arriving LE packets when certain queue length or sojourn time arriving LE packets when certain queue length or sojourn time
thresholds are exceeded. thresholds are exceeded.
Internet-wide deployment of the LE PHB is eased by the following Internet-wide deployment of the LE PHB is eased by the following
properties: properties:
o No harm to other traffic: since the LE PHB has the lowest o No harm to other traffic: since the LE PHB has the lowest
forwarding priority it does not consume resources from other PHBs. forwarding priority, it does not consume resources from other
Deployment across different provider domains with LE support PHBs. Deployment across different provider domains with LE
causes no trust issues or attack vectors to existing (non LE) support causes no trust issues or attack vectors to existing
traffic. Thus, providers can trust LE markings from end-systems, (non-LE) traffic. Thus, providers can trust LE markings from
i.e., there is no need to police or remark incoming LE traffic. end systems, i.e., there is no need to police or re-mark incoming
LE traffic.
o No PHB parameters or configuration of traffic profiles: the LE PHB o No PHB parameters or configuration of traffic profiles: the LE PHB
itself possesses no parameters that need to be set or configured. itself possesses no parameters that need to be set or configured.
Similarly, since LE traffic requires no admission or policing, it Similarly, since LE traffic requires no admission or policing, it
is not necessary to configure traffic profiles. is not necessary to configure traffic profiles.
o No traffic conditioning mechanisms: the LE PHB requires no traffic o No traffic-conditioning mechanisms: the LE PHB requires no traffic
meters, droppers, or shapers. See also Section 5 for further meters, droppers, or shapers. See also Section 5 for further
discussion. discussion.
Operators of DS domains that cannot or do not want to implement the Operators of DS domains that cannot or do not want to implement the
LE PHB (e.g., because there is no separate LE queue available in the LE PHB (e.g., because there is no separate LE queue available in the
corresponding nodes) SHOULD NOT drop packets marked with the LE DSCP. corresponding nodes) SHOULD NOT drop packets marked with the LE DSCP.
They SHOULD map packets with this DSCP to the default PHB and SHOULD They SHOULD map packets with this DSCP to the default PHB and SHOULD
preserve the LE DSCP marking. DS domains operators that do not preserve the LE DSCP marking. DS domain operators that do not
implement the LE PHB should be aware that they violate the "no harm" implement the LE PHB should be aware that they violate the "no harm"
property of LE. See also Section 8 for further discussion of property of LE. See also Section 8 for further discussion of
forwarding LE traffic with the default PHB instead. forwarding LE traffic with the default PHB instead of the LE PHB.
8. Remarking to other DSCPs/PHBs 8. Re-marking 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 to protect BE traffic from LE traffic
traffic (no harm property). In the case that a DS domain does not (the "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 re-marking to DSCP '000000'. This is
this is that later traversed DS domains may then have still the because DS domains that are traversed later may then still have the
possibility to treat such packets according to the LE PHB. opportunity 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 QoS degradation of the original BE traffic.
original BE traffic. In this case, the LE property of not harming In this case, the LE property of not harming other traffic is no
other traffic is no longer fulfilled. To limit the impact in such longer fulfilled. To limit the impact in such cases, traffic
cases, traffic policing of the LE aggregate MAY be used. policing of the LE aggregate MAY be used.
In the case that LE marked packets are effectively carried within the In the case that LE-marked packets are effectively carried with the
default PHB (i.e., forwarded as best-effort traffic) they get a default PHB (i.e., forwarded as BE traffic), they get a better
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
intention of the LE PHB user to strictly send the traffic only if original intention of the LE PHB user to strictly send the traffic
otherwise unused resources are available. In the case that LE only if otherwise-unused resources are available. In the case that
traffic is mapped to the default PHB, LE traffic may compete with BE LE traffic is mapped to the default PHB, LE traffic may compete with
traffic for the same resources and thus adversely affect the original BE traffic for the same resources and thus adversely affect the
BE aggregate. Applications that want to ensure the lower precedence original BE aggregate. Applications that want to ensure the lower
compared to BE traffic even in such cases SHOULD use additionally a precedence compared to BE traffic even in such cases SHOULD
corresponding Lower-than-Best-Effort transport protocol [RFC6297], additionally use a corresponding lower-than-BE transport protocol
e.g., LEDBAT [RFC6817]. [RFC6297], e.g., LEDBAT [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 re-mark 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
marked packet may be remarked by the default DSCP if the next domain CS1-marked packet may be re-marked by the default DSCP if the next
is applying Diffserv-Interconnection [RFC8100]. domain is applying Diffserv-Interconnection [RFC8100].
9. Multicast Considerations 9. Multicast Considerations
Basically, the multicast considerations in [RFC3754] apply. However, Basically, the multicast considerations in [RFC3754] apply. However,
using the Lower Effort PHB for multicast requires paying special using the LE PHB for multicast requires paying special attention to
attention to the way how packets get replicated inside routers. Due how packets get replicated inside routers. Due to multicast packet
to multicast packet replication, resource contention may actually replication, resource contention may actually occur even before a
occur even before a packet is forwarded to its output port and in the packet is forwarded to its output port. In the worst case, these
worst case, these forwarding resources are missing for higher forwarding resources are missing for higher-priority multicast or
prioritized multicast or even unicast packets. even unicast packets.
Several forward error correction coding schemes such as fountain Several forward error correction coding schemes, such as fountain
codes (e.g., [RFC5053]) allow reliable data delivery even in codes (e.g., [RFC5053]), allow reliable data delivery even in
environments with a potential high amount of packet loss in environments with a potentially high amount of packet loss in
transmission. When used for example over satellite links or other transmission. When used, for example, over satellite links or other
broadcast media, this means that receivers that lose 80% of packets broadcast media, this means that receivers that lose 80% of packets
in transmission simply need 5 times as long to receive the complete in transmission simply need five times longer to receive the complete
data than those receivers experiencing no loss (without any receiver data than those receivers experiencing no loss (without any receiver
feedback required). feedback required).
Superficially viewed, it may sound very attractive to use IP Superficially viewed, it may sound very attractive to use IP
multicast with the LE PHB to build this type of opportunistic multicast with the LE PHB to build this type of opportunistic
reliable distribution in IP networks, but it can only be usefully reliable distribution in IP networks, but it can only be usefully
deployed with routers that do not experience forwarding/replication deployed with routers that do not experience forwarding/replication
resource starvation when a large amount of packets (virtually) need resource starvation when a large amount of packets (virtually) need
to be replicated to links where the LE queue is full. to be replicated to links where the LE queue is full.
Thus, packet replication of LE marked packets should consider the Thus, a packet replication mechanism for LE-marked packets should
situation at the respective output links: it is a waste of internal consider the situation at the respective output links: it is a waste
forwarding resources if a packet is replicated to output links that of internal forwarding resources if a packet is replicated to output
have no resources left for LE forwarding. In those cases a packet links that have no resources left for LE forwarding. In those cases,
would have been replicated just to be dropped immediately after a packet would have been replicated just to be dropped immediately
finding a filled LE queue at the respective output port. Such after finding a filled LE queue at the respective output port. Such
behavior could be avoided for example by using a conditional internal behavior could be avoided -- for example, by using a conditional
packet replication: a packet would then only be replicated in case internal packet replication: a packet would then only be replicated
the output link is not fully used. This conditional replication, in cases where the output link is not fully used. This conditional
however, is probably not widely implemented. replication, however, is probably not widely implemented.
While the resource contention problem caused by multicast packet While the resource contention problem caused by multicast packet
replication is also true for other Diffserv PHBs, LE forwarding is replication is also true for other Diffserv PHBs, LE forwarding is
special, because often it is assumed that LE packets only get special, because often it is assumed that LE packets only get
forwarded in case of available resources at the output ports. The forwarded in the case of available resources at the output ports.
previously mentioned redundancy data traffic could nicely use the The previously mentioned redundancy data traffic could suitably use
varying available residual bandwidth being utilized the by LE PHB, the varying available residual bandwidth being utilized by the LE
but only if the specific requirements stated above for conditional PHB, but only if the specific requirements stated above for
replication in the internal implementation of the network devices are conditional replication in the internal implementation of the network
considered. devices are considered.
10. The Update to RFC 4594 10. The Updates to RFC 4594
[RFC4594] recommended to use CS1 as codepoint in section 4.10, [RFC4594] recommended the use of CS1 as the codepoint in its
whereas CS1 was defined in [RFC2474] to have a higher precedence than Section 4.10, whereas CS1 was defined in [RFC2474] to have a higher
CS0, i.e., the default PHB. Consequently, Diffserv domains precedence than CS0, i.e., the default PHB. Consequently, Diffserv
implementing CS1 according to [RFC2474] will cause a priority domains implementing CS1 according to [RFC2474] will cause a priority
inversion for LE packets that contradicts with the original purpose inversion for LE packets that contradicts the original purpose of LE.
of LE. Therefore, every occurrence of the CS1 DSCP is replaced by Therefore, every occurrence of the CS1 DSCP is replaced by the
the LE DSCP. LE DSCP.
Changes: Changes:
o This update to RFC 4594 removes the following entry from figure 3: o This update to RFC 4594 removes the following entry from its
Figure 3:
|---------------+---------+-------------+--------------------------| |---------------+---------+-------------+--------------------------|
| Low-Priority | CS1 | 001000 | Any flow that has no BW | | Low-Priority | CS1 | 001000 | Any flow that has no BW |
| Data | | | assurance | | Data | | | assurance |
------------------------------------------------------------------ ------------------------------------------------------------------
and replaces this by the following entry: and replaces it with the following entry:
|---------------+---------+-------------+--------------------------| |---------------+---------+-------------+--------------------------|
| Low-Priority | LE | 000001 | Any flow that has no BW | | Low-Priority | LE | 000001 | Any flow that has no BW |
| Data | | | assurance | | Data | | | assurance |
------------------------------------------------------------------ ------------------------------------------------------------------
o This update to RFC 4594 extends the Notes text below figure 3 that o This update to RFC 4594 extends the Notes text below Figure 3 that
currently states "Notes for Figure 3: Default Forwarding (DF) and currently states "Notes for Figure 3: Default Forwarding (DF) and
Class Selector 0 (CS0) provide equivalent behavior and use the Class Selector 0 (CS0) provide equivalent behavior and use the
same DS codepoint, '000000'." to state "Notes for Figure 3: same DS codepoint, '000000'." to state "Notes for Figure 3:
Default Forwarding (DF) and Class Selector 0 (CS0) provide Default Forwarding (DF) and Class Selector 0 (CS0) provide
equivalent behavior and use the same DS codepoint, '000000'. The equivalent behavior and use the same DSCP, '000000'. The prior
prior recommendation to use the CS1 DSCP for Low-Priority Data has recommendation to use the CS1 DSCP for Low-Priority Data has been
been replaced by the current recommendation to use the LE DSCP, replaced by the current recommendation to use the LE DSCP,
'000001'." '000001'."
o This update to RFC 4594 removes the following entry from figure 4: o This update to RFC 4594 removes the following entry from its
Figure 4:
|---------------+------+-------------------+---------+--------+----|
| Low-Priority | CS1 | Not applicable | RFC3662 | Rate | Yes|
| Data | | | | | |
------------------------------------------------------------------
and replaces this by the following entry:
|---------------+------+-------------------+---------+--------+----|
| Low-Priority | LE | Not applicable | RFCXXXX | Rate | Yes|
| Data | | | | | |
------------------------------------------------------------------
o Section 2.3 of [RFC4594] specifies: "In network segments that use
IP precedence marking, only one of the two service classes can be
supported, High-Throughput Data or Low-Priority Data. We
RECOMMEND that the DSCP value(s) of the unsupported service class
be changed to 000xx1 on ingress and changed back to original
value(s) on egress of the network segment that uses precedence
marking. For example, if Low-Priority Data is mapped to Standard
service class, then 000001 DSCP marking MAY be used to distinguish
it from Standard marked packets on egress." This document removes
this recommendation, because by using the herein defined LE DSCP
such remarking is not necessary. So even if Low-Priority Data is
unsupported (i.e., mapped to the default PHB) the LE DSCP should
be kept across the domain as RECOMMENDED in Section 8. That
removed text is replaced by: "In network segments that use IP
Precedence marking, the Low-Priority Data service class receives
the same Diffserv QoS as the Standard service class when the LE
DSCP is used for Low-Priority Data traffic. This is acceptable
behavior for the Low-Priority Data service class, although it is
not the preferred behavior."
o This document removes the following line of RFC 4594,
Section 4.10: "The RECOMMENDED DSCP marking is CS1 (Class Selector
1)." and replaces this with the following text: "The RECOMMENDED
DSCP marking is LE (Lower Effort), which replaces the prior
recommendation for CS1 (Class Selector 1) marking."
11. The Update to RFC 8325
Section 4.2.10 of RFC 8325 [RFC8325] specifies "[RFC3662] and
[RFC4594] both recommend Low-Priority Data be marked CS1 DSCP."
which is updated to "[RFC3662] recommends that Low-Priority Data be
marked CS1 DSCP. [RFC4594] as updated by [RFCXXXX] recommends Low-
Priority Data be marked LE DSCP."
This document removes the following paragraph of RFC 8325,
Section 4.2.10 because this document makes the anticipated change:
"Note: This marking recommendation may change in the future, as [LE-
PHB] defines a Lower Effort (LE) PHB for Low-Priority Data traffic
and recommends an additional DSCP for this traffic."
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" | Low-Priority | CS1 | Not applicable | RFC3662 | Rate | Yes|
which is updated to "therefore, it is RECOMMENDED to map Low-Priority | Data | | | | | |
Data traffic marked with LE DSCP or legacy CS1 DSCP to UP 1" ------------------------------------------------------------------
This update to RFC 8325 replaces the following entry from figure 1: and replaces it with the following entry:
+---------------+------+----------+-------------+--------------------+ |---------------+------+-------------------+----------+--------+----|
| Low-Priority | CS1 | RFC 3662 | 1 | AC_BK (Background) | | Low-Priority | LE | Not applicable | RFC 8622 | Rate | Yes|
| Data | | | | | | Data | | | | | |
+--------------------------------------------------------------------+ -------------------------------------------------------------------
by the following entries: o Section 2.3 of [RFC4594] specifies the following: "In network
segments that use IP precedence marking, only one of the two
service classes can be supported, High-Throughput Data or
Low-Priority Data. We RECOMMEND that the DSCP value(s) of the
unsupported service class be changed to 000xx1 on ingress and
changed back to original value(s) on egress of the network segment
that uses precedence marking. For example, if Low-Priority Data
is mapped to Standard service class, then 000001 DSCP marking MAY
be used to distinguish it from Standard marked packets on egress."
This document removes this recommendation, because by using the LE
DSCP defined herein, such re-marking is not necessary. So, even
if Low-Priority Data is unsupported (i.e., mapped to the default
PHB), the LE DSCP should be kept across the domain as RECOMMENDED
in Section 8. That removed text is replaced by the following: "In
network segments that use IP Precedence marking, the Low-Priority
Data service class receives the same Diffserv QoS as the Standard
service class when the LE DSCP is used for Low-Priority Data
traffic. This is acceptable behavior for the Low-Priority Data
service class, although it is not the preferred behavior."
+---------------+------+----------+-------------+--------------------+ o This document removes the following line in Section 4.10 of
| Low-Priority | LE | RFCXXXX | 1 | AC_BK (Background) | RFC 4594: "The RECOMMENDED DSCP marking is CS1 (Class
| Data | | | | | Selector 1)." and replaces it with the following text:
+--------------------------------------------------------------------+ "The RECOMMENDED DSCP marking is LE (Lower Effort), which replaces
| Low-Priority | CS1 | RFC 3662 | 1 | AC_BK (Background) | the prior recommendation for CS1 (Class Selector 1) marking."
| Data (legacy) | | | | |
+--------------------------------------------------------------------+
12. The Update to draft-ietf-tsvwg-rtcweb-qos 11. The Updates to RFC 8325
Section 5 of [I-D.ietf-tsvwg-rtcweb-qos] describes the Recommended Section 4.2.10 of RFC 8325 [RFC8325] specifies that "[RFC3662] and
DSCP Values for WebRTC Applications [RFC4594] both recommend Low-Priority Data be marked CS1 DSCP." This
This update to [I-D.ietf-tsvwg-rtcweb-qos] replaces all occurrences is updated to "[RFC3662] recommends that Low-Priority Data be marked
of CS1 with LE in Table 1: CS1 DSCP. [RFC4594], as updated by RFC 8622, recommends that
Low-Priority Data be marked LE DSCP."
This document removes the following paragraph in Section 4.2.10 of
[RFC8325], because this document makes the anticipated change: "Note:
This marking recommendation may change in the future, as [LE-PHB]
defines a Lower Effort (LE) PHB for Low-Priority Data traffic and
recommends an additional DSCP for this traffic."
+------------------------+-------+------+-------------+-------------+ Section 4.2.10 of RFC 8325 [RFC8325] specifies that "therefore, it is
| Flow Type | Very | Low | Medium | High | RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to
| | Low | | | | UP 1", which is updated to "therefore, it is RECOMMENDED to map
+------------------------+-------+------+-------------+-------------+ Low-Priority Data traffic marked with LE DSCP or legacy CS1 DSCP
| Audio | LE | DF | EF (46) | EF (46) | to UP 1".
| | (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: This update to RFC 8325 replaces the following entry from its
Figure 1:
"The above table assumes that packets marked with CS1 are treated as +---------------+------+----------+------------+--------------------+
"less than best effort", such as the LE behavior described in | Low-Priority | CS1 | RFC 3662 | 1 | AC_BK (Background) |
[RFC3662]. However, the treatment of CS1 is implementation | Data | | | | |
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: with the following entries:
"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 | Low-Priority | LE | RFC 8622 | 1 | AC_BK (Background) |
described in [RFCXXXX]. However, the treatment of LE is | Data | | | | |
implementation dependent. If an implementation treats LE as other +-------------------------------------------------------------------+
than "less than best effort", then the actual priority (or, more | Low-Priority | CS1 | RFC 3662 | 1 | AC_BK (Background) |
precisely, the per- hop-behavior) of the packets may be changed from | Data (legacy) | | | | |
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]. During development of this
document, the CS1 DSCP was recommended for "very low" application
priority traffic; implementations that followed that recommendation
SHOULD be updated to use the LE DSCP instead of the CS1 DSCP."
13. IANA Considerations 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/)
registry.xhtml) (Pool 3, Codepoint Space xxxx01, Standards Action) to ("DSCP Pool 3 Codepoints", Codepoint Space xxxx01, Standards Action)
the LE PHB. This document suggests to use a DSCP from Pool 3 in [RFC8126] to the LE PHB. This document uses 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, where they could
accidentally remarked as LE PHB, e.g., due to partial DSCP bleaching. become accidentally re-marked as LE PHB, e.g., due to partial DSCP
See [RFC8436] for re-classifying Pool 3 for Standards Action. bleaching. See [RFC8436] regarding reclassifying Pool 3 for
Standards Action.
IANA is requested to update the registry as follows: IANA has updated this 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 8622
14. 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 that is of low forwarding priority, re-marking
traffic as LE traffic may lead to quality-of-service degradation of other traffic as LE traffic may lead to QoS degradation of such
such traffic. Thus, any attacker that is able to modify the DSCP of traffic. Thus, any attacker that is able to modify the DSCP of a
a packet to LE may carry out a downgrade attack. See the general 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 if the
case the DSCP was set on the user's request. On the one hand, this DSCP was set per the user's request. On the one hand, this disclosed
disclosed information is useful only if correlation with metadata information is useful only if correlation with metadata (such as the
(such as the user's IP address) and/or other flows reveal user user's IP address) and/or other flows reveal a user's identity. On
identity. On the other hand, it might help an observer (e.g., a the other hand, it might help an observer (e.g., a state-level actor)
state level actor) who is interested in learning about the user's who is interested in learning about the user's behavior from observed
behavior from observed traffic: LE marked background traffic (such as traffic: LE-marked background traffic (such as software downloads,
software downloads, operating system updates, or telemetry data) may operating system updates, or telemetry data) may be less interesting
be less interesting for surveillance than general web traffic. for surveillance than general web traffic. Therefore, the LE marking
Therefore, the LE marking may help the observer to focus on may help the observer to focus on potentially more interesting
potentially more interesting traffic (however, the user may exploit traffic (however, the user may exploit this particular assumption and
this particular assumption and deliberately hide interesting traffic deliberately hide interesting traffic in the LE aggregate). Apart
in the LE aggregate). Apart from such considerations, the impact of from such considerations, the impact of disclosed information by the
disclosed information by the LE DSCP is likely negligible in most LE DSCP is likely negligible in most cases, given the numerous
cases given the numerous traffic analysis possibilities and general traffic analysis possibilities and general privacy threats (e.g., see
privacy threats (e.g., see [RFC6973]). [RFC6973]).
15. References 14. References
15.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>. <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,
<http://www.rfc-editor.org/info/rfc2474>. <https://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>. <https://www.rfc-editor.org/info/rfc2475>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, RFC 2119 Key Words", BCP 14, RFC 8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
15.2. Informative References 14.2. Informative References
[carlberg-lbe-2001] [Carlberg-LBE-2001]
Carlberg, K., Gevros, P., and J. Crowcroft, "Lower than Carlberg, K., Gevros, P., and J. Crowcroft, "Lower than
best effort: a design and implementation", SIGCOMM best effort: a design and implementation", ACM SIGCOMM
Computer Communications Review Volume 31, Issue 2 Computer Communication Review, Volume 31 Issue 2
supplement, April 2001, supplement, DOI 10.1145/844193.844208, April 2001,
<https://doi.org/10.1145/844193.844208>. <https://dl.acm.org/citation.cfm?doid=844193.844208>.
[chown-lbe-2003] [Chown-LBE-2003]
Chown, T., Ferrari, T., Leinen, S., Sabatino, R., Simar, Chown, T., Ferrari, T., Leinen, S., Sabatino, R., Simar,
N., and S. Venaas, "Less than Best Effort: Application N., and S. Venaas, "Less than Best Effort: Application
Scenarios and Experimental Results", In Proceedings of the Scenarios and Experimental Results", Proceedings of the
Second International Workshop on Quality of Service in Second International Workshop on Quality of Service in
Multiservice IP Networks (QoS-IP 2003), Lecture Notes in Multiservice IP Networks (QoS-IP 2003), Lecture Notes in
Computer Science, vol 2601. Springer, Berlin, Computer Science, vol 2601, Springer, Berlin, Heidelberg,
Heidelberg Pages 131-144, February 2003, Pages 131-144, DOI 10.1007/3-540-36480-3_10,
<https://doi.org/10.1007/3-540-36480-3_10>. February 2003, <https://link.springer.com/chapter/
10.1007%2F3-540-36480-3_10>.
[draft-bless-diffserv-lbe-phb-00]
Bless, R. and K. Wehrle, "A Lower Than Best-Effort Per-Hop
Behavior", draft-bless-diffserv-lbe-phb-00 (work in
progress), September 1999, <https://tools.ietf.org/html/
draft-bless-diffserv-lbe-phb-00>.
[I-D.ietf-tsvwg-rtcweb-qos] [Diffserv-LBE-PHB]
Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP Bless, R. and K. Wehrle, "A Lower Than Best-Effort
Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb- Per-Hop Behavior", Work in Progress,
qos-18 (work in progress), August 2016. draft-bless-diffserv-lbe-phb-00, September 1999.
[ietf99-secchi] [IETF99-Secchi]
Secchi, R., Venne, A., and A. Custura, "Measurements Secchi, R., Venne, A., and A. Custura, "Measurements
concerning the DSCP for a LE PHB", Presentation held at concerning the DSCP for a LE PHB", Presentation held at
99th IETF Meeting, TSVWG, Prague , July 2017, the 99th IETF Meeting, TSVWG, Prague, July 2017,
<https://datatracker.ietf.org/meeting/99/materials/slides- <https://datatracker.ietf.org/meeting/99/materials/
99-tsvwg-sessb-31measurements-concerning-the-dscp-for-a- slides-99-tsvwg-sessb-31measurements-concerning-
le-phb-00>. the-dscp-for-a-le-phb-00>.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, DOI 10.17487/RFC2914, September 2000, RFC 2914, DOI 10.17487/RFC2914, September 2000,
<https://www.rfc-editor.org/info/rfc2914>. <https://www.rfc-editor.org/info/rfc2914>.
[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>. <https://www.rfc-editor.org/info/rfc3168>.
[RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural
Guidelines and Philosophy", RFC 3439, Guidelines and Philosophy", RFC 3439,
DOI 10.17487/RFC3439, December 2002, DOI 10.17487/RFC3439, December 2002,
<https://www.rfc-editor.org/info/rfc3439>. <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>. <https://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, <https://www.rfc-editor.org/info/rfc3754>.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594, Guidelines for DiffServ Service Classes", RFC 4594,
DOI 10.17487/RFC4594, August 2006, DOI 10.17487/RFC4594, August 2006,
<http://www.rfc-editor.org/info/rfc4594>. <https://www.rfc-editor.org/info/rfc4594>.
[RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, [RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer,
"Raptor Forward Error Correction Scheme for Object "Raptor Forward Error Correction Scheme for Object
Delivery", RFC 5053, DOI 10.17487/RFC5053, October 2007, Delivery", RFC 5053, DOI 10.17487/RFC5053, October 2007,
<https://www.rfc-editor.org/info/rfc5053>. <https://www.rfc-editor.org/info/rfc5053>.
[RFC6297] Welzl, M. and D. Ros, "A Survey of Lower-than-Best-Effort [RFC6297] Welzl, M. and D. Ros, "A Survey of Lower-than-Best-Effort
Transport Protocols", RFC 6297, DOI 10.17487/RFC6297, June Transport Protocols", RFC 6297, DOI 10.17487/RFC6297,
2011, <http://www.rfc-editor.org/info/rfc6297>. June 2011, <https://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>. <https://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, DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-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>.
[RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using
Explicit Congestion Notification (ECN)", RFC 8087, Explicit Congestion Notification (ECN)", RFC 8087,
DOI 10.17487/RFC8087, March 2017, DOI 10.17487/RFC8087, March 2017,
<https://www.rfc-editor.org/info/rfc8087>. <https://www.rfc-editor.org/info/rfc8087>.
[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, <https://www.rfc-editor.org/info/rfc8100>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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,
2018, <https://www.rfc-editor.org/info/rfc8325>. February 2018, <https://www.rfc-editor.org/info/rfc8325>.
[RFC8436] Fairhurst, G., "Update to IANA Registration Procedures for [RFC8436] Fairhurst, G., "Update to IANA Registration Procedures for
Pool 3 Values in the Differentiated Services Field Pool 3 Values in the Differentiated Services Field
Codepoints (DSCP) Registry", RFC 8436, Codepoints (DSCP) Registry", RFC 8436,
DOI 10.17487/RFC8436, August 2018, DOI 10.17487/RFC8436, August 2018,
<https://www.rfc-editor.org/info/rfc8436>. <https://www.rfc-editor.org/info/rfc8436>.
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 draft version of this PHB was suggested by Roland Bless and
Wehrle in September 1999 [draft-bless-diffserv-lbe-phb-00], named "A Klaus Wehrle in September 1999 [Diffserv-LBE-PHB], named "A Lower
Lower Than Best-Effort Per-Hop Behavior". After some discussion in Than Best-Effort Per-Hop Behavior". After some discussion in the
the Diffserv Working Group Brian Carpenter and Kathie Nichols Diffserv Working Group, Brian Carpenter and Kathie Nichols proposed a
proposed a "bulk handling" per-domain behavior and believed a PHB was "bulk handling" per-domain behavior and believed a PHB was not
not necessary. Eventually, "Lower Effort" was specified as per- necessary. Eventually, "Lower Effort" was specified as per-domain
domain behavior and finally became [RFC3662]. More detailed behavior and finally became [RFC3662]. More detailed information
information about its history can be found in Section 10 of 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 There are several other names in use for this type of PHB or
associated service classes. Well-known is the QBone Scavenger associated service classes. Well known is the QBone Scavenger
Service (QBSS) that was proposed in March 2001 within the Internet2 Service (QBSS) that was proposed in March 2001 within the Internet2
QoS Working Group. Alternative names are "Lower-than-best-effort" QoS Working Group. Alternative names are "Lower than best effort"
[carlberg-lbe-2001] or "Less-than-best-effort" [chown-lbe-2003]. [Carlberg-LBE-2001] or "Less than best effort" [Chown-LBE-2003].
Appendix B. Acknowledgments Acknowledgments
Since text is partially borrowed from earlier Internet-Drafts and Since text is partially borrowed from earlier Internet-Drafts and
RFCs the co-authors of previous specifications are acknowledged here: RFCs, the coauthors of previous specifications are acknowledged here:
Kathie Nichols and Klaus Wehrle. David Black, Olivier Bonaventure, Kathie Nichols and Klaus Wehrle. David Black, Olivier Bonaventure,
Spencer Dawkins, Toerless Eckert, Gorry Fairhurst, Ruediger Geib, and Spencer Dawkins, Toerless Eckert, Gorry Fairhurst, Ruediger Geib, and
Kyle Rose provided helpful comments and (partially also text) Kyle Rose provided helpful comments and (partially also text)
suggestions. suggestions.
Appendix C. Change History
This section briefly lists changes between Internet-Draft versions
for convenience.
Changes in Version 10: (incorporated comments from IESG discussion as
follows)
o Appended "for Differentiated Services" to the title as suggested
by Alexey.
o Addressed Deborah Brungard's discuss: changed phrase to "However,
non-LE traffic (e.g., BE traffic) SHOULD NOT be remarked to LE."
with additional explanation as suggested by Gorry.
o Fixed the sentence "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 being dropped, particularly when the packets
are unauthorized traffic." according to Alice's and Mirja's
comments.
o Made reference to RFC8174 normative.
o Added hint for the RFC editor to apply changes from section
Section 12 and to delete it afterwards.
o Incorporated Mirja's and Benjamin's suggestions.
o Editorial suggested by Gorry: In case => In the case that
Changes in Version 09:
o Incorporated comments from IETF Last Call:
* from Olivier Bonaventure: added a bit of text for session
resumption and congestion control aspects as well as ECN usage.
* from Kyle Rose: Revised privacy considerations text in Security
Considerations Section
Changes in Version 08:
o revised two sentences as suggested by Spencer Dawkins
Changes in Version 07:
o revised some text for clarification according to comments from
Spencer Dawkins
Changes in Version 06:
o added Multicast Considerations section with input from Toerless
Eckert
o incorporated suggestions by David Black with respect to better
reflect legacy CS1 handling
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:
o Several editorial changes according to review from Gorry Fairhurst
o Changed the section structure a bit (moved subsections 1.1 and 1.2
into own sections 3 and 7 respectively)
o updated section 2 on requirements language
o added updates to RFC 8325
o tried to be more explicit what changes are required to RFCs 4594
and 8325
Changes in Version 03:
o Changed recommended codepoint to 000001
o Added text to explain the reasons for the DSCP choice
o Removed LE-min,LE-strict discussion
o Added one more potential use case: reporting errors or telemetry
data from OSs
o Added privacy considerations to the security section (not worth an
own section I think)
o Changed IANA considerations section
Changes in Version 02:
o Applied many editorial suggestions from David Black
o Added Multicast traffic use case
o Clarified what is required for deployment in section 1.2
(Deployment Considerations)
o Added text about implementations using AQMs and ECN usage
o Updated IANA section according to David Black's suggestions
o Revised text in the security section
o Changed copyright Notice to pre5378Trust200902
Changes in Version 01:
o Now obsoletes RFC 3662.
o Tried to be more precise in section 1.1 (Applicability) according
to R. Geib's suggestions, so rephrased several paragraphs. Added
text about congestion control
o Change section 2 (PHB Description) according to R. Geib's
suggestions.
o Added RFC 2119 language to several sentences.
o Detailed the description of remarking implications and
recommendations in Section 8.
o Added Section 10 to explicitly list changes with respect to RFC
4594, because this document will update it.
Appendix D. Note to RFC Editor
This section lists actions for the RFC editor during final
formatting.
o Apply the suggested changes of section Section 12 and add a
normative reference in draft-ietf-tsvwg-rtcweb-qos to this RFC.
o Delete Section 12.
o Please replace the occurrences of RFCXXXX in Section 10 and
Section 11 with the assigned RFC number for this document.
o Delete Appendix C.
o Delete this section.
Author's Address Author's Address
Roland Bless Roland Bless
Karlsruhe Institute of Technology (KIT) Karlsruhe Institute of Technology (KIT)
Institute of Telematics (TM)
Kaiserstr. 12 Kaiserstr. 12
Karlsruhe 76131 Karlsruhe 76131
Germany Germany
Phone: +49 721 608 46413 Phone: +49 721 608 46413
Email: roland.bless@kit.edu Email: roland.bless@kit.edu
 End of changes. 114 change blocks. 
635 lines changed or deleted 430 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/