RFC 8622
A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services
Internet Engineering Task Force (IETF) R. Bless Request for Comments: 8622 KIT Obsoletes: 3662 June 2019 Updates: 4594, 8325 Category: Standards Track ISSN: 2070-1721 A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated ServicesAbstract
This document specifies properties and characteristics of a Lower- Effort Per-Hop Behavior (LE PHB). The primary objective of this LE PHB is to protect Best-Effort (BE) traffic (packets forwarded with the default PHB) from LE traffic in congestion situations, i.e., when resources become scarce, BE traffic has precedence over LE traffic and may preempt it. Alternatively, packets forwarded by the LE PHB can be associated with a scavenger service class, i.e., they scavenge otherwise-unused resources only. There are numerous uses for this PHB, e.g., for background traffic of low precedence, such as bulk data transfers with low priority in time, non-time-critical backups, larger software updates, web search engines while gathering information from web servers and so on. This document recommends a standard Differentiated Services Code Point (DSCP) value for the LE PHB. This specification obsoletes RFC 3662 and updates the DSCP recommended in RFCs 4594 and 8325 to use the DSCP assigned in this specification. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8622.
Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.Table of Contents
1. Introduction ....................................................3 2. Requirements Language ...........................................3 3. Applicability ...................................................3 4. PHB Description .................................................6 5. Traffic-Conditioning Actions ....................................7 6. Recommended DSCP ................................................7 7. Deployment Considerations .......................................8 8. Re-marking to Other DSCPs/PHBs ..................................9 9. Multicast Considerations .......................................10 10. The Updates to RFC 4594 .......................................11 11. The Updates to RFC 8325 .......................................12 12. IANA Considerations ...........................................13 13. Security Considerations .......................................14 14. References ....................................................15 14.1. Normative References .....................................15 14.2. Informative References ...................................15 Appendix A. History of the LE PHB .................................18 Acknowledgments ...................................................18 Author's Address ..................................................18
1. Introduction
This document defines a Differentiated Services (DS) per-hop behavior [RFC2474] called "Lower-Effort Per-Hop Behavior" (LE PHB), which is intended for traffic of sufficiently low urgency that all other traffic takes precedence over the LE traffic in consumption of network link bandwidth. Low-urgency traffic has a low priority for timely forwarding; note, however, that this does not necessarily imply that it is generally of minor importance. From this viewpoint, it can be considered as a network equivalent to a background priority for processes in an operating system. There may or may not be memory (buffer) resources allocated for this type of traffic. Some networks carry packets that ought to consume network resources only when no other traffic is demanding them. From this point of view, packets forwarded by the LE PHB scavenge otherwise-unused resources only; this led to the name "scavenger service" in early Internet2 deployments (see Appendix A). Other commonly used names for LE PHB types of services are "Lower than best effort" [Carlberg-LBE-2001] or "Less than best effort" [Chown-LBE-2003]. In summary, with the above-mentioned feature, the LE PHB has two important properties: it should scavenge residual capacity, and it must be preemptable by the default PHB (or other elevated PHBs) in case they need more resources. Consequently, the effect of this type of traffic on all other network traffic is strictly limited (the "no harm" property). This is distinct from "Best-Effort" (BE) traffic, since the network makes no commitment to deliver LE packets. In contrast, BE traffic receives an implied "good faith" commitment of at least some available network resources. This document proposes an LE DS PHB for handling this "optional" traffic in a DS node.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.3. Applicability
An LE PHB is applicable for many applications that otherwise use BE delivery. More specifically, it is suitable for traffic and services that can tolerate strongly varying throughput for their data flows, especially periods of very low throughput or even starvation (i.e., long interruptions due to significant or even complete packet loss). Therefore, an application sending an LE-marked flow needs to be able to tolerate short or (even very) long interruptions due to the
presence of severe congestion conditions during the transmission of the flow. Thus, there ought to be an expectation that packets of the LE PHB could be excessively delayed or dropped when any other traffic is present. Whether or not a lack of progress is considered to be a failure is application dependent (e.g., if a transport connection fails due to timing out, the application may try several times to reestablish 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 DS domain or DS region. Just like BE traffic, LE traffic SHOULD be congestion controlled (i.e., use a congestion controlled transport or implement an appropriate congestion control method [RFC2914] [RFC8085]). Since LE traffic could be starved completely for a longer period of time, transport protocols or applications (and their related congestion control mechanisms) SHOULD be able to detect and react to such a starvation situation. An appropriate reaction would be to resume the transfer instead of aborting it, i.e., an LE-optimized transport ought to use appropriate retry strategies (e.g., exponential back-off with an upper bound) as well as corresponding retry and timeout limits in order to avoid the loss of the connection due to the above-mentioned starvation periods. 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. In the case of a lack of a transport protocol and congestion control that are adapted to LE, applications can also use existing common transport protocols and implement session resumption by trying to reestablish failed connections. Congestion control is not only useful for letting the flows within the LE Behavior Aggregate (BA) adapt to the available bandwidth, which may be highly fluctuating; it is also essential if LE traffic is mapped to the default PHB in DS domains that do not support LE. In this case, the use of background transport protocols, e.g., similar to Low Extra Delay Background Transport (LEDBAT) [RFC6817], is expedient. The use of the LE PHB might assist a network operator in moving certain kinds of traffic or users to off-peak times. Furthermore, packets can be designated for the LE PHB when the goal is to protect all other packet traffic from competition with the LE aggregate while not completely banning LE traffic from the network. An LE PHB SHOULD NOT be used for a customer's "normal Internet" traffic and packets SHOULD NOT be "downgraded" to the LE PHB instead of being dropped, particularly when the packets are unauthorized traffic. The LE PHB is expected to have applicability in networks that have at least some unused capacity during certain periods.
The LE PHB allows networks to protect themselves from selected types of traffic as a complement to giving preferential treatment to other selected traffic aggregates. LE ought not be used for the general case of downgraded traffic, but it could be used by design, e.g., to protect an internal network from untrusted external traffic sources. In this case, there is no way for attackers to preempt internal (non-LE) traffic by flooding. Another use case in this regard is the forwarding of multicast traffic from untrusted sources. Multicast forwarding is currently enabled within domains only for specific sources within a domain -- not for sources from anywhere in the Internet. One major problem is that multicast routing creates traffic sources at (mostly) unpredictable branching points within a domain, potentially leading to congestion and packet loss. In the case where multicast traffic packets from untrusted sources are forwarded as LE traffic, they will not harm traffic from non-LE BAs. A further related use case is mentioned in [RFC3754]: preliminary forwarding of non-admitted multicast traffic. 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 an additional traffic engineering tool for network administrators. For instance, it can be used to fill protection capacity of transmission links that is otherwise unused. Some network providers keep link utilization below 50% to ensure that all traffic is forwarded without loss after rerouting caused by a link failure (cf. Section 6 of [RFC3439]). LE-marked traffic can utilize the normally unused capacity and will be preempted automatically in the case of link failure when 100% of the link capacity is required for all other traffic. Ideally, applications mark their packets as LE traffic, because 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: o For traffic caused by World Wide Web search engines while they gather information from web servers. o For software updates or dissemination of new releases of operating systems. o For reporting errors or telemetry data from operating systems or applications. o For backup traffic, non-time-critical synchronization, or mirroring traffic. o For content distribution transfers between caches.
o For preloading or prefetching objects from web sites.
o For network news and other "bulk mail" of the Internet.
o For "downgraded" traffic from some other PHB when this does not
violate the operational objectives of the other PHB.
o For multicast traffic from untrusted (e.g., non-local) sources.
4. PHB Description
The LE PHB is defined in relation to the default PHB (BE). A packet
forwarded with the LE PHB SHOULD have lower precedence than packets
forwarded with the default PHB, i.e., in the case of congestion,
LE-marked traffic SHOULD be dropped prior to dropping any default PHB
traffic. Ideally, LE packets would be forwarded only when no packet
with any other PHB is awaiting transmission. This means that in the
case of link resource contention LE traffic can be starved
completely, which may not always be desired by the network operator's
policy. A scheduler used to implement the LE PHB may reflect this
policy accordingly.
A straightforward implementation could be a simple priority scheduler
serving the default PHB queue with higher priority than the LE PHB
queue. Alternative implementations may use scheduling algorithms
that assign a very small weight to the LE class. This, 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 share
is not.
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
drop all arriving LE packets as soon as certain queue length or
sojourn time thresholds are exceeded.
Since congestion control is also useful within the LE traffic class,
Explicit Congestion Notification (ECN) [RFC3168] SHOULD be used for
LE packets, too. More specifically, an LE implementation SHOULD also
apply Congestion Experienced (CE) marking for ECT-marked packets
("ECT" stands for ECN-Capable Transport), and transport protocols
used for LE SHOULD support and employ ECN. For more information on
the benefits of using ECN, see [RFC8087].
5. Traffic-Conditioning Actions
If possible, packets SHOULD be pre-marked in DS-aware end systems by applications due to their specific knowledge about the particular precedence of packets. There is no incentive for DS domains to distrust this initial marking, because letting LE traffic enter a DS domain causes no harm. Thus, any policing, such as limiting the rate of LE traffic, is not necessary at the DS boundary. As for most other PHBs, an initial classification and marking can also be performed at the first DS boundary node according to the DS domain's own policies (e.g., as a protection measure against untrusted sources). However, non-LE traffic (e.g., BE traffic) SHOULD NOT be re-marked to LE. Re-marking traffic from another PHB results in that traffic being "downgraded". This changes the way the network treats this traffic, and it is important not to violate the operational objectives of the original PHB. See Sections 3 and 8 for notes related to downgrading.6. Recommended DSCP
The RECOMMENDED codepoint for the LE PHB is '000001'. Earlier specifications (e.g., [RFC4594]) recommended the use of Class Selector 1 (CS1) as the codepoint (as mentioned in [RFC3662]). This is problematic, since it may cause a priority inversion in Diffserv domains that treat CS1 as originally proposed in [RFC2474], resulting in forwarding LE packets with higher precedence than BE packets. Existing implementations SHOULD transition to use the unambiguous LE codepoint '000001' whenever possible. This particular codepoint was chosen due to measurements on the currently observable Differentiated Services Code Point (DSCP) re-marking behavior in the Internet [IETF99-Secchi]. Since some network domains set the former IP Precedence bits to zero, it is possible that some other standardized DSCPs get mapped to the LE PHB DSCP if it were taken from the DSCP Standards Action Pool 1 (xxxxx0) [RFC2474] [RFC8436].
7. Deployment Considerations
In order to enable LE support, DS nodes typically only need o A BA classifier (see [RFC2475]) that classifies packets according to the LE DSCP o A dedicated LE queue o A suitable scheduling discipline, e.g., simple priority queueing Alternatively, implementations could use active queue management mechanisms instead of a dedicated LE queue, e.g., dropping all arriving LE packets when certain queue length or sojourn time thresholds are exceeded. Internet-wide deployment of the LE PHB is eased by the following properties: o No harm to other traffic: since the LE PHB has the lowest forwarding priority, it does not consume resources from other PHBs. Deployment across different provider domains with LE support causes no trust issues or attack vectors to existing (non-LE) traffic. Thus, providers can trust LE markings from end systems, i.e., there is no need to police or re-mark incoming LE traffic. o No PHB parameters or configuration of traffic profiles: the LE PHB itself possesses no parameters that need to be set or configured. Similarly, since LE traffic requires no admission or policing, it is not necessary to configure traffic profiles. o No traffic-conditioning mechanisms: the LE PHB requires no traffic meters, droppers, or shapers. See also Section 5 for further discussion. Operators of DS domains that cannot or do not want to implement the LE PHB (e.g., because there is no separate LE queue available in the corresponding nodes) SHOULD NOT drop packets marked with the LE DSCP. They SHOULD map packets with this DSCP to the default PHB and SHOULD preserve the LE DSCP marking. DS domain operators that do not implement the LE PHB should be aware that they violate the "no harm" property of LE. See also Section 8 for further discussion of forwarding LE traffic with the default PHB instead of the LE PHB.
8. Re-marking to Other DSCPs/PHBs
"DSCP bleaching", i.e., setting the DSCP to '000000' (default PHB) is NOT RECOMMENDED for this PHB. This may cause effects that are in contrast to the original intent to protect BE traffic from LE traffic (the "no harm" property). In the case that a DS domain does not support the LE PHB, its nodes SHOULD treat LE-marked packets with the default PHB instead (by mapping the LE DSCP to the default PHB), but they SHOULD do so without re-marking to DSCP '000000'. This is because DS domains that are traversed later may then still have the opportunity to treat such packets according to the LE PHB. Operators of DS domains that forward LE traffic within the BE aggregate need to be aware of the implications, i.e., induced congestion situations and QoS degradation of the original BE traffic. In this case, the LE property of not harming other traffic is no longer fulfilled. To limit the impact in such cases, traffic policing of the LE aggregate MAY be used. In the case that LE-marked packets are effectively carried with the default PHB (i.e., forwarded as BE traffic), they get a better forwarding treatment than expected. For some applications and services, it is favorable if the transmission is finished earlier 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 otherwise-unused resources are available. In the case that LE traffic is mapped to the default PHB, LE traffic may compete with BE traffic for the same resources and thus adversely affect the original BE aggregate. Applications that want to ensure the lower precedence compared to BE traffic even in such cases SHOULD additionally use a corresponding lower-than-BE transport protocol [RFC6297], e.g., LEDBAT [RFC6817]. A DS domain that still uses DSCP CS1 for marking LE traffic (including Low-Priority Data as defined in [RFC4594] or the old definition in [RFC3662]) SHOULD re-mark traffic to the LE DSCP '000001' at the egress to the next DS domain. This increases the probability that the DSCP is preserved end to end, whereas a CS1-marked packet may be re-marked by the default DSCP if the next domain is applying Diffserv-Interconnection [RFC8100].
9. Multicast Considerations
Basically, the multicast considerations in [RFC3754] apply. However, using the LE PHB for multicast requires paying special attention to how packets get replicated inside routers. Due to multicast packet replication, resource contention may actually occur even before a packet is forwarded to its output port. In the worst case, these forwarding resources are missing for higher-priority multicast or even unicast packets. Several forward error correction coding schemes, such as fountain codes (e.g., [RFC5053]), allow reliable data delivery even in environments with a potentially high amount of packet loss in transmission. When used, for example, over satellite links or other broadcast media, this means that receivers that lose 80% of packets in transmission simply need five times longer to receive the complete data than those receivers experiencing no loss (without any receiver feedback required). Superficially viewed, it may sound very attractive to use IP multicast with the LE PHB to build this type of opportunistic reliable distribution in IP networks, but it can only be usefully deployed with routers that do not experience forwarding/replication resource starvation when a large amount of packets (virtually) need to be replicated to links where the LE queue is full. Thus, a packet replication mechanism for LE-marked packets should consider the situation at the respective output links: it is a waste of internal forwarding resources if a packet is replicated to output links that have no resources left for LE forwarding. In those cases, a packet would have been replicated just to be dropped immediately after finding a filled LE queue at the respective output port. Such behavior could be avoided -- for example, by using a conditional internal packet replication: a packet would then only be replicated in cases where the output link is not fully used. This conditional replication, however, is probably not widely implemented. While the resource contention problem caused by multicast packet replication is also true for other Diffserv PHBs, LE forwarding is special, because often it is assumed that LE packets only get forwarded in the case of available resources at the output ports. The previously mentioned redundancy data traffic could suitably use the varying available residual bandwidth being utilized by the LE PHB, but only if the specific requirements stated above for conditional replication in the internal implementation of the network devices are considered.
(next page on part 2)
