RFC 8622

A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services

📅 published June 2019, from ietf

RFC 8622: A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services 💖

Okay bestie, this is RFC 8622 🦋 and it's all about a Lower-Effort Per-Hop Behavior (LE PHB) 💅. It came from R. Bless at KIT and was published in June 2019 as an IETF Standards Track document, so it's an official Internet standard. It is ISSN 2070-1721. It obsoletes RFC 3662 (so 3662 is retired, bye) and updates RFCs 4594 and 8325 (so their DSCP recommendations now point to the DSCP value assigned in this spec) ✨. The title block is the vibe check, and this one is giving "new and improved." 🎀

(Part 1 of 5, more to come 🌸)

Abstract 🌸

Here the doc spells out the properties and characteristics of a Lower-Effort Per-Hop Behavior (LE PHB) ✨. The main goal is to protect Best-Effort (BE) traffic (packets forwarded with the default PHB) from LE traffic when things get congested. So when resources get scarce, BE traffic has precedence over LE traffic and may preempt it. 🫶

The LE PHB can also be tied to a scavenger service class, which means its packets only scavenge resources that would otherwise go unused 🍓. There are loads of uses for this, like low-priority background traffic such as bulk data transfers that aren't time-critical, non-urgent backups, bigger software updates, and web search engines gathering info from web servers, and more 💜. 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 so they 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, received public review, and has been approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 7841 💖.

Info about the current status of this document, any errata, and how to give feedback on it can be found at https://www.rfc-editor.org/info/rfc8622 ✨.

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) as in effect on the date this document was published. Please read these carefully, because 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 they come 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 people controlling the copyright in some of that material may not have granted the IETF Trust the right to allow modifications outside the IETF Standards Process. So unless you get an adequate license from whoever controls the copyright in those 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. The exceptions are formatting it for publication as an RFC or translating 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) 🎀. It's meant for traffic with such low urgency that all other traffic takes priority over it when it comes to using network link bandwidth. Low-urgency traffic has low priority for timely forwarding, but that does not necessarily mean it's unimportant 💜. Think of it as the network version of 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 should only use network resources when nobody else needs them. From that point of view, packets forwarded by the LE PHB scavenge otherwise-unused resources only, and that's where the name "scavenger service" came from in early Internet2 deployments (see Appendix A) 🍓. Other names people use for LE PHB services are "Lower than best effort" [Carlberg-LBE-2001] or "Less than best effort" [Chown-LBE-2003] 🌸. In summary, 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 🔥. Because of that, the effect of this traffic on all other network traffic is strictly limited. This is the "no harm" property 🫶. This is different from "Best-Effort" (BE) traffic, since the network makes no commitment to deliver LE packets. BE traffic, on the other hand, gets 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 ✨

okay so the LE PHB is giving "I'm fine waiting" 🦋. It's applicable for SO many apps that would otherwise just use BE delivery 💅. It's especially suitable for traffic and services that can handle wildly changing throughput for their data flows, like those periods of very low throughput or even starvation (aka long interruptions from significant or even complete packet loss) 😭. So an app sending an LE-marked flow has to be able to handle short or (even very) long interruptions when there's severe congestion during the flow 💀. There should be an expectation that LE packets could get excessively delayed or dropped whenever any other traffic is around 🙈. Whether a lack of progress counts as a failure depends on the app (for example, if a transport connection fails because it timed out, the app might try a few times to reestablish the connection to resume the session before finally giving up) 🌸. The LE PHB is perfect for low-urgency traffic 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 that starvation situation 👑. The vibe is to resume the transfer instead of aborting it! So an LE-optimized transport ought to use appropriate retry strategies (e.g., exponential back-off with an upper bound) and corresponding retry and timeout limits so it doesn't lose the connection during those starvation periods ✨. Quick resumption as soon as resources come back is the dream, but it may be hard to pull off in practice 😅. If there's no transport protocol or congestion control adapted to LE, applications can still use existing common transport protocols and implement session resumption by trying to reestablish failed connections 🧚. Congestion control isn't only useful for letting flows within the LE Behavior Aggregate (BA) adapt to available bandwidth (which can be highly fluctuating), it's also essential if LE traffic gets mapped to the default PHB in DS domains that don't support LE 🔥. In that case, background transport protocols, e.g., similar to Low Extra Delay Background Transport (LEDBAT) [RFC6817], are expedient 💜.

