idnits 2.17.1 draft-ietf-tsvwg-le-phb-10.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 (March 11, 2019) is 1844 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: 'RFCXXXX' is mentioned on line 609, but not defined == Missing Reference: 'LE-PHB' is mentioned on line 539, but not defined == Missing Reference: 'RFC7657' is mentioned on line 615, 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 (~~), 4 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) March 11, 2019 5 Updates: 4594,8325 (if approved) 6 Intended status: Standards Track 7 Expires: September 12, 2019 9 A Lower Effort Per-Hop Behavior (LE PHB) for Differentiated Services 10 draft-ietf-tsvwg-le-phb-10 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 September 12, 2019. 47 Copyright Notice 49 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . 6 80 5. Traffic Conditioning Actions . . . . . . . . . . . . . . . . 7 81 6. Recommended DS Codepoint . . . . . . . . . . . . . . . . . . 7 82 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 7 83 8. Remarking to other DSCPs/PHBs . . . . . . . . . . . . . . . . 8 84 9. Multicast Considerations . . . . . . . . . . . . . . . . . . 9 85 10. The Update to RFC 4594 . . . . . . . . . . . . . . . . . . . 10 86 11. The Update to RFC 8325 . . . . . . . . . . . . . . . . . . . 12 87 12. The Update to draft-ietf-tsvwg-rtcweb-qos . . . . . . . . . . 12 88 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 89 14. Security Considerations . . . . . . . . . . . . . . . . . . . 14 90 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 15.1. Normative References . . . . . . . . . . . . . . . . . . 15 92 15.2. Informative References . . . . . . . . . . . . . . . . . 15 93 Appendix A. History of the LE PHB . . . . . . . . . . . . . . . 17 94 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 18 95 Appendix C. Change History . . . . . . . . . . . . . . . . . . . 18 96 Appendix D. Note to RFC Editor . . . . . . . . . . . . . . . . . 21 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 99 1. Introduction 101 This document defines a Differentiated Services per-hop behavior 102 [RFC2474] called "Lower Effort" (LE), which is intended for traffic 103 of sufficiently low urgency that all other traffic takes precedence 104 over the LE traffic in consumption of network link bandwidth. Low 105 urgency traffic has a low priority for timely forwarding, which does 106 not necessarily imply that it is generally of minor importance. From 107 this viewpoint, it can be considered as a network equivalent to a 108 background priority for processes in an operating system. There may 109 or may not be memory (buffer) resources allocated for this type of 110 traffic. 112 Some networks carry packets that ought to consume network resources 113 only when no other traffic is demanding them. In this point of view, 114 packets forwarded by the LE PHB scavenge otherwise unused resources 115 only, which led to the name "scavenger service" in early Internet2 116 deployments (see Appendix A). Other commonly used names for LE PHB 117 type services are "Lower-than-best-effort" or "Less-than-best- 118 effort". In summary, with the mentioned feature above, the LE PHB 119 has two important properties: it should scavenge residual capacity 120 and it must be preemptable by the default PHB (or other elevated 121 PHBs) in case they need more resources. Consequently, the effect of 122 this type of traffic on all other network traffic is strictly limited 123 ("no harm" property). This is distinct from "best-effort" (BE) 124 traffic since the network makes no commitment to deliver LE packets. 125 In contrast, BE traffic receives an implied "good faith" commitment 126 of at least some available network resources. This document proposes 127 a Lower Effort Differentiated Services per-hop behavior (LE PHB) for 128 handling this "optional" traffic in a differentiated services node. 130 2. Requirements Language 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in BCP 135 14 [RFC2119][RFC8174] when, and only when, they appear in all 136 capitals, as shown here. 138 3. Applicability 140 A Lower Effort PHB is applicable for many applications that otherwise 141 use best-effort delivery. More specifically, it is suitable for 142 traffic and services that can tolerate strongly varying throughput 143 for their data flows, especially periods of very low throughput or 144 even starvation (i.e., long interruptions due to significant or even 145 complete packet loss). Therefore, an application sending an LE 146 marked flow needs to be able to tolerate short or (even very) long 147 interruptions due to the presence of severe congestion conditions 148 during the transmission of the flow. Thus, there ought to be an 149 expectation that packets of the LE PHB could be excessively delayed 150 or dropped when any other traffic is present. It is application- 151 dependent when a lack of progress is considered being a failure 152 (e.g., if a transport connection fails due to timing out, the 153 application may try several times to re-establish the transport 154 connection in order to resume the application session before finally 155 giving up). The LE PHB is suitable for sending traffic of low 156 urgency across a Differentiated Services (DS) domain or DS region. 158 Just like best-effort traffic, LE traffic SHOULD be congestion 159 controlled (i.e., use a congestion controlled transport or implement 160 an appropriate congestion control method [RFC2914] [RFC8085]). Since 161 LE traffic could be starved completely for a longer period of time, 162 transport protocols or applications (and their related congestion 163 control mechanisms) SHOULD be able to detect and react to such a 164 starvation situation. An appropriate reaction would be to resume the 165 transfer instead of aborting it, i.e., an LE optimized transport 166 ought to use appropriate retry strategies (e.g., exponential back-off 167 with an upper bound) as well as corresponding retry and timeout 168 limits in order to avoid the loss of the connection due to the 169 mentioned starvation periods. While it is desirable to achieve a 170 quick resumption of the transfer as soon as resources become 171 available again, it may be difficult to achieve this in practice. In 172 lack of a transport protocol and congestion control that are adapted 173 to LE, applications can also use existing common transport protocols 174 and implement session resumption by trying to re-establish failed 175 connections. Congestion control is not only useful to let the flows 176 within the LE behavior aggregate adapt to the available bandwidth 177 that may be highly fluctuating, but is also essential if LE traffic 178 is mapped to the default PHB in DS domains that do not support LE. 179 In this case, use of background transport protocols, e.g., similar to 180 LEDBAT [RFC6817], is expedient. 182 Use of the LE PHB might assist a network operator in moving certain 183 kinds of traffic or users to off-peak times. Furthermore, packets 184 can be designated for the LE PHB when the goal is to protect all 185 other packet traffic from competition with the LE aggregate while not 186 completely banning LE traffic from the network. An LE PHB SHOULD NOT 187 be used for a customer's "normal Internet" traffic and packets SHOULD 188 NOT be "downgraded" to the LE PHB instead of being dropped, 189 particularly when the packets are unauthorized traffic. The LE PHB 190 is expected to have applicability in networks that have at least some 191 unused capacity at certain periods. 193 The LE PHB allows networks to protect themselves from selected types 194 of traffic as a complement to giving preferential treatment to other 195 selected traffic aggregates. LE ought not to be used for the general 196 case of downgraded traffic, but could be used by design, e.g., to 197 protect an internal network from untrusted external traffic sources. 198 In this case there is no way for attackers to preempt internal (non 199 LE) traffic by flooding. Another use case in this regard is 200 forwarding of multicast traffic from untrusted sources. Multicast 201 forwarding is currently enabled within domains only for specific 202 sources within a domain, but not for sources from anywhere in the 203 Internet. A major problem is that multicast routing creates traffic 204 sources at (mostly) unpredictable branching points within a domain, 205 potentially leading to congestion and packet loss. In the case of 206 multicast traffic packets from untrusted sources are forwarded as LE 207 traffic, they will not harm traffic from non-LE behavior aggregates. 208 A further related use case is mentioned in [RFC3754]: preliminary 209 forwarding of non-admitted multicast traffic. 211 There is no intrinsic reason to limit the applicability of the LE PHB 212 to any particular application or type of traffic. It is intended as 213 an additional traffic engineering tool for network administrators. 214 For instance, it can be used to fill protection capacity of 215 transmission links that is otherwise unused. Some network providers 216 keep link utilization below 50% to ensure that all traffic is 217 forwarded without loss after rerouting caused by a link failure (cf. 218 Section 6 of [RFC3439]). LE marked traffic can utilize the normally 219 unused capacity and will be preempted automatically in case of link 220 failure when 100% of the link capacity is required for all other 221 traffic. Ideally, applications mark their packets as LE traffic, 222 since they know the urgency of flows. Since LE traffic may be 223 starved for longer periods of time it is probably less suitable for 224 real-time and interactive applications. 226 Example uses for the LE PHB: 228 o For traffic caused by world-wide web search engines while they 229 gather information from web servers. 231 o For software updates or dissemination of new releases of operating 232 systems. 234 o For reporting errors or telemetry data from operating systems or 235 applications. 237 o For backup traffic or non-time critical synchronization or 238 mirroring traffic. 240 o For content distribution transfers between caches. 242 o For preloading or prefetching objects from web sites. 244 o For network news and other "bulk mail" of the Internet. 246 o For "downgraded" traffic from some other PHB when this does not 247 violate the operational objectives of the other PHB. 249 o For multicast traffic from untrusted (e.g., non-local) sources. 251 4. PHB Description 253 The LE PHB is defined in relation to the default PHB (best-effort). 254 A packet forwarded with the LE PHB SHOULD have lower precedence than 255 packets forwarded with the default PHB, i.e., in the case of 256 congestion, LE marked traffic SHOULD be dropped prior to dropping any 257 default PHB traffic. Ideally, LE packets would be forwarded only 258 when no packet with any other PHB is awaiting transmission. This 259 means that in case of link resource contention LE traffic can be 260 starved completely, which may not be always desired by the network 261 operator's policy. The used scheduler to implement the LE PHB may 262 reflect this policy accordingly. 264 A straightforward implementation could be a simple priority scheduler 265 serving the default PHB queue with higher priority than the lower- 266 effort PHB queue. Alternative implementations may use scheduling 267 algorithms that assign a very small weight to the LE class. This, 268 however, could sometimes cause better service for LE packets compared 269 to BE packets in cases when the BE share is fully utilized and the LE 270 share not. 272 If a dedicated LE queue is not available, an active queue management 273 mechanism within a common BE/LE queue could also be used. This could 274 drop all arriving LE packets as soon as certain queue length or 275 sojourn time thresholds are exceeded. 277 Since congestion control is also useful within the LE traffic class, 278 Explicit Congestion Notification (ECN) [RFC3168] SHOULD be used for 279 LE packets, too. More specifically, an LE implementation SHOULD also 280 apply CE marking for ECT marked packets and transport protocols used 281 for LE SHOULD support and employ ECN. For more information on the 282 benefits of using ECN see [RFC8087]. 284 5. Traffic Conditioning Actions 286 If possible, packets SHOULD be pre-marked in DS-aware end systems by 287 applications due to their specific knowledge about the particular 288 precedence of packets. There is no incentive for DS domains to 289 distrust this initial marking, because letting LE traffic enter a DS 290 domain causes no harm. Thus, any policing such as limiting the rate 291 of LE traffic is not necessary at the DS boundary. 293 As for most other PHBs an initial classification and marking can be 294 also performed at the first DS boundary node according to the DS 295 domain's own policies (e.g., as protection measure against untrusted 296 sources). However, non-LE traffic (e.g., BE traffic) SHOULD NOT be 297 remarked to LE. Remarking traffic from another PHB results in that 298 traffic being "downgraded". This changes the way the network treats 299 this traffic and it is important not to violate the operational 300 objectives of the original PHB. See also remarks with respect to 301 downgrading in Section 3 and Section 8. 303 6. Recommended DS Codepoint 305 The RECOMMENDED codepoint for the LE PHB is '000001'. 307 Earlier specifications [RFC4594] recommended to use CS1 as codepoint 308 (as mentioned in [RFC3662]). This is problematic since it may cause 309 a priority inversion in Diffserv domains that treat CS1 as originally 310 proposed in [RFC2474], resulting in forwarding LE packets with higher 311 precedence than BE packets. Existing implementations SHOULD 312 transition to use the unambiguous LE codepoint '000001' whenever 313 possible. 315 This particular codepoint was chosen due to measurements on the 316 currently observable DSCP remarking behavior in the Internet 317 [ietf99-secchi]. Since some network domains set the former IP 318 precedence bits to zero, it is possible that some other standardized 319 DSCPs get mapped to the LE PHB DSCP if it were taken from the DSCP 320 standards action pool 1 (xxxxx0). 322 7. Deployment Considerations 324 In order to enable LE support, DS nodes typically only need 326 o A BA classifier (Behavior Aggregate classifier, see [RFC2475]) 327 that classifies packets according to the LE DSCP 329 o A dedicated LE queue 331 o A suitable scheduling discipline, e.g., simple priority queueing 332 Alternatively, implementations could use active queue management 333 mechanisms instead of a dedicated LE queue, e.g., dropping all 334 arriving LE packets when certain queue length or sojourn time 335 thresholds are exceeded. 337 Internet-wide deployment of the LE PHB is eased by the following 338 properties: 340 o No harm to other traffic: since the LE PHB has the lowest 341 forwarding priority it does not consume resources from other PHBs. 342 Deployment across different provider domains with LE support 343 causes no trust issues or attack vectors to existing (non LE) 344 traffic. Thus, providers can trust LE markings from end-systems, 345 i.e., there is no need to police or remark incoming LE traffic. 347 o No PHB parameters or configuration of traffic profiles: the LE PHB 348 itself possesses no parameters that need to be set or configured. 349 Similarly, since LE traffic requires no admission or policing, it 350 is not necessary to configure traffic profiles. 352 o No traffic conditioning mechanisms: the LE PHB requires no traffic 353 meters, droppers, or shapers. See also Section 5 for further 354 discussion. 356 Operators of DS domains that cannot or do not want to implement the 357 LE PHB (e.g., because there is no separate LE queue available in the 358 corresponding nodes) SHOULD NOT drop packets marked with the LE DSCP. 359 They SHOULD map packets with this DSCP to the default PHB and SHOULD 360 preserve the LE DSCP marking. DS domains operators that do not 361 implement the LE PHB should be aware that they violate the "no harm" 362 property of LE. See also Section 8 for further discussion of 363 forwarding LE traffic with the default PHB instead. 365 8. Remarking to other DSCPs/PHBs 367 "DSCP bleaching", i.e., setting the DSCP to '000000' (default PHB) is 368 NOT RECOMMENDED for this PHB. This may cause effects that are in 369 contrast to the original intent in protecting BE traffic from LE 370 traffic (no harm property). In the case that a DS domain does not 371 support the LE PHB, its nodes SHOULD treat LE marked packets with the 372 default PHB instead (by mapping the LE DSCP to the default PHB), but 373 they SHOULD do so without remarking to DSCP '000000'. The reason for 374 this is that later traversed DS domains may then have still the 375 possibility to treat such packets according to the LE PHB. 377 Operators of DS domains that forward LE traffic within the BE 378 aggregate need to be aware of the implications, i.e., induced 379 congestion situations and quality-of-service degradation of the 380 original BE traffic. In this case, the LE property of not harming 381 other traffic is no longer fulfilled. To limit the impact in such 382 cases, traffic policing of the LE aggregate MAY be used. 384 In the case that LE marked packets are effectively carried within the 385 default PHB (i.e., forwarded as best-effort traffic) they get a 386 better forwarding treatment than expected. For some applications and 387 services, it is favorable if the transmission is finished earlier 388 than expected. However, in some cases it may be against the original 389 intention of the LE PHB user to strictly send the traffic only if 390 otherwise unused resources are available. In the case that LE 391 traffic is mapped to the default PHB, LE traffic may compete with BE 392 traffic for the same resources and thus adversely affect the original 393 BE aggregate. Applications that want to ensure the lower precedence 394 compared to BE traffic even in such cases SHOULD use additionally a 395 corresponding Lower-than-Best-Effort transport protocol [RFC6297], 396 e.g., LEDBAT [RFC6817]. 398 A DS domain that still uses DSCP CS1 for marking LE traffic 399 (including Low Priority-Data as defined in [RFC4594] or the old 400 definition in [RFC3662]) SHOULD remark traffic to the LE DSCP 401 '000001' at the egress to the next DS domain. This increases the 402 probability that the DSCP is preserved end-to-end, whereas a CS1 403 marked packet may be remarked by the default DSCP if the next domain 404 is applying Diffserv-Interconnection [RFC8100]. 406 9. Multicast Considerations 408 Basically, the multicast considerations in [RFC3754] apply. However, 409 using the Lower Effort PHB for multicast requires paying special 410 attention to the way how packets get replicated inside routers. Due 411 to multicast packet replication, resource contention may actually 412 occur even before a packet is forwarded to its output port and in the 413 worst case, these forwarding resources are missing for higher 414 prioritized multicast or even unicast packets. 416 Several forward error correction coding schemes such as fountain 417 codes (e.g., [RFC5053]) allow reliable data delivery even in 418 environments with a potential high amount of packet loss in 419 transmission. When used for example over satellite links or other 420 broadcast media, this means that receivers that lose 80% of packets 421 in transmission simply need 5 times as long to receive the complete 422 data than those receivers experiencing no loss (without any receiver 423 feedback required). 425 Superficially viewed, it may sound very attractive to use IP 426 multicast with the LE PHB to build this type of opportunistic 427 reliable distribution in IP networks, but it can only be usefully 428 deployed with routers that do not experience forwarding/replication 429 resource starvation when a large amount of packets (virtually) need 430 to be replicated to links where the LE queue is full. 432 Thus, packet replication of LE marked packets should consider the 433 situation at the respective output links: it is a waste of internal 434 forwarding resources if a packet is replicated to output links that 435 have no resources left for LE forwarding. In those cases a packet 436 would have been replicated just to be dropped immediately after 437 finding a filled LE queue at the respective output port. Such 438 behavior could be avoided for example by using a conditional internal 439 packet replication: a packet would then only be replicated in case 440 the output link is not fully used. This conditional replication, 441 however, is probably not widely implemented. 443 While the resource contention problem caused by multicast packet 444 replication is also true for other Diffserv PHBs, LE forwarding is 445 special, because often it is assumed that LE packets only get 446 forwarded in case of available resources at the output ports. The 447 previously mentioned redundancy data traffic could nicely use the 448 varying available residual bandwidth being utilized the by LE PHB, 449 but only if the specific requirements stated above for conditional 450 replication in the internal implementation of the network devices are 451 considered. 453 10. The Update to RFC 4594 455 [RFC4594] recommended to use CS1 as codepoint in section 4.10, 456 whereas CS1 was defined in [RFC2474] to have a higher precedence than 457 CS0, i.e., the default PHB. Consequently, Diffserv domains 458 implementing CS1 according to [RFC2474] will cause a priority 459 inversion for LE packets that contradicts with the original purpose 460 of LE. Therefore, every occurrence of the CS1 DSCP is replaced by 461 the LE DSCP. 463 Changes: 465 o This update to RFC 4594 removes the following entry from figure 3: 467 |---------------+---------+-------------+--------------------------| 468 | Low-Priority | CS1 | 001000 | Any flow that has no BW | 469 | Data | | | assurance | 470 ------------------------------------------------------------------ 472 and replaces this by the following entry: 474 |---------------+---------+-------------+--------------------------| 475 | Low-Priority | LE | 000001 | Any flow that has no BW | 476 | Data | | | assurance | 477 ------------------------------------------------------------------ 479 o This update to RFC 4594 extends the Notes text below figure 3 that 480 currently states "Notes for Figure 3: Default Forwarding (DF) and 481 Class Selector 0 (CS0) provide equivalent behavior and use the 482 same DS codepoint, '000000'." to state "Notes for Figure 3: 483 Default Forwarding (DF) and Class Selector 0 (CS0) provide 484 equivalent behavior and use the same DS codepoint, '000000'. The 485 prior recommendation to use the CS1 DSCP for Low-Priority Data has 486 been replaced by the current recommendation to use the LE DSCP, 487 '000001'." 489 o This update to RFC 4594 removes the following entry from figure 4: 491 |---------------+------+-------------------+---------+--------+----| 492 | Low-Priority | CS1 | Not applicable | RFC3662 | Rate | Yes| 493 | Data | | | | | | 494 ------------------------------------------------------------------ 496 and replaces this by the following entry: 498 |---------------+------+-------------------+---------+--------+----| 499 | Low-Priority | LE | Not applicable | RFCXXXX | Rate | Yes| 500 | Data | | | | | | 501 ------------------------------------------------------------------ 503 o Section 2.3 of [RFC4594] specifies: "In network segments that use 504 IP precedence marking, only one of the two service classes can be 505 supported, High-Throughput Data or Low-Priority Data. We 506 RECOMMEND that the DSCP value(s) of the unsupported service class 507 be changed to 000xx1 on ingress and changed back to original 508 value(s) on egress of the network segment that uses precedence 509 marking. For example, if Low-Priority Data is mapped to Standard 510 service class, then 000001 DSCP marking MAY be used to distinguish 511 it from Standard marked packets on egress." This document removes 512 this recommendation, because by using the herein defined LE DSCP 513 such remarking is not necessary. So even if Low-Priority Data is 514 unsupported (i.e., mapped to the default PHB) the LE DSCP should 515 be kept across the domain as RECOMMENDED in Section 8. That 516 removed text is replaced by: "In network segments that use IP 517 Precedence marking, the Low-Priority Data service class receives 518 the same Diffserv QoS as the Standard service class when the LE 519 DSCP is used for Low-Priority Data traffic. This is acceptable 520 behavior for the Low-Priority Data service class, although it is 521 not the preferred behavior." 523 o This document removes the following line of RFC 4594, 524 Section 4.10: "The RECOMMENDED DSCP marking is CS1 (Class Selector 525 1)." and replaces this with the following text: "The RECOMMENDED 526 DSCP marking is LE (Lower Effort), which replaces the prior 527 recommendation for CS1 (Class Selector 1) marking." 529 11. The Update to RFC 8325 531 Section 4.2.10 of RFC 8325 [RFC8325] specifies "[RFC3662] and 532 [RFC4594] both recommend Low-Priority Data be marked CS1 DSCP." 533 which is updated to "[RFC3662] recommends that Low-Priority Data be 534 marked CS1 DSCP. [RFC4594] as updated by [RFCXXXX] recommends Low- 535 Priority Data be marked LE DSCP." 537 This document removes the following paragraph of RFC 8325, 538 Section 4.2.10 because this document makes the anticipated change: 539 "Note: This marking recommendation may change in the future, as [LE- 540 PHB] defines a Lower Effort (LE) PHB for Low-Priority Data traffic 541 and recommends an additional DSCP for this traffic." 543 Section 4.2.10 of RFC 8325 [RFC8325] specifies "therefore, it is 544 RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to UP 1" 545 which is updated to "therefore, it is RECOMMENDED to map Low-Priority 546 Data traffic marked with LE DSCP or legacy CS1 DSCP to UP 1" 548 This update to RFC 8325 replaces the following entry from figure 1: 550 +---------------+------+----------+-------------+--------------------+ 551 | Low-Priority | CS1 | RFC 3662 | 1 | AC_BK (Background) | 552 | Data | | | | | 553 +--------------------------------------------------------------------+ 555 by the following entries: 557 +---------------+------+----------+-------------+--------------------+ 558 | Low-Priority | LE | RFCXXXX | 1 | AC_BK (Background) | 559 | Data | | | | | 560 +--------------------------------------------------------------------+ 561 | Low-Priority | CS1 | RFC 3662 | 1 | AC_BK (Background) | 562 | Data (legacy) | | | | | 563 +--------------------------------------------------------------------+ 565 12. The Update to draft-ietf-tsvwg-rtcweb-qos 567 Section 5 of [I-D.ietf-tsvwg-rtcweb-qos] describes the Recommended 568 DSCP Values for WebRTC Applications 569 This update to [I-D.ietf-tsvwg-rtcweb-qos] replaces all occurrences 570 of CS1 with LE in Table 1: 572 +------------------------+-------+------+-------------+-------------+ 573 | Flow Type | Very | Low | Medium | High | 574 | | Low | | | | 575 +------------------------+-------+------+-------------+-------------+ 576 | Audio | LE | DF | EF (46) | EF (46) | 577 | | (1) | (0) | | | 578 | | | | | | 579 | Interactive Video with | LE | DF | AF42, AF43 | AF41, AF42 | 580 | or without Audio | (1) | (0) | (36, 38) | (34, 36) | 581 | | | | | | 582 | Non-Interactive Video | LE | DF | AF32, AF33 | AF31, AF32 | 583 | with or without Audio | (1) | (0) | (28, 30) | (26, 28) | 584 | | | | | | 585 | Data | LE | DF | AF11 | AF21 | 586 | | (1) | (0) | | | 587 +------------------------+-------+------+-------------+-------------+ 589 and updates the following paragraph: 591 "The above table assumes that packets marked with CS1 are treated as 592 "less than best effort", such as the LE behavior described in 593 [RFC3662]. However, the treatment of CS1 is implementation 594 dependent. If an implementation treats CS1 as other than "less than 595 best effort", then the actual priority (or, more precisely, the per- 596 hop-behavior) of the packets may be changed from what is intended. 597 It is common for CS1 to be treated the same as DF, so applications 598 and browsers using CS1 cannot assume that CS1 will be treated 599 differently than DF [RFC7657]. However, it is also possible per 600 [RFC2474] for CS1 traffic to be given better treatment than DF, thus 601 caution should be exercised when electing to use CS1. This is one of 602 the cases where marking packets using these recommendations can make 603 things worse." 605 as follows: 607 "The above table assumes that packets marked with LE are treated as 608 lower effort (i.e., "less than best effort"), such as the LE behavior 609 described in [RFCXXXX]. However, the treatment of LE is 610 implementation dependent. If an implementation treats LE as other 611 than "less than best effort", then the actual priority (or, more 612 precisely, the per- hop-behavior) of the packets may be changed from 613 what is intended. It is common for LE to be treated the same as DF, 614 so applications and browsers using LE cannot assume that LE will be 615 treated differently than DF [RFC7657]. During development of this 616 document, the CS1 DSCP was recommended for "very low" application 617 priority traffic; implementations that followed that recommendation 618 SHOULD be updated to use the LE DSCP instead of the CS1 DSCP." 620 13. IANA Considerations 622 This document assigns the Differentiated Services Field Codepoint 623 (DSCP) '000001' from the Differentiated Services Field Codepoints 624 (DSCP) registry (https://www.iana.org/assignments/dscp-registry/dscp- 625 registry.xhtml) (Pool 3, Codepoint Space xxxx01, Standards Action) to 626 the LE PHB. This document suggests to use a DSCP from Pool 3 in 627 order to avoid problems for other PHB marked flows to become 628 accidentally remarked as LE PHB, e.g., due to partial DSCP bleaching. 629 See [RFC8436] for re-classifying Pool 3 for Standards Action. 631 IANA is requested to update the registry as follows: 633 o Name: LE 635 o Value (Binary): 000001 637 o Value (Decimal): 1 639 o Reference: [RFC number of this memo] 641 14. Security Considerations 643 There are no specific security exposures for this PHB. Since it 644 defines a new class of low forwarding priority, remarking other 645 traffic as LE traffic may lead to quality-of-service degradation of 646 such traffic. Thus, any attacker that is able to modify the DSCP of 647 a packet to LE may carry out a downgrade attack. See the general 648 security considerations in [RFC2474] and [RFC2475]. 650 With respect to privacy, an attacker could use the information from 651 the DSCP to infer that the transferred (probably even encrypted) 652 content is considered of low priority or low urgency by a user, in 653 case the DSCP was set on the user's request. On the one hand, this 654 disclosed information is useful only if correlation with metadata 655 (such as the user's IP address) and/or other flows reveal user 656 identity. On the other hand, it might help an observer (e.g., a 657 state level actor) who is interested in learning about the user's 658 behavior from observed traffic: LE marked background traffic (such as 659 software downloads, operating system updates, or telemetry data) may 660 be less interesting for surveillance than general web traffic. 661 Therefore, the LE marking may help the observer to focus on 662 potentially more interesting traffic (however, the user may exploit 663 this particular assumption and deliberately hide interesting traffic 664 in the LE aggregate). Apart from such considerations, the impact of 665 disclosed information by the LE DSCP is likely negligible in most 666 cases given the numerous traffic analysis possibilities and general 667 privacy threats (e.g., see [RFC6973]). 669 15. References 671 15.1. Normative References 673 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 674 Requirement Levels", BCP 14, RFC 2119, 675 DOI 10.17487/RFC2119, March 1997, 676 . 678 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 679 "Definition of the Differentiated Services Field (DS 680 Field) in the IPv4 and IPv6 Headers", RFC 2474, 681 DOI 10.17487/RFC2474, December 1998, 682 . 684 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 685 and W. Weiss, "An Architecture for Differentiated 686 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 687 . 689 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 690 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 691 May 2017, . 693 15.2. Informative References 695 [carlberg-lbe-2001] 696 Carlberg, K., Gevros, P., and J. Crowcroft, "Lower than 697 best effort: a design and implementation", SIGCOMM 698 Computer Communications Review Volume 31, Issue 2 699 supplement, April 2001, 700 . 702 [chown-lbe-2003] 703 Chown, T., Ferrari, T., Leinen, S., Sabatino, R., Simar, 704 N., and S. Venaas, "Less than Best Effort: Application 705 Scenarios and Experimental Results", In Proceedings of the 706 Second International Workshop on Quality of Service in 707 Multiservice IP Networks (QoS-IP 2003), Lecture Notes in 708 Computer Science, vol 2601. Springer, Berlin, 709 Heidelberg Pages 131-144, February 2003, 710 . 712 [draft-bless-diffserv-lbe-phb-00] 713 Bless, R. and K. Wehrle, "A Lower Than Best-Effort Per-Hop 714 Behavior", draft-bless-diffserv-lbe-phb-00 (work in 715 progress), September 1999, . 718 [I-D.ietf-tsvwg-rtcweb-qos] 719 Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP 720 Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb- 721 qos-18 (work in progress), August 2016. 723 [ietf99-secchi] 724 Secchi, R., Venne, A., and A. Custura, "Measurements 725 concerning the DSCP for a LE PHB", Presentation held at 726 99th IETF Meeting, TSVWG, Prague , July 2017, 727 . 731 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 732 RFC 2914, DOI 10.17487/RFC2914, September 2000, 733 . 735 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 736 of Explicit Congestion Notification (ECN) to IP", 737 RFC 3168, DOI 10.17487/RFC3168, September 2001, 738 . 740 [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural 741 Guidelines and Philosophy", RFC 3439, 742 DOI 10.17487/RFC3439, December 2002, 743 . 745 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 746 Per-Domain Behavior (PDB) for Differentiated Services", 747 RFC 3662, DOI 10.17487/RFC3662, December 2003, 748 . 750 [RFC3754] Bless, R. and K. Wehrle, "IP Multicast in Differentiated 751 Services (DS) Networks", RFC 3754, DOI 10.17487/RFC3754, 752 April 2004, . 754 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 755 Guidelines for DiffServ Service Classes", RFC 4594, 756 DOI 10.17487/RFC4594, August 2006, 757 . 759 [RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, 760 "Raptor Forward Error Correction Scheme for Object 761 Delivery", RFC 5053, DOI 10.17487/RFC5053, October 2007, 762 . 764 [RFC6297] Welzl, M. and D. Ros, "A Survey of Lower-than-Best-Effort 765 Transport Protocols", RFC 6297, DOI 10.17487/RFC6297, June 766 2011, . 768 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 769 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 770 DOI 10.17487/RFC6817, December 2012, 771 . 773 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 774 Morris, J., Hansen, M., and R. Smith, "Privacy 775 Considerations for Internet Protocols", RFC 6973, 776 DOI 10.17487/RFC6973, July 2013, 777 . 779 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 780 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 781 March 2017, . 783 [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using 784 Explicit Congestion Notification (ECN)", RFC 8087, 785 DOI 10.17487/RFC8087, March 2017, 786 . 788 [RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection 789 Classes and Practice", RFC 8100, DOI 10.17487/RFC8100, 790 March 2017, . 792 [RFC8325] Szigeti, T., Henry, J., and F. Baker, "Mapping Diffserv to 793 IEEE 802.11", RFC 8325, DOI 10.17487/RFC8325, February 794 2018, . 796 [RFC8436] Fairhurst, G., "Update to IANA Registration Procedures for 797 Pool 3 Values in the Differentiated Services Field 798 Codepoints (DSCP) Registry", RFC 8436, 799 DOI 10.17487/RFC8436, August 2018, 800 . 802 Appendix A. History of the LE PHB 804 A first version of this PHB was suggested by Roland Bless and Klaus 805 Wehrle in September 1999 [draft-bless-diffserv-lbe-phb-00], named "A 806 Lower Than Best-Effort Per-Hop Behavior". After some discussion in 807 the Diffserv Working Group Brian Carpenter and Kathie Nichols 808 proposed a "bulk handling" per-domain behavior and believed a PHB was 809 not necessary. Eventually, "Lower Effort" was specified as per- 810 domain behavior and finally became [RFC3662]. More detailed 811 information about its history can be found in Section 10 of 812 [RFC3662]. 814 There are several other names in use for this type of PHB or 815 associated service classes. Well-known is the QBone Scavenger 816 Service (QBSS) that was proposed in March 2001 within the Internet2 817 QoS Working Group. Alternative names are "Lower-than-best-effort" 818 [carlberg-lbe-2001] or "Less-than-best-effort" [chown-lbe-2003]. 820 Appendix B. Acknowledgments 822 Since text is partially borrowed from earlier Internet-Drafts and 823 RFCs the co-authors of previous specifications are acknowledged here: 824 Kathie Nichols and Klaus Wehrle. David Black, Olivier Bonaventure, 825 Spencer Dawkins, Toerless Eckert, Gorry Fairhurst, Ruediger Geib, and 826 Kyle Rose provided helpful comments and (partially also text) 827 suggestions. 829 Appendix C. Change History 831 This section briefly lists changes between Internet-Draft versions 832 for convenience. 834 Changes in Version 10: (incorporated comments from IESG discussion as 835 follows) 837 o Appended "for Differentiated Services" to the title as suggested 838 by Alexey. 840 o Addressed Deborah Brungard's discuss: changed phrase to "However, 841 non-LE traffic (e.g., BE traffic) SHOULD NOT be remarked to LE." 842 with additional explanation as suggested by Gorry. 844 o Fixed the sentence "An LE PHB SHOULD NOT be used for a customer's 845 "normal Internet" traffic nor should packets be "downgraded" to 846 the LE PHB instead of being dropped, particularly when the packets 847 are unauthorized traffic." according to Alice's and Mirja's 848 comments. 850 o Made reference to RFC8174 normative. 852 o Added hint for the RFC editor to apply changes from section 853 Section 12 and to delete it afterwards. 855 o Incorporated Mirja's and Benjamin's suggestions. 857 o Editorial suggested by Gorry: In case => In the case that 859 Changes in Version 09: 861 o Incorporated comments from IETF Last Call: 863 * from Olivier Bonaventure: added a bit of text for session 864 resumption and congestion control aspects as well as ECN usage. 866 * from Kyle Rose: Revised privacy considerations text in Security 867 Considerations Section 869 Changes in Version 08: 871 o revised two sentences as suggested by Spencer Dawkins 873 Changes in Version 07: 875 o revised some text for clarification according to comments from 876 Spencer Dawkins 878 Changes in Version 06: 880 o added Multicast Considerations section with input from Toerless 881 Eckert 883 o incorporated suggestions by David Black with respect to better 884 reflect legacy CS1 handling 886 Changes in Version 05: 888 o added scavenger service class into abstract 890 o added some more history 892 o added reference for "Myth of Over-Provisioning" in RFC3439 and 893 references to presentations w.r.t. codepoint choices 895 o added text to update draft-ietf-tsvwg-rtcweb-qos 897 o revised text on congestion control in case of remarking to BE 899 o added reference to DSCP measurement talk @IETF99 901 o small typo fixes 902 Changes in Version 04: 904 o Several editorial changes according to review from Gorry Fairhurst 906 o Changed the section structure a bit (moved subsections 1.1 and 1.2 907 into own sections 3 and 7 respectively) 909 o updated section 2 on requirements language 911 o added updates to RFC 8325 913 o tried to be more explicit what changes are required to RFCs 4594 914 and 8325 916 Changes in Version 03: 918 o Changed recommended codepoint to 000001 920 o Added text to explain the reasons for the DSCP choice 922 o Removed LE-min,LE-strict discussion 924 o Added one more potential use case: reporting errors or telemetry 925 data from OSs 927 o Added privacy considerations to the security section (not worth an 928 own section I think) 930 o Changed IANA considerations section 932 Changes in Version 02: 934 o Applied many editorial suggestions from David Black 936 o Added Multicast traffic use case 938 o Clarified what is required for deployment in section 1.2 939 (Deployment Considerations) 941 o Added text about implementations using AQMs and ECN usage 943 o Updated IANA section according to David Black's suggestions 945 o Revised text in the security section 947 o Changed copyright Notice to pre5378Trust200902 949 Changes in Version 01: 951 o Now obsoletes RFC 3662. 953 o Tried to be more precise in section 1.1 (Applicability) according 954 to R. Geib's suggestions, so rephrased several paragraphs. Added 955 text about congestion control 957 o Change section 2 (PHB Description) according to R. Geib's 958 suggestions. 960 o Added RFC 2119 language to several sentences. 962 o Detailed the description of remarking implications and 963 recommendations in Section 8. 965 o Added Section 10 to explicitly list changes with respect to RFC 966 4594, because this document will update it. 968 Appendix D. Note to RFC Editor 970 This section lists actions for the RFC editor during final 971 formatting. 973 o Apply the suggested changes of section Section 12 and add a 974 normative reference in draft-ietf-tsvwg-rtcweb-qos to this RFC. 976 o Delete Section 12. 978 o Please replace the occurrences of RFCXXXX in Section 10 and 979 Section 11 with the assigned RFC number for this document. 981 o Delete Appendix C. 983 o Delete this section. 985 Author's Address 987 Roland Bless 988 Karlsruhe Institute of Technology (KIT) 989 Kaiserstr. 12 990 Karlsruhe 76131 991 Germany 993 Phone: +49 721 608 46413 994 Email: roland.bless@kit.edu