draft-ietf-tsvwg-le-phb-06.txt   draft-ietf-tsvwg-le-phb-07.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) October 11, 2018 Obsoletes: 3662 (if approved) January 20, 2019
Updates: 4594,8325 (if approved) Updates: 4594,8325 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: April 14, 2019 Expires: July 24, 2019
A Lower Effort Per-Hop Behavior (LE PHB) A Lower Effort Per-Hop Behavior (LE PHB)
draft-ietf-tsvwg-le-phb-06 draft-ietf-tsvwg-le-phb-07
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. Alternatively, packets forwarded by the traffic and may preempt it. Alternatively, packets forwarded by the
LE PHB can be associated with a scavenger service class, i.e., they LE PHB can be associated with a scavenger service class, i.e., they
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 14, 2019. This Internet-Draft will expire on July 24, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
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
skipping to change at page 2, line 37 skipping to change at page 2, line 37
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 . . . . . . . . . . . . . . . . . . . . . . . 5 4. PHB Description . . . . . . . . . . . . . . . . . . . . . . . 6
5. Traffic Conditioning Actions . . . . . . . . . . . . . . . . 6 5. Traffic Conditioning Actions . . . . . . . . . . . . . . . . 6
6. Recommended DS Codepoint . . . . . . . . . . . . . . . . . . 6 6. Recommended DS Codepoint . . . . . . . . . . . . . . . . . . 7
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 7 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 7
8. Remarking to other DSCPs/PHBs . . . . . . . . . . . . . . . . 8 8. Remarking to other DSCPs/PHBs . . . . . . . . . . . . . . . . 8
9. Multicast Considerations . . . . . . . . . . . . . . . . . . 9 9. Multicast Considerations . . . . . . . . . . . . . . . . . . 9
10. The Update to RFC 4594 . . . . . . . . . . . . . . . . . . . 10 10. The Update to RFC 4594 . . . . . . . . . . . . . . . . . . . 10
11. The Update to RFC 8325 . . . . . . . . . . . . . . . . . . . 11 11. The Update to RFC 8325 . . . . . . . . . . . . . . . . . . . 11
12. The Update to draft-ietf-tsvwg-rtcweb-qos . . . . . . . . . . 12 12. The Update to draft-ietf-tsvwg-rtcweb-qos . . . . . . . . . . 12
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
14. Security Considerations . . . . . . . . . . . . . . . . . . . 14 14. Security Considerations . . . . . . . . . . . . . . . . . . . 14
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
15.1. Normative References . . . . . . . . . . . . . . . . . . 14 15.1. Normative References . . . . . . . . . . . . . . . . . . 14
15.2. Informative References . . . . . . . . . . . . . . . . . 14 15.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. History of the LE PHB . . . . . . . . . . . . . . . 17 Appendix A. History of the LE PHB . . . . . . . . . . . . . . . 17
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 17 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 17
Appendix C. Change History . . . . . . . . . . . . . . . . . . . 17 Appendix C. Change History . . . . . . . . . . . . . . . . . . . 17
Appendix D. Note to RFC Editor . . . . . . . . . . . . . . . . . 19 Appendix D. Note to RFC Editor . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
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 packets that ought to consume network resources
optional; that is, packets of this type of traffic ought to consume only when no other traffic is demanding them otherwise. In this
network resources only when no other traffic is present. In this
point of view, packets forwarded by the LE PHB scavenge otherwise point of view, packets forwarded by the LE PHB scavenge otherwise
unused resources only, which led to the name "scavenger service" in unused resources only, which led to the name "scavenger service" in
early Internet2 deployments (see Appendix A). Other commonly used early Internet2 deployments (see Appendix A). Other commonly used
names for LE PHB type services are "Lower-than-best-effort" or "Less- names for LE PHB type services are "Lower-than-best-effort" or "Less-
than-best-effort". Alternatively, the effect of this type of traffic than-best-effort". Alternatively, the effect of this type of traffic
on all other network traffic is strictly limited ("no harm" on all other network traffic is strictly limited ("no harm"
property). This is distinct from "best-effort" (BE) traffic since property). This is distinct from "best-effort" (BE) traffic since
the network makes no commitment to deliver LE packets. In contrast, the network makes no commitment to deliver LE packets. In contrast,
BE traffic receives an implied "good faith" commitment of at least BE traffic receives an implied "good faith" commitment of at least
some available network resources. This document proposes a Lower some available network resources. This document proposes a Lower
Effort Differentiated Services per-hop behavior (LE PHB) for handling Effort Differentiated Services per-hop behavior (LE PHB) for handling
this "optional" traffic in a differentiated services node. 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
A Lower Effort PHB is applicable for many applications that otherwise A Lower Effort PHB is applicable for many applications that otherwise
use best-effort delivery. More specifically, it is suitable for use best-effort delivery. More specifically, it is suitable for
traffic and services that can tolerate strongly varying throughput traffic and services that can tolerate strongly varying throughput
for their data flows, especially periods of very low throughput or for their data flows, especially periods of very low throughput or
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.
Just like best-effort traffic, LE traffic SHOULD be congestion Just like best-effort traffic, LE traffic SHOULD be congestion
controlled (i.e., use a congestion controlled transport or implement controlled (i.e., use a congestion controlled transport or implement
an appropriate congestion control method [RFC8085]). Since LE an appropriate congestion control method [RFC2914] [RFC8085]). Since
traffic could be starved completely for a longer period of time, LE 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
situation and ought to resume the transfer as soon as possible. starvation situation. An appropriate reaction would be to resume the
Congestion control is not only useful to let the flows within the LE transfer instead of aborting it, i.e., an LE optimized transport
behavior aggregate adapt to the available bandwidth that may be ought to use appropriate retry and timeout limits in order to avoid
highly fluctuating, but is also essential if LE traffic is mapped to the loss of the connection due to the mentioned starvation periods.
the default PHB in DS domains that do not support LE. While it is desirable to achieve a quick resumption of the transfer
as soon as resources become available again, it may be difficult to
achieve this in practice. Congestion control is not only useful to
let the flows within the LE behavior aggregate adapt to the available
bandwidth that may be highly fluctuating, but is also essential if LE
traffic is mapped to the default PHB in DS domains that do not
support LE. In this case, use of background transport protocols,
e.g., similar to LEDBAT [RFC6817], is expedient.
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
skipping to change at page 6, line 5 skipping to change at page 6, line 12
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 (best-effort).
A packet forwarded with the LE PHB SHOULD have lower precedence than A packet forwarded with the LE PHB SHOULD have lower precedence than
packets forwarded with the default PHB, i.e., in the case of packets forwarded with the default PHB, i.e., in the case of
congestion, LE marked traffic SHOULD be dropped prior to dropping any congestion, LE marked traffic SHOULD be dropped prior to dropping any
default PHB traffic. Ideally, LE packets SHOULD be forwarded only if default PHB traffic. Ideally, LE packets SHOULD be forwarded only if
no packet with any other PHB is awaiting transmission. no packet with any other PHB is awaiting transmission. This means
that in case of link resource contention LE traffic can be starved
completely, which may not be always desired by the network operator's
policy. The used scheduler to implement the LE PHB may reflect this
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 lower-
effort PHB queue. Alternative implementations may use scheduling effort PHB queue. Alternative implementations may use scheduling
algorithms that assign a very small weight to the LE class. This, algorithms that assign a very small weight to the LE class. This,
however, could sometimes cause better service for LE packets compared however, could sometimes cause better service for LE packets compared
to BE packets in cases when the BE share is fully utilized and the LE to BE packets in cases when the BE share is fully utilized and the LE
share not. share 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
skipping to change at page 6, line 47 skipping to change at page 7, line 11
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 and user. See also remarks with respect to downgrading in Section 3 and
Section 8. 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 currently observable DSCP remarking behavior in the Internet
[ietf99-secchi]. Since some network domains set the former IP [ietf99-secchi]. Since some network domains set the former IP
precedence bits to zero, it is possible that some other standardized 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 DSCPs get mapped to the LE PHB DSCP if it were taken from the DSCP
skipping to change at page 7, line 40 skipping to change at page 8, line 4
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 PHBs.
Deployment across different provider domains with LE support Deployment across different provider domains with LE support
causes no trust issues or attack vectors to existing (non LE) causes no trust issues or attack vectors to existing (non LE)
traffic. Thus, providers can trust LE markings from end-systems, traffic. Thus, providers can trust LE markings from end-systems,
i.e., there is no need to police or remark incoming LE traffic. i.e., there is no need to police or remark 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 support the LE Operators of DS domains that cannot or do not want to implement the
PHB should be aware that they violate the "no harm" property of LE. LE PHB (e.g., because there is no separate LE queue available in the
DS domains that do not offer support for the LE PHB support SHOULD corresponding nodes) SHOULD NOT drop packets marked with the LE DSCP.
NOT drop packets marked with the LE DSCP. They SHOULD map packets They SHOULD map packets with this DSCP to the default PHB and SHOULD
with this DSCP to the default PHB and SHOULD preserve the LE DSCP preserve the LE DSCP marking. DS domains operators that do not
marking. See also Section 8 for further discussion of forwarding LE implement the LE PHB should be aware that they violate the "no harm"
traffic with the default PHB instead. property of LE. See also Section 8 for further discussion of
forwarding LE traffic with the default PHB instead.
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
skipping to change at page 8, line 46 skipping to change at page 9, line 11
compared to BE traffic even in such cases SHOULD use additionally a compared to BE traffic even in such cases SHOULD use additionally a
corresponding Lower-than-Best-Effort transport protocol [RFC6297], corresponding Lower-than-Best-Effort transport protocol [RFC6297],
e.g., LEDBAT [RFC6817]. 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 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. 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 to pay special using the Lower Effort PHB for multicast requires to pay special
attention to the way how packets get replicated inside routers. Due attention to the way how packets get replicated inside routers. Due
to multicast packet replication, resource contention may actually to multicast packet replication, resource contention may actually
occur even before a packet is forwarded to its output port and in the occur even before a packet is forwarded to its output port and in the
worst case, these forwarding resources are missing for higher worst case, these forwarding resources are missing for higher
prioritized multicast or even unicast packets. prioritized multicast or even unicast packets.
Several forwarding error correction coding schemes such as fountain Several forwarding 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 potential 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 loose 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 5 times as long 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.
skipping to change at page 9, line 43 skipping to change at page 9, line 51
forwarding resources if a packet is replicated to output links that forwarding resources if a packet is replicated to output links that
have no resources left for LE forwarding. In those cases a packet have no resources left for LE forwarding. In those cases a packet
would have been replicated just to be dropped immediately after would have been replicated just to be dropped immediately after
finding a filled LE queue at the respective output port. Such 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 internal
packet replication: a packet would then only be replicated in case packet replication: a packet would then only be replicated in case
the output link is not fully used. This conditional replication, the output link is not fully used. This conditional replication,
however, is probably not widely implemented. 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 get only special, because often it is assumed that LE packets get only
forwarded in case of available resources at the output ports. The forwarded in case of available resources at the output ports. The
previously mentioned redundancy data traffic could nicely use the previously mentioned redundancy data traffic could nicely use the
varying available residual bandwidth being utilized the by LE PHB, varying available residual bandwidth being utilized the by LE PHB,
but only if the previously specific requirements in the internal but only if the previously specific requirements in the internal
implementation of the network devices are considered. implementation of the network devices are considered.
10. The Update to RFC 4594 10. The Update to RFC 4594
[RFC4594] recommended to use CS1 as codepoint in section 4.10, [RFC4594] recommended to use CS1 as codepoint in section 4.10,
whereas CS1 was defined in [RFC2474] to have a higher precedence than whereas CS1 was defined in [RFC2474] to have a higher precedence than
CS0, i.e., the default PHB. Consequently, DiffServ domains CS0, i.e., the default PHB. Consequently, Diffserv domains
implementing CS1 according to [RFC2474] will cause a priority 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 with the original purpose
of LE. Therefore, every occurrence of the CS1 DSCP is replaced by of LE. Therefore, every occurrence of the CS1 DSCP is replaced by
the LE DSCP. the 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 figure 3:
|---------------+---------+-------------+--------------------------| |---------------+---------+-------------+--------------------------|
skipping to change at page 12, line 29 skipping to change at page 12, line 31
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
| Low-Priority | CS1 | RFC 3662 | 1 | AC_BK (Background) | | Low-Priority | CS1 | RFC 3662 | 1 | AC_BK (Background) |
| Data (legacy) | | | | | | Data (legacy) | | | | |
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
12. The Update to draft-ietf-tsvwg-rtcweb-qos 12. The Update to draft-ietf-tsvwg-rtcweb-qos
Section 5 of [I-D.ietf-tsvwg-rtcweb-qos] describes the Recommended Section 5 of [I-D.ietf-tsvwg-rtcweb-qos] describes the Recommended
DSCP Values for WebRTC Applications DSCP Values for WebRTC Applications
This update to [I-D.ietf-tsvwg-rtcweb-qos] replaces all occurences of This update to [I-D.ietf-tsvwg-rtcweb-qos] replaces all occurrences
CS1 with LE in Table 1: of CS1 with LE in Table 1:
+------------------------+-------+------+-------------+-------------+ +------------------------+-------+------+-------------+-------------+
| Flow Type | Very | Low | Medium | High | | Flow Type | Very | Low | Medium | High |
| | Low | | | | | | Low | | | |
+------------------------+-------+------+-------------+-------------+ +------------------------+-------+------+-------------+-------------+
| Audio | LE | DF | EF (46) | EF (46) | | Audio | LE | DF | EF (46) | EF (46) |
| | (1) | (0) | | | | | (1) | (0) | | |
| | | | | | | | | | | |
| Interactive Video with | LE | DF | AF42, AF43 | AF41, AF42 | | Interactive Video with | LE | DF | AF42, AF43 | AF41, AF42 |
| or without Audio | (1) | (0) | (36, 38) | (34, 36) | | or without Audio | (1) | (0) | (36, 38) | (34, 36) |
skipping to change at page 13, line 43 skipping to change at page 13, line 43
13. IANA Considerations 13. 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 [RFC8436] for re-classifying Pool 3 for Standards Action.
classify Pool 3 for Standards Action.
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]
skipping to change at page 15, line 21 skipping to change at page 15, line 21
Computer Science, vol 2601. Springer, Berlin, Computer Science, vol 2601. Springer, Berlin,
Heidelberg Pages 131-144, February 2003, Heidelberg Pages 131-144, February 2003,
<https://doi.org/10.1007/3-540-36480-3_10>. <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]
Fairhurst, G., "IANA Assignment of DSCP Pool 3 (xxxx01)
Values to require Publication of a Standards Track or Best
Current Practice RFC", draft-ietf-tsvwg-iana-dscp-
registry-08 (work in progress), June 2018.
[I-D.ietf-tsvwg-rtcweb-qos] [I-D.ietf-tsvwg-rtcweb-qos]
Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP
Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb- Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb-
qos-18 (work in progress), August 2016. qos-18 (work in progress), August 2016.
[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, 99th IETF Meeting, TSVWG, Prague , July 2017,
<https://datatracker.ietf.org/meeting/99/materials/slides- <https://datatracker.ietf.org/meeting/99/materials/slides-
99-tsvwg-sessb-31measurements-concerning-the-dscp-for-a- 99-tsvwg-sessb-31measurements-concerning-the-dscp-for-a-
le-phb-00>. le-phb-00>.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, DOI 10.17487/RFC2914, September 2000,
<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>. <http://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>.
skipping to change at page 17, line 9 skipping to change at page 17, line 5
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>.
[RFC8436] Fairhurst, G., "Update to IANA Registration Procedures for
Pool 3 Values in the Differentiated Services Field
Codepoints (DSCP) Registry", RFC 8436,
DOI 10.17487/RFC8436, August 2018,
<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 version of this PHB was suggested by Roland Bless and Klaus
Wehrle in September 1999 [draft-bless-diffserv-lbe-phb-00], named "A Wehrle in September 1999 [draft-bless-diffserv-lbe-phb-00], named "A
Lower Than Best-Effort Per-Hop Behavior". After some discussion in Lower Than Best-Effort Per-Hop Behavior". After some discussion in
the DiffServ Working Group Brian Carpenter and Kathie Nichols the Diffserv Working Group Brian Carpenter and Kathie Nichols
proposed a "bulk handling" per-domain behavior and believed a PHB was proposed a "bulk handling" per-domain behavior and believed a PHB was
not necessary. Eventually, "Lower Effort" was specified as per- not necessary. Eventually, "Lower Effort" was specified as per-
domain behavior and finally became [RFC3662]. More detailed 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 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 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, Toerless Eckert, Gorry Nichols and Klaus Wehrle. David Black, Toerless Eckert, Gorry
Fairhurst, and Ruediger Geib provided helpful comments and (also Fairhurst, Ruediger Geib, and Spencer Dawkins provided helpful
text) suggestions. comments and (also text) 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 07:
o revised some text for clarification according to comments from
Spencer Dawkins
Changes in Version 06: Changes in Version 06:
o added Multicast Considerations section with input from Toerless o added Multicast Considerations section with input from Toerless
Eckert Eckert
o incorporated suggestions by David Black with respect to better o incorporated suggestions by David Black with respect to better
reflect legacy CS1 handling reflect legacy CS1 handling
Changes in Version 05: Changes in Version 05:
 End of changes. 28 change blocks. 
45 lines changed or deleted 65 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/