The LE PHB might help a network operator move certain kinds of traffic or users to off-peak times 🌙. Packets can also be marked for the LE PHB when the goal is to protect all other packet traffic from competing 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, especially when the packets are unauthorized traffic 🚫. The LE PHB is expected to be useful in networks that have at least some unused capacity during certain periods 🌈.

The LE PHB lets networks 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 that case, attackers have no way to preempt internal (non-LE) traffic by flooding 💪. Another use case is forwarding 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 big problem is that multicast routing creates traffic sources at (mostly) unpredictable branching points within a domain, which can lead to congestion and packet loss 📉. When multicast traffic from untrusted sources is forwarded as LE traffic, it won't harm traffic from non-LE BAs 🎀. A further related use case is mentioned in [RFC3754]: preliminary forwarding of non-admitted multicast traffic 🧐.

There's no intrinsic reason to limit the LE PHB to any particular application or type of traffic 🌸. It's meant to be an additional traffic engineering tool for network administrators 🛠️. For instance, it can be used to fill protection capacity of transmission links that would otherwise go unused. Some network providers keep link utilization below 50% so that all traffic is forwarded without loss after rerouting caused by a link failure (cf. Section 6 of [RFC3439]) 🤓. LE-marked traffic can use that normally unused capacity, and it will be preempted automatically when a link failure means 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 their flows 🧠. Since LE traffic may be starved for longer periods of time, it's probably less suitable for real-time and interactive applications 🙃.

Example uses for the LE PHB:

  • For traffic caused by World Wide Web search engines while they gather information from web servers 🔍.
  • For software updates or dissemination of new releases of operating systems 💿.
  • For reporting errors or telemetry data from operating systems or applications 📊.
  • For backup traffic, non-time-critical synchronization, or mirroring traffic 💾.
  • For content distribution transfers between caches 📦.
  • For preloading or prefetching objects from web sites 🕸️.
  • For network news and other "bulk mail" of the Internet 📰.
  • For "downgraded" traffic from some other PHB when this does not violate the operational objectives of the other PHB 🧃.
  • 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. So in the case of congestion, LE-marked traffic SHOULD be dropped before any default PHB traffic gets dropped 🥹. Ideally, LE packets would only be forwarded when no packet with any other PHB is waiting to be transmitted. That means that when link resources are contended, LE traffic can be starved completely, which may not always match the network operator's policy 😬. A scheduler used to implement the LE PHB may reflect that 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 give LE packets better service than BE packets, in cases when the BE share is fully utilized and the LE share isn't 🙀.

If a dedicated LE queue isn't available, an active queue management mechanism within a common BE/LE queue could also be used 🪣. It 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 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, since they have specific knowledge about the particular precedence of their packets 🧠. DS domains have no incentive to distrust this initial marking, because letting LE traffic enter a DS domain causes no harm ✨. So any policing, such as limiting the rate of LE traffic, isn't necessary at the DS boundary 🙌.

Like 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 means that traffic gets "downgraded". This changes how the network treats that traffic, so it's important not to violate the operational objectives of the original PHB 😤. See Sections 3 and 8 for notes related to downgrading 📖.

The RECOMMENDED codepoint for the LE PHB is '000001' 💜.

Earlier specifications (e.g., [RFC4594]) recommended using 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 LE packets being forwarded with higher precedence than BE packets 😱. Existing implementations SHOULD transition to the unambiguous LE codepoint '000001' whenever possible 🔄.

This particular codepoint was chosen due to measurements of 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's 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 🚀

Okay so bestie, to turn on LE support, DS nodes typically only need these three things 🫶

  • A BA classifier (see [RFC2475]) that classifies packets according to the LE DSCP
  • A dedicated LE queue
  • A suitable scheduling discipline, e.g., simple priority queueing

Or, plot twist 🦋, 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 these properties, and they're giving main character energy ✨

  • 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.
  • 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.
  • No traffic-conditioning mechanisms: the LE PHB requires no traffic meters, droppers, or shapers. See also Section 5 for further discussion.

Now the tricky bit 🥺 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. ✨

10. The Updates to RFC 4594 🍓

[RFC4594] recommended the use of CS1 as the codepoint in its Section 4.10, whereas CS1 was defined in [RFC2474] to have a higher precedence than CS0, i.e., the default PHB. Consequently, Diffserv domains implementing CS1 according to [RFC2474] will cause a priority inversion for LE packets that contradicts the original purpose of LE. Therefore, every occurrence of the CS1 DSCP is replaced by the LE DSCP. 💖

