draft-ietf-tsvwg-le-phb-08.txt   draft-ietf-tsvwg-le-phb-09.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) January 30, 2019 Obsoletes: 3662 (if approved) February 15, 2019
Updates: 4594,8325 (if approved) Updates: 4594,8325 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: August 3, 2019 Expires: August 19, 2019
A Lower Effort Per-Hop Behavior (LE PHB) A Lower Effort Per-Hop Behavior (LE PHB)
draft-ietf-tsvwg-le-phb-08 draft-ietf-tsvwg-le-phb-09
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 3, 2019. This Internet-Draft will expire on August 19, 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 46 skipping to change at page 2, line 46
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3
4. PHB Description . . . . . . . . . . . . . . . . . . . . . . . 6 4. PHB Description . . . . . . . . . . . . . . . . . . . . . . . 6
5. Traffic Conditioning Actions . . . . . . . . . . . . . . . . 6 5. Traffic Conditioning Actions . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 14
14. Security Considerations . . . . . . . . . . . . . . . . . . . 14 14. Security Considerations . . . . . . . . . . . . . . . . . . . 14
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
15.1. Normative References . . . . . . . . . . . . . . . . . . 14 15.1. Normative References . . . . . . . . . . . . . . . . . . 15
15.2. Informative References . . . . . . . . . . . . . . . . . 14 15.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. History of the LE PHB . . . . . . . . . . . . . . . 17 Appendix A. History of the LE PHB . . . . . . . . . . . . . . . 17
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 17 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 18
Appendix C. Change History . . . . . . . . . . . . . . . . . . . 17 Appendix C. Change History . . . . . . . . . . . . . . . . . . . 18
Appendix D. Note to RFC Editor . . . . . . . . . . . . . . . . . 19 Appendix D. Note to RFC Editor . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 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
this viewpoint, it can be considered as a network equivalent to a this viewpoint, it can be considered as a network equivalent to a
skipping to change at page 4, line 8 skipping to change at page 4, line 8
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. It is application-
for sending traffic of low urgency across a Differentiated Services dependent when a lack of progress is considered being a failure
(DS) domain or DS region. (e.g., if a transport connection fails due to timing out, the
application may try several times to re-establish the transport
connection in order to resume the application session before finally
giving up). The LE PHB is suitable for sending traffic of low
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 and timeout limits in order to avoid ought to use appropriate retry strategies (e.g., exponential backoff
the loss of the connection due to the mentioned starvation periods. with an upper bound) as well as corresponding retry and timeout
While it is desirable to achieve a quick resumption of the transfer limits in order to avoid the loss of the connection due to the
as soon as resources become available again, it may be difficult to mentioned starvation periods. While it is desirable to achieve a
achieve this in practice. Congestion control is not only useful to quick resumption of the transfer as soon as resources become
let the flows within the LE behavior aggregate adapt to the available available again, it may be difficult to achieve this in practice. In
bandwidth that may be highly fluctuating, but is also essential if LE lack of a transport protocol and congestion control that are adapted
traffic is mapped to the default PHB in DS domains that do not to LE, applications can also use existing common transport protocols
support LE. In this case, use of background transport protocols, and implement session resumption by trying to re-establish failed
e.g., similar to LEDBAT [RFC6817], is expedient. connections. 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 32 skipping to change at page 6, line 39
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
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 [RFC3168] SHOULD be used for LE Explicit Congestion Notification (ECN) [RFC3168] SHOULD be used for
packets, too. LE packets, too. More specifically, an LE implementation SHOULD also
apply CE marking for ECT marked packets and transport protocols used
for LE SHOULD support and employ ECN.
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.
skipping to change at page 14, line 18 skipping to change at page 14, line 38
There are no specific security exposures for this PHB. Since it There are no specific security exposures for this PHB. Since it
defines a new class of low forwarding priority, remarking other defines a new class of low forwarding priority, remarking other
traffic as LE traffic may lead to quality-of-service degradation of traffic as LE traffic may lead to quality-of-service degradation of
such traffic. Thus, any attacker that is able to modify the DSCP of such traffic. Thus, any attacker that is able to modify the DSCP of
a packet to LE may carry out a downgrade attack. See the general a packet to LE may carry out a downgrade attack. See the general
security considerations in [RFC2474] and [RFC2475]. security considerations in [RFC2474] and [RFC2475].
With respect to privacy, an attacker could use the information from With respect to privacy, an attacker could use the information from
the DSCP to infer that the transferred (probably even encrypted) the DSCP to infer that the transferred (probably even encrypted)
content is considered of low priority or low urgency by a user, in content is considered of low priority or low urgency by a user, in
case the DSCP was set on the user's request. However, this disclosed case the DSCP was set on the user's request. On the one hand, this
information is only useful if some form of identification happened at disclosed information is useful only if correlation with metadata
the same time, see [RFC6973] for further details on general privacy (such as the user's IP address) and/or other flows reveal user
threats. identity. On the other hand, it might help an observer (e.g., a
state level actor) who is interested in learning about the user's
behavior from observed traffic: LE marked background traffic (such as
software downloads, operating system updates, or telemetry data) may
be less interesting for surveillance than general web traffic.
Therefore, the LE marking may help the observer to focus on
potentially more interesting traffic (however, the user may exploit
this particular assumption and deliberately hide interesting traffic
in the LE aggregate). Apart from such considerations, the impact of
disclosed information by the LE DSCP is likely negligible in most
cases given the numerous traffic analysis possibilities and general
privacy threats (e.g., see [RFC6973]).
15. References 15. References
15.1. Normative References 15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 17, line 31 skipping to change at page 18, line 13
[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 partially borrowed from earlier Internet-Drafts and
authors of previous specifications are acknowledged here: Kathie RFCs the co-authors of previous specifications are acknowledged here:
Nichols and Klaus Wehrle. David Black, Toerless Eckert, Gorry Kathie Nichols and Klaus Wehrle. David Black, Olivier Bonaventure,
Fairhurst, Ruediger Geib, and Spencer Dawkins provided helpful Spencer Dawkins, Toerless Eckert, Gorry Fairhurst, Ruediger Geib, and
comments and (also text) suggestions. Kyle Rose provided helpful comments and (partially 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 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: Changes in Version 08:
o revised two sentences as suggested by Spencer Dawkins o revised two sentences as suggested by Spencer Dawkins
Changes in Version 07: Changes in Version 07:
o revised some text for clarification according to comments from o revised some text for clarification according to comments from
Spencer Dawkins Spencer Dawkins
Changes in Version 06: Changes in Version 06:
 End of changes. 13 change blocks. 
36 lines changed or deleted 69 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/