RFC 8622
A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services
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: o 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 | ------------------------------------------------------------------ o 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'."
o 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 | | | | | | ------------------------------------------------------------------- o 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." o 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
Section 4.2.10 of RFC 8325 [RFC8325] specifies that "[RFC3662] and [RFC4594] both recommend Low-Priority Data be marked CS1 DSCP." This is updated to "[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 removes the following paragraph in Section 4.2.10 of [RFC8325], because this document makes the anticipated change: "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." Section 4.2.10 of RFC 8325 [RFC8325] specifies that "therefore, it is RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to UP 1", which is 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 to RFC 8325 replaces the following entry from its Figure 1: +---------------+------+----------+------------+--------------------+ | Low-Priority | CS1 | RFC 3662 | 1 | AC_BK (Background) | | Data | | | | | +-------------------------------------------------------------------+ with the following entries: +---------------+------+----------+------------+--------------------+ | Low-Priority | LE | RFC 8622 | 1 | AC_BK (Background) | | Data | | | | | +-------------------------------------------------------------------+ | Low-Priority | CS1 | RFC 3662 | 1 | AC_BK (Background) | | Data (legacy) | | | | | +-------------------------------------------------------------------+12. IANA Considerations
This document assigns the Differentiated Services Field Codepoint (DSCP) '000001' from the "Differentiated Services Field Codepoints (DSCP)" registry (https://www.iana.org/assignments/dscp-registry/) ("DSCP Pool 3 Codepoints", Codepoint Space xxxx01, Standards Action) [RFC8126] to the LE PHB. This document uses a DSCP from Pool 3 in order to avoid problems for other PHB-marked flows, where they could become accidentally re-marked as LE PHB, e.g., due to partial DSCP bleaching. See [RFC8436] regarding reclassifying Pool 3 for Standards Action.
IANA has updated this registry as follows: o Name: LE o Value (Binary): 000001 o Value (Decimal): 1 o Reference: RFC 862213. Security Considerations
There are no specific security exposures for this PHB. Since it defines a new class that is of low forwarding priority, re-marking other traffic as LE traffic may lead to QoS degradation 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 security considerations in [RFC2474] and [RFC2475]. With respect to privacy, an attacker could use the information from the DSCP to infer that the transferred (probably even encrypted) content is considered of low priority or low urgency by a user if the DSCP was set per the user's request. On the one hand, this disclosed information is useful only if correlation with metadata (such as the user's IP address) and/or other flows reveal a user's 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]).
14. References
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
A first draft version of this PHB was suggested by Roland Bless and Klaus Wehrle in September 1999 [Diffserv-LBE-PHB], named "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 per-domain behavior and finally became [RFC3662]. More detailed information about its history can be found in Section 10 of [RFC3662]. There are several other names in use for this type of PHB or associated service classes. Well known is the QBone Scavenger Service (QBSS) that was proposed in March 2001 within the Internet2 QoS Working Group. Alternative names are "Lower than best effort" [Carlberg-LBE-2001] or "Less than best effort" [Chown-LBE-2003].Acknowledgments
Since text is partially borrowed from earlier Internet-Drafts and RFCs, the coauthors of previous specifications are acknowledged here: Kathie Nichols and Klaus Wehrle. David Black, Olivier Bonaventure, Spencer Dawkins, Toerless Eckert, Gorry Fairhurst, Ruediger Geib, and Kyle Rose provided helpful comments and (partially also text) suggestions.Author's Address
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