Changes:

  • This update to RFC 4594 removes the following entry from its Figure 3:
   |---------------+---------+-------------+--------------------------|
   | Low-Priority  |  CS1    |   001000    | Any flow that has no BW  |
   |     Data      |         |             | assurance                |
    ------------------------------------------------------------------

and replaces it with the following entry:

   |---------------+---------+-------------+--------------------------|
   | Low-Priority  |   LE    |   000001    | Any flow that has no BW  |
   |     Data      |         |             | assurance                |
    ------------------------------------------------------------------
  • This update to RFC 4594 extends the Notes text below Figure 3 that currently states "Notes for Figure 3: Default Forwarding (DF) and Class Selector 0 (CS0) provide equivalent behavior and use the same DS codepoint, '000000'." to state "Notes for Figure 3: Default Forwarding (DF) and Class Selector 0 (CS0) provide equivalent behavior and use the same DSCP, '000000'. The prior recommendation to use the CS1 DSCP for Low-Priority Data has been replaced by the current recommendation to use the LE DSCP, '000001'."
  • This update to RFC 4594 removes the following entry from its Figure 4:
   |---------------+------+-------------------+---------+--------+----|
   | Low-Priority  | CS1  | Not applicable    | RFC3662 |  Rate  | Yes|
   |     Data      |      |                   |         |        |    |
    ------------------------------------------------------------------

and replaces it with the following entry:

   |---------------+------+-------------------+----------+--------+----|
   | Low-Priority  | LE   | Not applicable    | RFC 8622 |  Rate  | Yes|
   |     Data      |      |                   |          |        |    |
    -------------------------------------------------------------------
  • Section 2.3 of [RFC4594] specifies the following: "In network segments that use IP precedence marking, only one of the two service classes can be supported, High-Throughput Data or Low-Priority Data. We RECOMMEND that the DSCP value(s) of the unsupported service class be changed to 000xx1 on ingress and changed back to original value(s) on egress of the network segment that uses precedence marking. For example, if Low-Priority Data is mapped to Standard service class, then 000001 DSCP marking MAY be used to distinguish it from Standard marked packets on egress." This document removes this recommendation, because by using the LE DSCP defined herein, such re-marking is not necessary. So, even if Low-Priority Data is unsupported (i.e., mapped to the default PHB), the LE DSCP should be kept across the domain as RECOMMENDED in Section 8. That removed text is replaced by the following: "In network segments that use IP Precedence marking, the Low-Priority Data service class receives the same Diffserv QoS as the Standard service class when the LE DSCP is used for Low-Priority Data traffic. This is acceptable behavior for the Low-Priority Data service class, although it is not the preferred behavior."
  • This document removes the following line in Section 4.10 of RFC 4594: "The RECOMMENDED DSCP marking is CS1 (Class Selector 1)." and replaces it with the following text: "The RECOMMENDED DSCP marking is LE (Lower Effort), which replaces the prior recommendation for CS1 (Class Selector 1) marking."

11. The Updates to RFC 8325 📝✨

Okay bestie, this section is where RFC 8325 gets a glow-up 💅 Section 4.2.10 of RFC 8325 [RFC8325] says that "[RFC3662] and [RFC4594] both recommend Low-Priority Data be marked CS1 DSCP." Now it becomes "[RFC3662] recommends that Low-Priority Data be marked CS1 DSCP. [RFC4594], as updated by RFC 8622, recommends that Low-Priority Data be marked LE DSCP." 🦋

This document also deletes the paragraph in Section 4.2.10 of [RFC8325] that was basically saying "this might change later." It's changing now, so the note is no longer needed 🫶 That note was: "Note: This marking recommendation may change in the future, as [LE-PHB] defines a Lower Effort (LE) PHB for Low-Priority Data traffic and recommends an additional DSCP for this traffic."

Next up, the UP mapping. Section 4.2.10 of RFC 8325 [RFC8325] says "therefore, it is RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to UP 1", and that gets updated to "therefore, it is RECOMMENDED to map Low-Priority Data traffic marked with LE DSCP or legacy CS1 DSCP to UP 1" 🌸

This update also swaps out one row of Figure 1 in RFC 8325. The old row goes:

   +---------------+------+----------+------------+--------------------+
   | Low-Priority  | CS1  | RFC 3662 |     1      | AC_BK (Background) |
   |     Data      |      |          |            |                    |
   +-------------------------------------------------------------------+

