< draft-ietf-tsvwg-le-phb-09.txt   draft-ietf-tsvwg-le-phb-10.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) February 15, 2019 Obsoletes: 3662 (if approved) March 11, 2019
Updates: 4594,8325 (if approved) Updates: 4594,8325 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: August 19, 2019 Expires: September 12, 2019
A Lower Effort Per-Hop Behavior (LE PHB) A Lower Effort Per-Hop Behavior (LE PHB) for Differentiated Services
draft-ietf-tsvwg-le-phb-09 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 (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 August 19, 2019. This Internet-Draft will expire on September 12, 2019.
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 38 skipping to change at page 2, line 38
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 . . . . . . . . . . . . . . . . 6 5. Traffic Conditioning Actions . . . . . . . . . . . . . . . . 7
6. Recommended DS Codepoint . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . 12
12. The Update to draft-ietf-tsvwg-rtcweb-qos . . . . . . . . . . 12 12. The Update to draft-ietf-tsvwg-rtcweb-qos . . . . . . . . . . 12
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
14. Security Considerations . . . . . . . . . . . . . . . . . . . 14 14. Security Considerations . . . . . . . . . . . . . . . . . . . 14
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
15.1. Normative References . . . . . . . . . . . . . . . . . . 15 15.1. Normative References . . . . . . . . . . . . . . . . . . 15
15.2. Informative References . . . . . . . . . . . . . . . . . 15 15.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. History of the LE PHB . . . . . . . . . . . . . . . 17 Appendix A. History of the LE PHB . . . . . . . . . . . . . . . 17
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 18 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 18
Appendix C. Change History . . . . . . . . . . . . . . . . . . . 18 Appendix C. Change History . . . . . . . . . . . . . . . . . . . 18
Appendix D. Note to RFC Editor . . . . . . . . . . . . . . . . . 20 Appendix D. Note to RFC Editor . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
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
skipping to change at page 3, line 27 skipping to change at page 3, line 27
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 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. In this point of view,
packets forwarded by the LE PHB scavenge otherwise unused resources packets forwarded by the LE PHB scavenge otherwise unused resources
only, which led to the name "scavenger service" in early Internet2 only, which led to the name "scavenger service" in early Internet2
deployments (see Appendix A). Other commonly used names for LE PHB deployments (see Appendix A). Other commonly used names for LE PHB
type services are "Lower-than-best-effort" or "Less-than-best- type services are "Lower-than-best-effort" or "Less-than-best-
effort". Alternatively, the effect of this type of traffic on all effort". In summary, with the mentioned feature above, the LE PHB
other network traffic is strictly limited ("no harm" property). This has two important properties: it should scavenge residual capacity
is distinct from "best-effort" (BE) traffic since the network makes and it must be preemptable by the default PHB (or other elevated
no commitment to deliver LE packets. In contrast, BE traffic PHBs) in case they need more resources. Consequently, the effect of
receives an implied "good faith" commitment of at least some this type of traffic on all other network traffic is strictly limited
available network resources. This document proposes a Lower Effort ("no harm" property). This is distinct from "best-effort" (BE)
Differentiated Services per-hop behavior (LE PHB) for handling this traffic since the network makes no commitment to deliver LE packets.
"optional" traffic in a differentiated services node. In contrast, BE traffic receives an implied "good faith" commitment
of at least some available network resources. This document proposes
a Lower Effort Differentiated Services per-hop behavior (LE PHB) for
handling this "optional" traffic in a differentiated services node.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Applicability 3. Applicability
skipping to change at page 4, line 24 skipping to change at page 4, line 27
urgency across a Differentiated Services (DS) domain or DS region. urgency across a Differentiated Services (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 [RFC2914] [RFC8085]). Since an appropriate congestion control method [RFC2914] [RFC8085]). Since
LE 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
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 backoff 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 mentioned starvation periods. While it is desirable to achieve a
quick resumption of the transfer as soon as resources become 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 lack of a transport protocol and congestion control that are adapted
to LE, applications can also use existing common transport protocols to LE, applications can also use existing common transport protocols
and implement session resumption by trying to re-establish failed and implement session resumption by trying to re-establish failed
connections. Congestion control is not only useful to let the flows connections. Congestion control is not only useful to let the flows
within the LE behavior aggregate adapt to the available bandwidth within the LE behavior aggregate adapt to the available bandwidth
that may be highly fluctuating, but is also essential if LE traffic 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. 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 In this case, use of background transport protocols, e.g., similar to
LEDBAT [RFC6817], is expedient. 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. Furthermore, packets
addition, packets can be designated for the LE PHB when the goal is can be designated for the LE PHB when the goal is to protect all
to protect all other packet traffic from competition with the LE other packet traffic from competition with the LE aggregate while not
aggregate while not completely banning LE traffic from the network. completely banning LE traffic from the network. An LE PHB SHOULD NOT
An LE PHB SHOULD NOT be used for a customer's "normal Internet" be used for a customer's "normal Internet" traffic and packets SHOULD
traffic nor should packets be "downgraded" to the LE PHB instead of NOT be "downgraded" to the LE PHB instead of being dropped,
being dropped, particularly when the packets are unauthorized particularly when the packets are unauthorized traffic. The LE PHB
traffic. The LE PHB is expected to have applicability in networks is expected to have applicability in networks that have at least some
that have at least some unused capacity at certain periods. unused capacity at certain periods.
The LE PHB allows networks to protect themselves from selected types The LE PHB allows networks to protect themselves from selected types
of traffic as a complement to giving preferential treatment to other of traffic as a complement to giving preferential treatment to other
selected traffic aggregates. LE ought not to be used for the general selected traffic aggregates. LE ought not to be used for the general
case of downgraded traffic, but could be used by design, e.g., to case of downgraded traffic, but could be used by design, e.g., to
protect an internal network from untrusted external traffic sources. protect an internal network from untrusted external traffic sources.
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 (non
LE) traffic by flooding. Another use case in this regard is LE) traffic by flooding. Another use case in this regard is
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, but not for sources from anywhere in the
Internet. A main problem is that multicast routing creates traffic Internet. A major problem is that multicast routing creates traffic
sources at (mostly) unpredictable branching points within a domain, sources at (mostly) unpredictable branching points within a domain,
potentially leading to congestion and packet loss. In the case of potentially leading to congestion and packet loss. In the case of
multicast traffic packets from untrusted sources are forwarded as LE multicast traffic packets from untrusted sources are forwarded as LE
traffic, they will not harm traffic from non-LE behavior aggregates. traffic, they will not harm traffic from non-LE behavior aggregates.
A further related use case is mentioned in [RFC3754]: preliminary A further related use case is mentioned in [RFC3754]: preliminary
forwarding of non-admitted multicast traffic. forwarding of non-admitted multicast traffic.
There is no intrinsic reason to limit the applicability of the LE PHB There is no intrinsic reason to limit the applicability of the LE PHB
to any particular application or type of traffic. It is intended as to any particular application or type of traffic. It is intended as
an additional traffic engineering tool for network administrators. an additional traffic engineering tool for network administrators.
For instance, it can be used to fill protection capacity of For instance, it can be used to fill protection capacity of
transmission links that is otherwise unused. Some network providers transmission links that is otherwise unused. Some network providers
keep link utilization below 50% to ensure that all traffic is keep link utilization below 50% to ensure that all traffic is
forwarded without loss after rerouting caused by a link failure (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 case of link
failure when 100% of the link capacity is required for all other 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 they know the urgency of flows. Since LE traffic may be
starved for longer periods of time it is probably less suitable for
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
skipping to change at page 6, line 42 skipping to change at page 6, line 49
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 CE marking for ECT marked packets and transport protocols used
for LE SHOULD support and employ ECN. 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 be
also performed at the first DS boundary node according to the DS also performed at the first DS boundary node according to the DS
domain's own policies (e.g., as protection measure against untrusted domain's own policies (e.g., as protection measure against untrusted
sources). However, non-LE traffic (e.g., BE traffic) SHOULD NOT be sources). However, non-LE traffic (e.g., BE traffic) SHOULD NOT be
remarked to LE on a regular basis without consent or knowledge of the remarked to LE. Remarking traffic from another PHB results in that
user. See also remarks with respect to downgrading in Section 3 and traffic being "downgraded". This changes the way the network treats
Section 8. this traffic and it is important not to violate the operational
objectives of the original PHB. See also remarks with respect to
downgrading in Section 3 and Section 8.
6. Recommended DS Codepoint 6. Recommended DS Codepoint
The RECOMMENDED codepoint for the LE PHB is '000001'. The RECOMMENDED codepoint for the LE PHB is '000001'.
Earlier specifications [RFC4594] recommended to use CS1 as codepoint Earlier specifications [RFC4594] recommended to use CS1 as codepoint
(as mentioned in [RFC3662]). This is problematic since it may cause (as mentioned in [RFC3662]). This is problematic since it may cause
a priority inversion in Diffserv domains that treat CS1 as originally a priority inversion in Diffserv domains that treat CS1 as originally
proposed in [RFC2474], resulting in forwarding LE packets with higher proposed in [RFC2474], resulting in forwarding LE packets with higher
precedence than BE packets. Existing implementations SHOULD precedence than BE packets. Existing implementations SHOULD
skipping to change at page 8, line 47 skipping to change at page 9, line 8
this is that later traversed DS domains may then have still the this is that later traversed DS domains may then have still the
possibility to treat such packets according to the LE PHB. possibility to treat such packets according to the LE PHB.
Operators of DS domains that forward LE traffic within the BE Operators of DS domains that forward LE traffic within the BE
aggregate need to be aware of the implications, i.e., induced aggregate need to be aware of the implications, i.e., induced
congestion situations and quality-of-service degradation of the congestion situations and quality-of-service degradation of the
original BE traffic. In this case, the LE property of not harming original BE traffic. In this case, the LE property of not harming
other traffic is no longer fulfilled. To limit the impact in such other traffic is no longer fulfilled. To limit the impact in such
cases, traffic policing of the LE aggregate MAY be used. cases, traffic policing of the LE aggregate MAY be used.
In case LE marked packets are effectively carried within the default In the case that LE marked packets are effectively carried within the
PHB (i.e., forwarded as best-effort traffic) they get a better default PHB (i.e., forwarded as best-effort traffic) they get a
forwarding treatment than expected. For some applications and better forwarding treatment than expected. For some applications and
services, it is favorable if the transmission is finished earlier services, it is favorable if the transmission is finished earlier
than expected. However, in some cases it may be against the original than expected. However, in some cases it may be against the original
intention of the LE PHB user to strictly send the traffic only if intention of the LE PHB user to strictly send the traffic only if
otherwise unused resources are available. In case LE traffic is otherwise unused resources are available. In the case that LE
mapped to the default PHB, LE traffic may compete with BE traffic for traffic is mapped to the default PHB, LE traffic may compete with BE
the same resources and thus adversely affect the original BE traffic for the same resources and thus adversely affect the original
aggregate. Applications that want to ensure the lower precedence BE aggregate. Applications that want to ensure the lower precedence
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-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 to pay special using the Lower Effort PHB for multicast requires paying 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 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 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 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 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
skipping to change at page 10, line 11 skipping to change at page 10, line 21
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 only get
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 specific requirements stated above for conditional
implementation of the network devices are considered. replication in the internal 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.
skipping to change at page 15, line 25 skipping to change at page 15, line 28
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
<http://www.rfc-editor.org/info/rfc2474>. <http://www.rfc-editor.org/info/rfc2474>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<http://www.rfc-editor.org/info/rfc2475>. <http://www.rfc-editor.org/info/rfc2475>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
15.2. Informative References 15.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", SIGCOMM
Computer Communications Review Volume 31, Issue 2 Computer Communications Review Volume 31, Issue 2
supplement, April 2001, supplement, April 2001,
<https://doi.org/10.1145/844193.844208>. <https://doi.org/10.1145/844193.844208>.
[chown-lbe-2003] [chown-lbe-2003]
skipping to change at page 17, line 24 skipping to change at page 17, line 29
[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
Explicit Congestion Notification (ECN)", RFC 8087,
DOI 10.17487/RFC8087, March 2017,
<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, <http://www.rfc-editor.org/info/rfc8100>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/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 [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>.
skipping to change at page 18, line 25 skipping to change at page 18, line 31
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 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 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: Changes in Version 09:
o Incorporated comments from IETF Last Call: o Incorporated comments from IETF Last Call:
* from Olivier Bonaventure: added a bit of text for session * from Olivier Bonaventure: added a bit of text for session
resumption and congestion control aspects as well as ECN usage. resumption and congestion control aspects as well as ECN usage.
* from Kyle Rose: Revised privacy considerations text in Security * from Kyle Rose: Revised privacy considerations text in Security
Considerations Section Considerations Section
skipping to change at page 20, line 41 skipping to change at page 21, line 27
recommendations in Section 8. recommendations in Section 8.
o Added Section 10 to explicitly list changes with respect to RFC o Added Section 10 to explicitly list changes with respect to RFC
4594, because this document will update it. 4594, because this document will update it.
Appendix D. Note to RFC Editor Appendix D. Note to RFC Editor
This section lists actions for the RFC editor during final This section lists actions for the RFC editor during final
formatting. 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 o Please replace the occurrences of RFCXXXX in Section 10 and
Section 11 with the assigned RFC number for this document. Section 11 with the assigned RFC number for this document.
o Delete Appendix C. o Delete Appendix C.
o Delete this section. o Delete this section.
Author's Address Author's Address
Roland Bless Roland Bless
 End of changes. 26 change blocks. 
50 lines changed or deleted 94 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/