idnits 2.17.1 draft-ietf-tsvwg-le-phb-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC8325, but the abstract doesn't seem to directly say this. It does mention RFC8325 though, so this could be OK. -- The draft header indicates that this document updates RFC4594, but the abstract doesn't seem to directly say this. It does mention RFC4594 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4594, updated by this document, for RFC5378 checks: 2005-02-14) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 3, 2018) is 2116 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC7657' is mentioned on line 508, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 502, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2475 -- Obsolete informational reference (is this intentional?): RFC 3662 (Obsoleted by RFC 8622) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Bless 3 Internet-Draft Karlsruhe Institute of Technology (KIT) 4 Obsoletes: 3662 (if approved) July 3, 2018 5 Updates: 4594,8325 (if approved) 6 Intended status: Standards Track 7 Expires: January 4, 2019 9 A Lower Effort Per-Hop Behavior (LE PHB) 10 draft-ietf-tsvwg-le-phb-05 12 Abstract 14 This document specifies properties and characteristics of a Lower 15 Effort (LE) per-hop behavior (PHB). The primary objective of this LE 16 PHB is to protect best-effort (BE) traffic (packets forwarded with 17 the default PHB) from LE traffic in congestion situations, i.e., when 18 resources become scarce, best-effort traffic has precedence over LE 19 traffic and may preempt it. Alternatively, packets forwarded by the 20 LE PHB can be associated with a scavenger service class, i.e., they 21 scavenge otherwise unused resources only. There are numerous uses 22 for this PHB, e.g., for background traffic of low precedence, such as 23 bulk data transfers with low priority in time, non time-critical 24 backups, larger software updates, web search engines while gathering 25 information from web servers and so on. This document recommends a 26 standard DSCP value for the LE PHB. This specification obsoletes RFC 27 3662 and updates the DSCP recommended in RFC 4594 and RFC 8325 to use 28 the DSCP assigned in this specification. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 4, 2019. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 78 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 79 4. PHB Description . . . . . . . . . . . . . . . . . . . . . . . 5 80 5. Traffic Conditioning Actions . . . . . . . . . . . . . . . . 6 81 6. Recommended DS Codepoint . . . . . . . . . . . . . . . . . . 6 82 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 7 83 8. Remarking to other DSCPs/PHBs . . . . . . . . . . . . . . . . 8 84 9. The Update to RFC 4594 . . . . . . . . . . . . . . . . . . . 8 85 10. The Update to RFC 8325 . . . . . . . . . . . . . . . . . . . 10 86 11. The Update to draft-ietf-tsvwg-rtcweb-qos . . . . . . . . . . 10 87 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 88 13. Security Considerations . . . . . . . . . . . . . . . . . . . 12 89 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 14.1. Normative References . . . . . . . . . . . . . . . . . . 12 91 14.2. Informative References . . . . . . . . . . . . . . . . . 13 92 Appendix A. History of the LE PHB . . . . . . . . . . . . . . . 15 93 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 15 94 Appendix C. Change History . . . . . . . . . . . . . . . . . . . 15 95 Appendix D. Note to RFC Editor . . . . . . . . . . . . . . . . . 17 96 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 98 1. Introduction 100 This document defines a Differentiated Services per-hop behavior 101 [RFC2474] called "Lower Effort" (LE), which is intended for traffic 102 of sufficiently low urgency that all other traffic takes precedence 103 over the LE traffic in consumption of network link bandwidth. Low 104 urgency traffic has a low priority for timely forwarding, which does 105 not necessarily imply that it is generally of minor importance. From 106 this viewpoint, it can be considered as a network equivalent to a 107 background priority for processes in an operating system. There may 108 or may not be memory (buffer) resources allocated for this type of 109 traffic. 111 Some networks carry traffic for which delivery is considered 112 optional; that is, packets of this type of traffic ought to consume 113 network resources only when no other traffic is present. In this 114 point of view, packets forwarded by the LE PHB scavenge otherwise 115 unused resources only, which led to the name "scavenger service" in 116 early Internet2 deployments (Appendix A). Other commonly used names 117 for LE PHB type services are "Lower-than-best-effort" or "Less-than- 118 best-effort". Alternatively, the effect of this type of traffic on 119 all other network traffic is strictly limited ("no harm" property). 120 This is distinct from "best-effort" (BE) traffic since the network 121 makes no commitment to deliver LE packets. In contrast, BE traffic 122 receives an implied "good faith" commitment of at least some 123 available network resources. This document proposes a Lower Effort 124 Differentiated Services per-hop behavior (LE PHB) for handling this 125 "optional" traffic in a differentiated services node. 127 2. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in BCP 132 14 [RFC2119] [RFC8174] when, and only when, they appear in all 133 capitals, as shown here. 135 3. Applicability 137 A Lower Effort PHB is applicable for many applications that otherwise 138 use best-effort delivery. More specifically, it is suitable for 139 traffic and services that can tolerate strongly varying throughput 140 for their data flows, especially periods of very low throughput or 141 even starvation (i.e., long interruptions due to significant or even 142 complete packet loss). Therefore, an application sending an LE 143 marked flow needs to be able to tolerate short or (even very) long 144 interruptions due to the presence of severe congestion conditions 145 during the transmission of the flow. Thus, there ought to be an 146 expectation that packets of the LE PHB could be excessively delayed 147 or dropped when any other traffic is present. The LE PHB is suitable 148 for sending traffic of low urgency across a Differentiated Services 149 (DS) domain or DS region. 151 Just like best-effort traffic, LE traffic SHOULD be congestion 152 controlled (i.e., use a congestion controlled transport or implement 153 an appropriate congestion control method [RFC8085]). Since LE 154 traffic could be starved completely for a longer period of time, 155 transport protocols or applications (and their related congestion 156 control mechanisms) SHOULD be able to detect and react to such a 157 situation and ought to resume the transfer as soon as possible. 158 Congestion control is not only useful to let the flows within the LE 159 behavior aggregate adapt to the available bandwidth that may be 160 highly fluctuating, but is also essential if LE traffic is mapped to 161 the default PHB in DS domains that do not support LE. 163 Use of the LE PHB might assist a network operator in moving certain 164 kinds of traffic or users to off-peak times. Alternatively, or in 165 addition, packets can be designated for the LE PHB when the goal is 166 to protect all other packet traffic from competition with the LE 167 aggregate while not completely banning LE traffic from the network. 168 An LE PHB SHOULD NOT be used for a customer's "normal Internet" 169 traffic nor should packets be "downgraded" to the LE PHB instead of 170 being dropped, particularly when the packets are unauthorized 171 traffic. The LE PHB is expected to have applicability in networks 172 that have at least some unused capacity at certain periods. 174 The LE PHB allows networks to protect themselves from selected types 175 of traffic as a complement to giving preferential treatment to other 176 selected traffic aggregates. LE ought not to be used for the general 177 case of downgraded traffic, but could be used by design, e.g., to 178 protect an internal network from untrusted external traffic sources. 179 In this case there is no way for attackers to preempt internal (non 180 LE) traffic by flooding. Another use case in this regard is 181 forwarding of multicast traffic from untrusted sources. Multicast 182 forwarding is currently enabled within domains only for specific 183 sources within a domain, but not for sources from anywhere in the 184 Internet. A main problem is that multicast routing creates traffic 185 sources at (mostly) unpredictable branching points within a domain, 186 potentially leading to congestion and packet loss. In the case of 187 multicast traffic packets from untrusted sources are forwarded as LE 188 traffic, they will not harm traffic from non-LE behavior aggregates. 189 A further related use case is mentioned in [RFC3754]: preliminary 190 forwarding of non-admitted multicast traffic. 192 There is no intrinsic reason to limit the applicability of the LE PHB 193 to any particular application or type of traffic. It is intended as 194 an additional traffic engineering tool for network administrators. 195 For instance, it can be used to fill protection capacity of 196 transmission links that is otherwise unused. Some network providers 197 keep link utilization below 50% to ensure that all traffic is 198 forwarded without loss after rerouting caused by a link failure (cf. 199 Section 6 of [RFC3439]). LE marked traffic can utilize the normally 200 unused capacity and will be preempted automatically in case of link 201 failure when 100% of the link capacity is required for all other 202 traffic. Ideally, applications mark their packets as LE traffic, 203 since they know the urgency of flows. 205 Example uses for the LE PHB: 207 o For traffic caused by world-wide web search engines while they 208 gather information from web servers. 210 o For software updates or dissemination of new releases of operating 211 systems. 213 o For reporting errors or telemetry data from operating systems or 214 applications. 216 o For backup traffic or non-time critical synchronization or 217 mirroring traffic. 219 o For content distribution transfers between caches. 221 o For preloading or prefetching objects from web sites. 223 o For network news and other "bulk mail" of the Internet. 225 o For "downgraded" traffic from some other PHB when this does not 226 violate the operational objectives of the other PHB. 228 o For multicast traffic from untrusted (e.g., non-local) sources. 230 4. PHB Description 232 The LE PHB is defined in relation to the default PHB (best-effort). 233 A packet forwarded with the LE PHB SHOULD have lower precedence than 234 packets forwarded with the default PHB, i.e., in the case of 235 congestion, LE marked traffic SHOULD be dropped prior to dropping any 236 default PHB traffic. Ideally, LE packets SHOULD be forwarded only if 237 no packet with any other PHB is awaiting transmission. 239 A straightforward implementation could be a simple priority scheduler 240 serving the default PHB queue with higher priority than the lower- 241 effort PHB queue. Alternative implementations may use scheduling 242 algorithms that assign a very small weight to the LE class. This, 243 however, could sometimes cause better service for LE packets compared 244 to BE packets in cases when the BE share is fully utilized and the LE 245 share not. 247 If a dedicated LE queue is not available, an active queue management 248 mechanism within a common BE/LE queue could also be used. This could 249 drop all arriving LE packets as soon as certain queue length or 250 sojourn time thresholds are exceeded. 252 Since congestion control is also useful within the LE traffic class, 253 Explicit Congestion Notification [RFC3168] SHOULD be used for LE 254 packets, too. 256 5. Traffic Conditioning Actions 258 If possible, packets SHOULD be pre-marked in DS-aware end systems by 259 applications due to their specific knowledge about the particular 260 precedence of packets. There is no incentive for DS domains to 261 distrust this initial marking, because letting LE traffic enter a DS 262 domain causes no harm. Thus, any policing such as limiting the rate 263 of LE traffic is not necessary at the DS boundary. 265 As for most other PHBs an initial classification and marking can be 266 also performed at the first DS boundary node according to the DS 267 domain's own policies (e.g., as protection measure against untrusted 268 sources). However, non-LE traffic (e.g., BE traffic) SHOULD NOT be 269 remarked to LE on a regular basis without consent or knowledge of the 270 user. See also remarks with respect to downgrading in Section 3 and 271 Section 8. 273 6. Recommended DS Codepoint 275 The RECOMMENDED codepoint for the LE PHB is '000001'. 277 Earlier specifications [RFC4594] recommended to use CS1 as codepoint 278 (as mentioned in [RFC3662]). This is problematic since it may cause 279 a priority inversion in DiffServ domains that treat CS1 as originally 280 proposed in [RFC2474], resulting in forwarding LE packets with higher 281 precedence than BE packets. Existing implementations SHOULD 282 transition to use the unambiguous LE codepoint '000001' whenever 283 possible. 285 This particular codepoint was chosen due to measurements on the 286 currently observable DSCP remarking behavior in the Internet 288 [ietf99-secchi]. Since some network domains set the former IP 289 precedence bits to zero, it is possible that some other standardized 290 DSCPs get mapped to the LE PHB DSCP if it were taken from the DSCP 291 standards action pool 1 (xxxxx0). 293 7. Deployment Considerations 295 In order to enable LE support, DS nodes typically only need 297 o A BA classifier (Behavior Aggregate classifier, see [RFC2475]) 298 that classifies packets according to the LE DSCP 300 o A dedicated LE queue 302 o A suitable scheduling discipline, e.g., simple priority queueing 304 Alternatively, implementations could use active queue management 305 mechanisms instead of a dedicated LE queue, e.g., dropping all 306 arriving LE packets when certain queue length or sojourn time 307 thresholds are exceeded. 309 Internet-wide deployment of the LE PHB is eased by the following 310 properties: 312 o No harm to other traffic: since the LE PHB has the lowest 313 forwarding priority it does not consume resources from other PHBs. 314 Deployment across different provider domains with LE support 315 causes no trust issues or attack vectors to existing (non LE) 316 traffic. Thus, providers can trust LE markings from end-systems, 317 i.e., there is no need to police or remark incoming LE traffic. 319 o No PHB parameters or configuration of traffic profiles: the LE PHB 320 itself possesses no parameters that need to be set or configured. 321 Similarly, since LE traffic requires no admission or policing, it 322 is not necessary to configure traffic profiles. 324 o No traffic conditioning mechanisms: the LE PHB requires no traffic 325 meters, droppers, or shapers. See also Section 5 for further 326 discussion. 328 Operators of DS domains that cannot or do not want to support the LE 329 PHB should be aware that they violate the "no harm" property of LE. 330 DS domains that do not offer support for the LE PHB support SHOULD 331 NOT drop packets marked with the LE DSCP. They SHOULD map packets 332 with this DSCP to the default PHB and SHOULD preserve the LE DSCP 333 marking. See also Section 8 for further discussion of forwarding LE 334 traffic with the default PHB instead. 336 8. Remarking to other DSCPs/PHBs 338 "DSCP bleaching", i.e., setting the DSCP to '000000' (default PHB) is 339 NOT RECOMMENDED for this PHB. This may cause effects that are in 340 contrast to the original intent in protecting BE traffic from LE 341 traffic (no harm property). In the case that a DS domain does not 342 support the LE PHB, its nodes SHOULD treat LE marked packets with the 343 default PHB instead (by mapping the LE DSCP to the default PHB), but 344 they SHOULD do so without remarking to DSCP '000000'. The reason for 345 this is that later traversed DS domains may then have still the 346 possibility to treat such packets according to the LE PHB. 348 Operators of DS domains that forward LE traffic within the BE 349 aggregate need to be aware of the implications, i.e., induced 350 congestion situations and quality-of-service degradation of the 351 original BE traffic. In this case, the LE property of not harming 352 other traffic is no longer fulfilled. To limit the impact in such 353 cases, traffic policing of the LE aggregate MAY be used. 355 In case LE marked packets are effectively carried within the default 356 PHB (i.e., forwarded as best-effort traffic) they get a better 357 forwarding treatment than expected. For some applications and 358 services, it is favorable if the transmission is finished earlier 359 than expected. However, in some cases it may be against the original 360 intention of the LE PHB user to strictly send the traffic only if 361 otherwise unused resources are available. In case LE traffic is 362 mapped to the default PHB, LE traffic may compete with BE traffic for 363 the same resources and thus adversely affect the original BE 364 aggregate. Applications that want to ensure the lower precedence 365 compared to BE traffic even in such cases SHOULD use additionally a 366 corresponding Lower-than-Best-Effort transport protocol [RFC6297], 367 e.g., LEDBAT [RFC6817]. 369 A DS domain that still uses DSCP CS1 for marking LE traffic 370 (including Low Priority-Data as defined in [RFC4594] or the old 371 definition in [RFC3662]) SHOULD remark traffic to the LE DSCP 372 '000001' at the egress to the next DS domain. This increases the 373 probability that the DSCP is preserved end-to-end, whereas a CS1 374 marked packet may be remarked by the default DSCP if the next domain 375 is applying DiffServ-intercon [RFC8100]. 377 9. The Update to RFC 4594 379 [RFC4594] recommended to use CS1 as codepoint in section 4.10, 380 whereas CS1 was defined in [RFC2474] to have a higher precedence than 381 CS0, i.e., the default PHB. Consequently, DiffServ domains 382 implementing CS1 according to [RFC2474] will cause a priority 383 inversion for LE packets that contradicts with the original purpose 384 of LE. Therefore, every occurrence of the CS1 DSCP is replaced by 385 the LE DSCP. 387 Changes: 389 o This update to RFC 4594 removes the following entry from figure 3: 391 |---------------+---------+-------------+--------------------------| 392 | Low-Priority | CS1 | 001000 | Any flow that has no BW | 393 | Data | | | assurance | 394 ------------------------------------------------------------------ 396 and replaces this by the following entry: 398 |---------------+---------+-------------+--------------------------| 399 | Low-Priority | LE | 000001 | Any flow that has no BW | 400 | Data | | | assurance | 401 ------------------------------------------------------------------ 403 o This update to RFC 4594 removes the following entry from figure 4: 405 |---------------+------+-------------------+---------+--------+----| 406 | Low-Priority | CS1 | Not applicable | RFC3662 | Rate | Yes| 407 | Data | | | | | | 408 ------------------------------------------------------------------ 410 and replaces this by the following entry: 412 |---------------+------+-------------------+---------+--------+----| 413 | Low-Priority | LE | Not applicable | RFCXXXX | Rate | Yes| 414 | Data | | | | | | 415 ------------------------------------------------------------------ 417 o Section 2.3 of [RFC4594] specifies: "In network segments that use 418 IP precedence marking, only one of the two service classes can be 419 supported, High-Throughput Data or Low-Priority Data. We 420 RECOMMEND that the DSCP value(s) of the unsupported service class 421 be changed to 000xx1 on ingress and changed back to original 422 value(s) on egress of the network segment that uses precedence 423 marking. For example, if Low-Priority Data is mapped to Standard 424 service class, then 000001 DSCP marking MAY be used to distinguish 425 it from Standard marked packets on egress." This document removes 426 this recommendation, because by using the herein defined LE DSCP 427 such remarking is not necessary. So even if Low-Priority Data is 428 unsupported (i.e., mapped to the default PHB) the LE DSCP should 429 be kept across the domain as RECOMMENDED in Section 8. 431 o This document removes the following line of RFC 4594, 432 Section 4.10: "The RECOMMENDED DSCP marking is CS1 (Class Selector 433 1)." and replaces this with the following text: "The RECOMMENDED 434 DSCP marking is LE (Lower Effort)." 436 10. The Update to RFC 8325 438 Section 4.2.10 of RFC 8325 [RFC8325] specifies "therefore, it is 439 RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to UP 1" 440 which is updated to "therefore, it is RECOMMENDED to map Low-Priority 441 Data traffic marked with LE DSCP or CS1 DSCP to UP 1" 443 This update to RFC 8325 removes the following entry from figure 1: 445 +---------------+------+----------+-------------+--------------------+ 446 | Low-Priority | CS1 | RFC 3662 | 1 | AC_BK (Background) | 447 | Data | | | | | 448 +--------------------------------------------------------------------+ 450 and replaces this by the following entry: 452 +---------------+------+----------+-------------+--------------------+ 453 | Low-Priority | LE | RFCXXXX | 1 | AC_BK (Background) | 454 | Data | | | | | 455 +--------------------------------------------------------------------+ 457 11. The Update to draft-ietf-tsvwg-rtcweb-qos 459 Section 5 of [I-D.ietf-tsvwg-rtcweb-qos] describes the Recommended 460 DSCP Values for WebRTC Applications 462 This update to [I-D.ietf-tsvwg-rtcweb-qos] replaces all occurences of 463 CS1 with LE in Table 1: 465 +------------------------+-------+------+-------------+-------------+ 466 | Flow Type | Very | Low | Medium | High | 467 | | Low | | | | 468 +------------------------+-------+------+-------------+-------------+ 469 | Audio | LE | DF | EF (46) | EF (46) | 470 | | (1) | (0) | | | 471 | | | | | | 472 | Interactive Video with | LE | DF | AF42, AF43 | AF41, AF42 | 473 | or without Audio | (1) | (0) | (36, 38) | (34, 36) | 474 | | | | | | 475 | Non-Interactive Video | LE | DF | AF32, AF33 | AF31, AF32 | 476 | with or without Audio | (1) | (0) | (28, 30) | (26, 28) | 477 | | | | | | 478 | Data | LE | DF | AF11 | AF21 | 479 | | (1) | (0) | | | 480 +------------------------+-------+------+-------------+-------------+ 482 and updates the following paragraph: 484 "The above table assumes that packets marked with CS1 are treated as 485 "less than best effort", such as the LE behavior described in 486 [RFC3662]. However, the treatment of CS1 is implementation 487 dependent. If an implementation treats CS1 as other than "less than 488 best effort", then the actual priority (or, more precisely, the per- 489 hop-behavior) of the packets may be changed from what is intended. 490 It is common for CS1 to be treated the same as DF, so applications 491 and browsers using CS1 cannot assume that CS1 will be treated 492 differently than DF [RFC7657]. However, it is also possible per 493 [RFC2474] for CS1 traffic to be given better treatment than DF, thus 494 caution should be exercised when electing to use CS1. This is one of 495 the cases where marking packets using these recommendations can make 496 things worse." 498 as follows: 500 "The above table assumes that packets marked with LE are treated as 501 lower effort (i.e., "less than best effort"), such as the LE behavior 502 described in [RFCXXXX]. However, the treatment of LE is 503 implementation dependent. If an implementation treats LE as other 504 than "less than best effort", then the actual priority (or, more 505 precisely, the per- hop-behavior) of the packets may be changed from 506 what is intended. It is common for LE to be treated the same as DF, 507 so applications and browsers using LE cannot assume that LE will be 508 treated differently than DF [RFC7657]." 510 12. IANA Considerations 512 This document assigns the Differentiated Services Field Codepoint 513 (DSCP) '000001' from the Differentiated Services Field Codepoints 514 (DSCP) registry (https://www.iana.org/assignments/dscp-registry/dscp- 515 registry.xhtml) (Pool 3, Codepoint Space xxxx01, Standards Action) to 516 the LE PHB. This document suggests to use a DSCP from Pool 3 in 517 order to avoid problems for other PHB marked flows to become 518 accidentally remarked as LE PHB, e.g., due to partial DSCP bleaching. 519 See [I-D.ietf-tsvwg-iana-dscp-registry] for the request to re- 520 classify Pool 3 for Standards Action. 522 IANA is requested to update the registry as follows: 524 o Name: LE 526 o Value (Binary): 000001 528 o Value (Decimal): 1 530 o Reference: [RFC number of this memo] 532 13. Security Considerations 534 There are no specific security exposures for this PHB. Since it 535 defines a new class of low forwarding priority, remarking other 536 traffic as LE traffic may lead to quality-of-service degradation of 537 such traffic. Thus, any attacker that is able to modify the DSCP of 538 a packet to LE may carry out a downgrade attack. See the general 539 security considerations in [RFC2474] and [RFC2475]. 541 With respect to privacy, an attacker could use the information from 542 the DSCP to infer that the transferred (probably even encrypted) 543 content is considered of low priority or low urgency by a user, in 544 case the DSCP was set on the user's request. However, this disclosed 545 information is only useful if some form of identification happened at 546 the same time, see [RFC6973] for further details on general privacy 547 threats. 549 14. References 551 14.1. Normative References 553 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 554 Requirement Levels", BCP 14, RFC 2119, 555 DOI 10.17487/RFC2119, March 1997, 556 . 558 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 559 "Definition of the Differentiated Services Field (DS 560 Field) in the IPv4 and IPv6 Headers", RFC 2474, 561 DOI 10.17487/RFC2474, December 1998, 562 . 564 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 565 and W. Weiss, "An Architecture for Differentiated 566 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 567 . 569 14.2. Informative References 571 [carlberg-lbe-2001] 572 Carlberg, K., Gevros, P., and J. Crowcroft, "Lower than 573 best effort: a design and implementation", SIGCOMM 574 Computer Communications Review Volume 31, Issue 2 575 supplement, April 2001, 576 . 578 [chown-lbe-2003] 579 Chown, T., Ferrari, T., Leinen, S., Sabatino, R., Simar, 580 N., and S. Venaas, "Less than Best Effort: Application 581 Scenarios and Experimental Results", In Proceedings of the 582 Second International Workshop on Quality of Service in 583 Multiservice IP Networks (QoS-IP 2003), Lecture Notes in 584 Computer Science, vol 2601. Springer, Berlin, 585 Heidelberg Pages 131-144, February 2003, 586 . 588 [draft-bless-diffserv-lbe-phb-00] 589 Bless, R. and K. Wehrle, "A Lower Than Best-Effort Per-Hop 590 Behavior", draft-bless-diffserv-lbe-phb-00 (work in 591 progress), September 1999, . 594 [I-D.ietf-tsvwg-iana-dscp-registry] 595 Fairhurst, G., "IANA Assignment of DSCP Pool 3 (xxxx01) 596 Values to require Publication of a Standards Track or Best 597 Current Practice RFC", draft-ietf-tsvwg-iana-dscp- 598 registry-08 (work in progress), June 2018. 600 [I-D.ietf-tsvwg-rtcweb-qos] 601 Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP 602 Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb- 603 qos-18 (work in progress), August 2016. 605 [ietf99-secchi] 606 Secchi, R., Venne, A., and A. Custura, "Measurements 607 concerning the DSCP for a LE PHB", Presentation held at 608 99th IETF Meeting, TSVWG, Prague , July 2017, 609 . 613 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 614 of Explicit Congestion Notification (ECN) to IP", 615 RFC 3168, DOI 10.17487/RFC3168, September 2001, 616 . 618 [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural 619 Guidelines and Philosophy", RFC 3439, 620 DOI 10.17487/RFC3439, December 2002, 621 . 623 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 624 Per-Domain Behavior (PDB) for Differentiated Services", 625 RFC 3662, DOI 10.17487/RFC3662, December 2003, 626 . 628 [RFC3754] Bless, R. and K. Wehrle, "IP Multicast in Differentiated 629 Services (DS) Networks", RFC 3754, DOI 10.17487/RFC3754, 630 April 2004, . 632 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 633 Guidelines for DiffServ Service Classes", RFC 4594, 634 DOI 10.17487/RFC4594, August 2006, 635 . 637 [RFC6297] Welzl, M. and D. Ros, "A Survey of Lower-than-Best-Effort 638 Transport Protocols", RFC 6297, DOI 10.17487/RFC6297, June 639 2011, . 641 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 642 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 643 DOI 10.17487/RFC6817, December 2012, 644 . 646 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 647 Morris, J., Hansen, M., and R. Smith, "Privacy 648 Considerations for Internet Protocols", RFC 6973, 649 DOI 10.17487/RFC6973, July 2013, 650 . 652 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 653 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 654 March 2017, . 656 [RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection 657 Classes and Practice", RFC 8100, DOI 10.17487/RFC8100, 658 March 2017, . 660 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 661 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 662 May 2017, . 664 [RFC8325] Szigeti, T., Henry, J., and F. Baker, "Mapping Diffserv to 665 IEEE 802.11", RFC 8325, DOI 10.17487/RFC8325, February 666 2018, . 668 Appendix A. History of the LE PHB 670 A first version of this PHB was suggested by Roland Bless and Klaus 671 Wehrle in September 1999 [draft-bless-diffserv-lbe-phb-00], named "A 672 Lower Than Best-Effort Per-Hop Behavior". After some discussion in 673 the DiffServ Working Group Brian Carpenter and Kathie Nichols 674 proposed a "bulk handling" per-domain behavior and believed a PHB was 675 not necessary. Eventually, "Lower Effort" was specified as per- 676 domain behavior and finally became [RFC3662]. More detailed 677 information about its history can be found in Section 10 of 678 [RFC3662]. 680 There are several other names in use for this type of PHB or 681 associated service classes. Well-known is the QBone Scavenger 682 Service (QBSS) that was proposed in March 2001 within the Internet2 683 QoS Working Group. Alternative names are "Lower-than-best-effort" 684 [carlberg-lbe-2001] or "Less-than-best-effort" [chown-lbe-2003]. 686 Appendix B. Acknowledgments 688 Since text is borrowed from earlier Internet-Drafts and RFCs the co- 689 authors of previous specifications are acknowledged here: Kathie 690 Nichols and Klaus Wehrle. David Black, Gorry Fairhurst, and Ruediger 691 Geib provided helpful comments and suggestions. 693 Appendix C. Change History 695 This section briefly lists changes between Internet-Draft versions 696 for convenience. 698 Changes in Version 05: 700 o added scavenger service class into abstract 702 o added some more history 704 o added reference for "Myth of Over-Provisioning" in RFC3439 and 705 references to presentations w.r.t. codepoint choices 707 o added text to update draft-ietf-tsvwg-rtcweb-qos 709 o revised text on congestion control in case of remarking to BE 711 o added reference to DSCP measurement talk @IETF99 713 o small typo fixes 715 Changes in Version 04: 717 o Several editorial changes according to review from Gorry Fairhurst 719 o Changed the section structure a bit (moved subsections 1.1 and 1.2 720 into own sections 3 and 7 respectively) 722 o updated section 2 on requirements language 724 o added updates to RFC 8325 726 o tried to be more explicit what changes are required to RFCs 4594 727 and 8325 729 Changes in Version 03: 731 o Changed recommended codepoint to 000001 733 o Added text to explain the reasons for the DSCP choice 735 o Removed LE-min,LE-strict discussion 737 o Added one more potential use case: reporting errors or telemetry 738 data from OSs 740 o Added privacy considerations to the security section (not worth an 741 own section I think) 743 o Changed IANA considerations section 745 Changes in Version 02: 747 o Applied many editorial suggestions from David Black 748 o Added Multicast traffic use case 750 o Clarified what is required for deployment in section 1.2 751 (Deployment Considerations) 753 o Added text about implementations using AQMs and ECN usage 755 o Updated IANA section according to David Black's suggestions 757 o Revised text in the security section 759 o Changed copyright Notice to pre5378Trust200902 761 Changes in Version 01: 763 o Now obsoletes RFC 3662. 765 o Tried to be more precise in section 1.1 (Applicability) according 766 to R. Geib's suggestions, so rephrased several paragraphs. Added 767 text about congestion control 769 o Change section 2 (PHB Description) according to R. Geib's 770 suggestions. 772 o Added RFC 2119 language to several sentences. 774 o Detailed the description of remarking implications and 775 recommendations in Section 8. 777 o Added Section 9 to explicitly list changes with respect to RFC 778 4594, because this document will update it. 780 Appendix D. Note to RFC Editor 782 This section lists actions for the RFC editor during final 783 formatting. 785 o Please replace the occurrences of RFCXXXX in Section 9 and 786 Section 10 with the assigned RFC number for this document. 788 o Delete Appendix C. 790 o Delete this section. 792 Author's Address 794 Roland Bless 795 Karlsruhe Institute of Technology (KIT) 796 Kaiserstr. 12 797 Karlsruhe 76131 798 Germany 800 Phone: +49 721 608 46413 801 Email: roland.bless@kit.edu