And it gets replaced with these two entries, so LE gets its own spot and legacy CS1 stays visible too 🎀

   +---------------+------+----------+------------+--------------------+
   | Low-Priority  | LE   | RFC 8622 |     1      | AC_BK (Background) |
   |     Data      |      |          |            |                    |
   +-------------------------------------------------------------------+
   | Low-Priority  | CS1  | RFC 3662 |     1      | AC_BK (Background) |
   | Data (legacy) |      |          |            |                    |
   +-------------------------------------------------------------------+

12. IANA Considerations 🌈

Here's the IANA situation. This document assigns the DSCP 000001 from the "Differentiated Services Field Codepoints (DSCP)" registry at https://www.iana.org/assignments/dscp-registry/. It's listed under "DSCP Pool 3 Codepoints", Codepoint Space xxxx01, Standards Action [RFC8126], and it goes to the LE PHB 🧚

Why Pool 3? Because the authors wanted to avoid trouble for other PHB-marked flows. If one of those got accidentally re-marked as LE PHB, say because of partial DSCP bleaching, that would be a mess 😭 See [RFC8436] for more on reclassifying Pool 3 for Standards Action.

IANA has updated the registry like this:

  • Name: LE
  • Value (Binary): 000001
  • Value (Decimal): 1
  • Reference: RFC 8622

13. Security Considerations 🔥💀

Okay, let's get serious for a sec. There are no specific security exposures for this PHB 🙈 But since it defines a brand-new class with low forwarding priority, re-marking other traffic as LE traffic may lead to QoS degradation of that traffic. That's a whole vibe shift for the traffic getting demoted. So any attacker who can change a packet's DSCP to LE may carry out a downgrade attack. Yikes. For the general security considerations, check out [RFC2474] and [RFC2475] 👑

Now for privacy, which is kind of a big deal 😭 An attacker could look at the DSCP and figure out that the transferred content (probably even encrypted) is considered low priority or low urgency by a user, but only if the DSCP was set based on that user's request. Is this info useful on its own? Not really. It becomes useful when it's correlated with metadata, like the user's IP address, or with other flows that reveal who someone is. But an observer, like a state-level actor, who wants to learn about a user's behavior from traffic could still find it handy. LE-marked background traffic, like software downloads, operating system updates, or telemetry data, may be less interesting for surveillance than general web traffic. So the LE marking may help the observer zoom in on potentially more interesting traffic. (Plot twist: the user can exploit this assumption and deliberately hide interesting traffic inside the LE aggregate 🦋) Apart from all that, the impact of the information disclosed by the LE DSCP is likely negligible in most cases, given the many traffic analysis possibilities and general privacy threats. See [RFC6973] for those.

14. References 📚

Here are the reference lists, copied exactly because citations matter 🫶

14.1. Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474,
              DOI 10.17487/RFC2474, December 1998,
              <https://www.rfc-editor.org/info/rfc2474>.

   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and W. Weiss, "An Architecture for Differentiated
              Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
              <https://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>.

14.2. Informative References

   [Carlberg-LBE-2001]
              Carlberg, K., Gevros, P., and J. Crowcroft, "Lower than
              best effort: a design and implementation", ACM SIGCOMM
              Computer Communication Review, Volume 31 Issue 2
              supplement, DOI 10.1145/844193.844208, April 2001,
              <https://dl.acm.org/citation.cfm?doid=844193.844208>.

   [Chown-LBE-2003]
              Chown, T., Ferrari, T., Leinen, S., Sabatino, R., Simar,
              N., and S. Venaas, "Less than Best Effort: Application
              Scenarios and Experimental Results", Proceedings of the
              Second International Workshop on Quality of Service in
              Multiservice IP Networks (QoS-IP 2003), Lecture Notes in
              Computer Science, vol 2601, Springer, Berlin, Heidelberg,
              Pages 131-144, DOI 10.1007/3-540-36480-3_10,
              February 2003, <https://link.springer.com/chapter/
              10.1007%2F3-540-36480-3_10>.

   [Diffserv-LBE-PHB]
              Bless, R. and K. Wehrle, "A Lower Than Best-Effort
              Per-Hop Behavior", Work in Progress,
              draft-bless-diffserv-lbe-phb-00, September 1999.

   [IETF99-Secchi]
              Secchi, R., Venne, A., and A. Custura, "Measurements
              concerning the DSCP for a LE PHB", Presentation held at
              the 99th IETF Meeting, TSVWG, Prague, July 2017,
              <https://datatracker.ietf.org/meeting/99/materials/
              slides-99-tsvwg-sessb-31measurements-concerning-
              the-dscp-for-a-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
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, DOI 10.17487/RFC3168, September 2001,
              <https://www.rfc-editor.org/info/rfc3168>.

   [RFC3439]  Bush, R. and D. Meyer, "Some Internet Architectural
              Guidelines and Philosophy", RFC 3439,
              DOI 10.17487/RFC3439, December 2002,
              <https://www.rfc-editor.org/info/rfc3439>.

   [RFC3662]  Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
              Per-Domain Behavior (PDB) for Differentiated Services",
              RFC 3662, DOI 10.17487/RFC3662, December 2003,
              <https://www.rfc-editor.org/info/rfc3662>.

   [RFC3754]  Bless, R. and K. Wehrle, "IP Multicast in Differentiated
              Services (DS) Networks", RFC 3754, DOI 10.17487/RFC3754,
              April 2004, <https://www.rfc-editor.org/info/rfc3754>.

   [RFC4594]  Babiarz, J., Chan, K., and F. Baker, "Configuration
              Guidelines for DiffServ Service Classes", RFC 4594,
              DOI 10.17487/RFC4594, August 2006,
              <https://www.rfc-editor.org/info/rfc4594>.

   [RFC5053]  Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer,
              "Raptor Forward Error Correction Scheme for Object
              Delivery", RFC 5053, DOI 10.17487/RFC5053, October 2007,
              <https://www.rfc-editor.org/info/rfc5053>.

   [RFC6297]  Welzl, M. and D. Ros, "A Survey of Lower-than-Best-Effort
              Transport Protocols", RFC 6297, DOI 10.17487/RFC6297,
              June 2011, <https://www.rfc-editor.org/info/rfc6297>.

   [RFC6817]  Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
              "Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
              DOI 10.17487/RFC6817, December 2012,
              <https://www.rfc-editor.org/info/rfc6817>.

   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
              Morris, J., Hansen, M., and R. Smith, "Privacy
              Considerations for Internet Protocols", RFC 6973,
              DOI 10.17487/RFC6973, July 2013,
              <https://www.rfc-editor.org/info/rfc6973>.

   [RFC8085]  Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
              Guidelines", BCP 145, RFC 8085, DOI 10.17487/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
              Classes and Practice", RFC 8100, DOI 10.17487/RFC8100,
              March 2017, <https://www.rfc-editor.org/info/rfc8100>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8325]  Szigeti, T., Henry, J., and F. Baker, "Mapping Diffserv to
              IEEE 802.11", RFC 8325, DOI 10.17487/RFC8325,
              February 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 🕰️🦋

Let's do a little history lesson, it's actually kind of iconic 👑 A first draft of this PHB was suggested by Roland Bless and Klaus Wehrle in September 1999 [Diffserv-LBE-PHB], and it was called "A Lower Than Best-Effort Per-Hop Behavior". After some discussion in the Diffserv Working Group, Brian Carpenter and Kathie Nichols proposed a "bulk handling" per-domain behavior and believed a PHB was not necessary 🙈 Eventually "Lower Effort" was specified as a per-domain behavior, and it finally became [RFC3662]. If you want the full story, Section 10 of [RFC3662] has more details.

It also goes by a bunch of other names, ngl. The QBone Scavenger Service (QBSS) was proposed in March 2001 within the Internet2 QoS Working Group, and it's the well-known one 🌸 Other alternative names are "Lower than best effort" [Carlberg-LBE-2001] and "Less than best effort" [Chown-LBE-2003]. Same energy, different outfits 💜

Acknowledgments ✨

okay bestie, big shoutout time 🫶 this spec borrowed some text from older Internet-Drafts and RFCs, so the coauthors of those earlier specs get credit here: Kathie Nichols and Klaus Wehrle 👑. Then a whole squad gave helpful comments and suggestions, and some of them even wrote bits of text 💜: David Black, Olivier Bonaventure, Spencer Dawkins, Toerless Eckert, Gorry Fairhurst, Ruediger Geib, and Kyle Rose 🦋 literally iconic behavior.

Author's Address 🎀

this is where you can reach the author, Roland Bless 🧚

Roland Bless
Karlsruhe Institute of Technology (KIT)
Institute of Telematics (TM)
Kaiserstr. 12
Karlsruhe  76131
Germany

Phone: +49 721 608 46413
Email: roland.bless@kit.edu
📦 where this page comes from