idnits 2.17.1 draft-ietf-tsvwg-le-phb-01.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 obsoletes RFC3662, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4594, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Non-LE traffic (e.g., BE traffic) SHOULD not be remarked to LE on a regular basis without consent or knowledge of the user. (Using the creation date from RFC4594, updated by this document, for RFC5378 checks: 2005-02-14) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 6, 2017) is 2635 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) ** 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) February 6, 2017 5 Updates: 4594 (if approved) 6 Intended status: Standards Track 7 Expires: August 10, 2017 9 A Lower Effort Per-Hop Behavior (LE PHB) 10 draft-ietf-tsvwg-le-phb-01 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. There are numerous uses for this PHB, 20 e.g., for background traffic of low precedence, such as bulk data 21 transfers with low priority in time, non time-critical backups, 22 larger software updates, web search engines while gathering 23 information from web servers and so on. This document recommends a 24 standard DSCP value for the LE PHB. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 10, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 62 1.2. Deployment Considerations . . . . . . . . . . . . . . . . 4 63 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 64 2. PHB Description . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Traffic Conditioning Actions . . . . . . . . . . . . . . . . 5 66 4. Recommended DS Codepoint . . . . . . . . . . . . . . . . . . 6 67 5. Remarking to other DSCPs/PHBs . . . . . . . . . . . . . . . . 6 68 6. Changes to RFC 4594 . . . . . . . . . . . . . . . . . . . . . 7 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 9.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Appendix A. History of the LE PHB . . . . . . . . . . . . . . . 9 75 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 9 76 Appendix C. Change History . . . . . . . . . . . . . . . . . . . 10 77 Appendix D. Note to RFC Editor . . . . . . . . . . . . . . . . . 10 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 This document defines a Differentiated Services per-hop behavior 83 [RFC2474] called "Lower Effort" (LE) which is intended for traffic of 84 sufficiently low urgency, in which all other traffic takes precedence 85 over LE traffic in consumption of network link bandwidth. Low 86 urgency traffic has got a low priority in time, which does not 87 necessarily imply that it is generally of minor importance. From 88 this viewpoint, it can be considered as a network equivalent to a 89 background priority for processes in an operating system. There may 90 or may not be memory (buffer) resources allocated for this type of 91 traffic. 93 Some networks carry traffic for which delivery is considered 94 optional; that is, packets of this type of traffic ought to consume 95 network resources only when no other traffic is present. 97 Alternatively, the effect of this type of traffic on all other 98 network traffic is strictly limited. This is distinct from "best- 99 effort" (BE) traffic since the network makes no commitment to deliver 100 LE packets. In contrast, BE traffic receives an implied "good faith" 101 commitment of at least some available network resources. This 102 document proposes a Lower Effort Differentiated Services per-hop 103 behavior (LE PHB) for handling this "optional" traffic in a 104 differentiated services node. 106 1.1. Applicability 108 A Lower Effort PHB is applicable for most elastic applications that 109 otherwise use best-effort delivery. More specifically, it is 110 suitable for traffic and services accepting strongly varying 111 throughput for their data flows, especially with respect to periods 112 of very low throughput or even starvation (i.e., long interruptions 113 due to excessive packet loss). Therefore, an application sending an 114 LE marked flow must be able to tolerate short or (even very) long 115 interruptions due to the presence of severe congestion conditions 116 during the transmission of the flow. Thus, there should be an 117 expectation that packets of the LE PHB may be excessively delayed or 118 dropped when any other traffic is present. The LE PHB is suitable 119 for sending traffic of low urgency across a Differentiated Services 120 (DS) domain or DS region. 122 LE traffic SHOULD be congestion controlled. Since LE traffic may be 123 starved completely for a longer period of time, transport protocols 124 or applications (and their related congestion control mechanisms) 125 SHOULD be able to detect and react to such a situation and should 126 resume the transfer as soon as possible. Congestion control is not 127 only useful to let the flows within the LE behavior aggregate adapt 128 to the available bandwidth that may be highly fluctuating, but also 129 in case that LE traffic is mapped to the default PHB (e.g., due to 130 DSCP bleaching). 132 Use of the LE PHB might assist a network operator in moving certain 133 kinds of traffic or users to off-peak times. Alternatively, or in 134 addition, packets can be designated for the LE PHB when the goal is 135 to protect all other packet traffic from competition with the LE 136 aggregate while not completely banning LE traffic from the network. 137 An LE PHB should not be used for a customer's "normal internet" 138 traffic nor should packets be "downgraded" to the LE PHB used as a 139 substitute for dropping packets that ought simply to be dropped as 140 unauthorized. The LE PHB is expected to have applicability in 141 networks that have at least some unused capacity at some times of 142 day. 144 The LE PHB allows networks to protect themselves from selected types 145 of traffic rather than giving a selected traffic aggregate 146 preferential treatment. Moreover, the LE PHB may also exploit all 147 unused resources from other PHBs. 149 There is no intrinsic reason to limit the applicability of the LE PHB 150 to any particular application or type of traffic. It is intended as 151 an additional tool for administrators in engineering networks. For 152 instance, it can be used for filling up protection capacity of 153 transmission links which is otherwise unused. Some network providers 154 keep link utilization below 50% in order to being able carrying all 155 traffic without loss in case of rerouting due to a link failure. LE 156 marked traffic can utilize the normally unused capacity and will be 157 preempted automatically in case of link failure when 100% of the link 158 capacity is required for all other traffic. Ideally, applications 159 mark their packets as LE traffic, since they know the urgency of 160 flows. 162 Example uses for the LE PHB comprise: 164 o For traffic caused by world-wide web search engines while they 165 gather information from web servers. 167 o For software updates or dissemination of new releases of operating 168 systems. 170 o For backup traffic or non-time critical synchronization or 171 mirroring traffic. 173 o For content distribution transfers between caches. 175 o For Netnews and other "bulk mail" of the Internet. 177 o For "downgraded" traffic from some other PHB when this does not 178 violate the operational objectives of the other PHB or the overall 179 network. LE should not be used for the general case of downgraded 180 traffic, but may be used by design, e.g., to protect an internal 181 network from untrusted external traffic sources. In this case 182 there is no way for attackers to preempt internal (non LE) traffic 183 by flooding. Another use case is mentioned in [RFC3754]: non- 184 admitted multicast traffic. 186 1.2. Deployment Considerations 188 Internet-wide deployment of the LE PHB is eased by the following 189 properties: 191 o No harm to other traffic: since the LE PHB has got the lowest 192 forwarding priority it does not consume resources from other PHBs. 193 Deployment across different provider domains causes no trust 194 issues or attack vectors to existing traffic. 196 o No parameters or configuration: the LE PHB requires no parameters 197 and no configuration of traffic profiles and so on. 199 o No traffic conditioning mechanisms: the LE PHB requires no traffic 200 meters, droppers, or shapers. 202 DS domains that cannot or do not want to support the LE PHB SHOULD 203 NOT drop LE marked packets, but rather map them to the default PHB 204 and keep the LE DSCP. See also Section 5 for further discussion of 205 forwarding LE traffic with the default PHB instead. 207 1.3. Requirements Language 209 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 210 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 211 document are to be interpreted as described in [RFC2119]. 213 2. PHB Description 215 The LE PHB is defined in relation to the default PHB (best-effort). 216 A packet forwarded with the LE PHB SHOULD have lower precedence than 217 packets forwarded with the default PHB, i.e., in case of congestion, 218 LE marked traffic SHOULD be dropped prior to dropping any default PHB 219 traffic. Ideally, LE packets SHOULD be forwarded only if no best- 220 effort packet is waiting for its transmission. 222 A straightforward implementation could be a simple priority scheduler 223 serving the default PHB queue with higher priority than the lower- 224 effort PHB queue. Alternative implementations may use scheduling 225 algorithms that assign a very small weight to the LE class. This, 226 however, may sometimes cause better service for LE packets compared 227 to BE packets in cases when the BE share is fully utilized and the LE 228 share not. 230 3. Traffic Conditioning Actions 232 As for most other PHBs an initial classification and marking would 233 usually be performed at the first DS boundary node. If possible, 234 packets SHOULD be pre-marked in DS-aware end systems by applications 235 due to their specific knowledge about the particular precedence of 236 packets. There is no incentive for DS domains to distrust this 237 initial marking, because letting LE traffic enter a DS domain causes 238 no harm. In the worst case it evokes the same effect as it would 239 have been marked with the default PHB, i.e., as best-effort traffic. 240 Usually, the amount of LE traffic is implicitly limited by queueing 241 mechanisms and related discard actions of the PHB. Thus, any 242 policing such as limiting the rate of LE traffic is not necessary at 243 the DS boundary. 245 Non-LE traffic (e.g., BE traffic) SHOULD not be remarked to LE on a 246 regular basis without consent or knowledge of the user. 248 4. Recommended DS Codepoint 250 The RECOMMENDED codepoint for the LE PHB is '000010'. 252 Earlier specifications [RFC4594] recommended to use CS1 as codepoint 253 (as mentioned in [RFC3662]). This is problematic since it may cause 254 a priority inversion in DiffServ domains that treat CS1 as originally 255 proposed in [RFC2474], resulting in forwarding LE packets with higher 256 precedence than BE packets. Existing implementations SHOULD 257 therefore use the unambiguous LE codepoint '000010' whenever 258 possible. 260 5. Remarking to other DSCPs/PHBs 262 "DSCP bleaching", i.e., setting the DSCP to '000000' (default PHB) is 263 NOT RECOMMENDED for this PHB. This may cause effects that are in 264 contrast to the original intent in protecting BE traffic from LE 265 traffic. In case DS domains do not support the LE PHB, they SHOULD 266 treat LE marked packets with the default PHB instead (by mapping the 267 LE DSCP to the default PHB), but they SHOULD do so without remarking 268 to DSCP '000000'. The reason for this is that later traversed DS 269 domains may then have still the possibility to treat such packets 270 according the LE PHB. However, operators of DS domains that forward 271 LE traffic within the BE aggregate should be aware of the 272 implications, i.e., induced congestion situations and quality-of- 273 service degradation of the original BE traffic. In this case, the LE 274 property of not harming other traffic is no longer fulfilled. In 275 order to limit the impact in such cases, traffic policing of the LE 276 aggregate may be used. 278 In case LE marked packets are effectively carried within the default 279 PHB (i.e., forwarded as best-effort traffic) they get a better 280 forwarding treatment than expected. For some applications and 281 services, it is favorable if the transmission is finished earlier 282 than expected. However, in some cases it may be against the original 283 intention of the LE PHB user to strictly send the traffic only if 284 otherwise unused resources are available, i.e., LE traffic may 285 compete with BE traffic for the same resources and thus adversely 286 affect the original BE aggregate. One possible solution for a clear 287 distinction in such cases would be to use two different codepoints, 288 "LE-min = LE, better treatment allowed", "LE-strict = LE, better 289 treatment NOT allowed". However, since DSCPs are a scarce resource, 290 applications that want to ensure the lower precedence compared to BE 291 traffic SHOULD use additionally a corresponding Lower-than-Best- 292 Effort transport protocol [RFC6297], e.g., LEDBAT [RFC6817]. 294 A DS domain that still uses DSCP CS1 for marking LE traffic 295 (including Low Priority-Data as defined in [RFC4594] or the old 296 definition in [RFC3662]) MUST remark traffic to the LE DSCP '000010' 297 at the egress to the next DS domain. This increases the probability 298 that the DSCP is preserved end-to-end, whereas a CS1 marked packet 299 may be remarked by the default DSCP if the next domain is applying 300 DiffServ-intercon [I-D.ietf-tsvwg-diffserv-intercon]. 302 6. Changes to RFC 4594 304 [RFC4594] recommended to use CS1 as codepoint in section 4.10, 305 whereas CS1 was defined in [RFC2474] to have a higher precedence than 306 CS0, i.e., the default PHB. Consequently, DiffServ domains 307 implementing CS1 according to [RFC2474] will cause a priority 308 inversion for LE packets that contradicts with the original purpose 309 of LE. Therefore, every occurrence of the CS1 DSCP is replaced by 310 the LE DSCP. 312 Changes: 314 o The Low-Priority Data row in Figure 3 is updated as follows: 316 |---------------+---------+-------------+--------------------------| 317 | Low-Priority | LE | 000010 | Any flow that has no BW | 318 | Data | | | assurance | 319 ------------------------------------------------------------------ 321 o The Low-Priority Data row in Figure 4 is updated as follows: 323 |---------------+------+-------------------+---------+--------+----| 324 | Low-Priority | LE | Not applicable | RFCXXXX | Rate | Yes| 325 | Data | | | | | | 326 ------------------------------------------------------------------ 328 o Section 4.10: The RECOMMENDED DSCP marking is LE (Lower Effort). 330 o [RFC4594] recommended to remark Low-Priority Data to DSCP '000001' 331 inside a DS domain that uses IP precedence marking. By using the 332 herein defined LE DSCP such remarking is not necessary, so even if 333 Low-Priority Data is unsupported (i.e., mapped to the default PHB) 334 the LE DSCP should be kept across the domain as RECOMMENDED in 335 Section 5. 337 7. IANA Considerations 339 This memo includes a request to assign a Differentiated Services 340 Field Codepoint (DSCP) '000010' from the Differentiated Services 341 Field Codepoints (DSCP) registry https://www.iana.org/assignments/ 342 dscp-registry/dscp-registry.xml 344 8. Security Considerations 346 There are no specific security exposures for this PHB. Since it 347 defines a new class of low forwarding priority, other traffic may be 348 downgraded to this LE PHB in case it is remarked as LE traffic. See 349 the general security considerations in [RFC2474] and [RFC2475]. 351 9. References 353 9.1. Normative References 355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 356 Requirement Levels", BCP 14, RFC 2119, 357 DOI 10.17487/RFC2119, March 1997, 358 . 360 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 361 "Definition of the Differentiated Services Field (DS 362 Field) in the IPv4 and IPv6 Headers", RFC 2474, 363 DOI 10.17487/RFC2474, December 1998, 364 . 366 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 367 and W. Weiss, "An Architecture for Differentiated 368 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 369 . 371 9.2. Informative References 373 [draft-bless-diffserv-lbe-phb-00] 374 Bless, R. and K. Wehrle, "A Lower Than Best-Effort Per-Hop 375 Behavior", draft-bless-diffserv-lbe-phb-00 (work in 376 progress), September 1999, . 379 [I-D.ietf-tsvwg-diffserv-intercon] 380 Geib, R. and D. Black, "Diffserv-Interconnection classes 381 and practice", draft-ietf-tsvwg-diffserv-intercon-14 (work 382 in progress), December 2016. 384 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 385 Per-Domain Behavior (PDB) for Differentiated Services", 386 RFC 3662, DOI 10.17487/RFC3662, December 2003, 387 . 389 [RFC3754] Bless, R. and K. Wehrle, "IP Multicast in Differentiated 390 Services (DS) Networks", RFC 3754, DOI 10.17487/RFC3754, 391 April 2004, . 393 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 394 Guidelines for DiffServ Service Classes", RFC 4594, 395 DOI 10.17487/RFC4594, August 2006, 396 . 398 [RFC6297] Welzl, M. and D. Ros, "A Survey of Lower-than-Best-Effort 399 Transport Protocols", RFC 6297, DOI 10.17487/RFC6297, June 400 2011, . 402 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 403 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 404 DOI 10.17487/RFC6817, December 2012, 405 . 407 Appendix A. History of the LE PHB 409 A first version of this PHB was suggested by Roland Bless and Klaus 410 Wehrle in 1999 [draft-bless-diffserv-lbe-phb-00]. After some 411 discussion in the DiffServ Working Group Brian Carpenter and Kathie 412 Nichols proposed a bulk handling per-domain behavior and believed a 413 PHB was not necessary. Eventually, Lower Effort was specified as 414 per-domain behavior and finally became [RFC3662]. More detailed 415 information about its history can be found in Section 10 of 416 [RFC3662]. 418 Appendix B. Acknowledgments 420 Since text is borrowed from earlier Internet-Drafts and RFCs the co- 421 authors of previous specifications are acknowledged here: Kathie 422 Nichols and Klaus Wehrle. Ruediger Geib provided helpful comments 423 and suggestions. 425 Appendix C. Change History 427 This section briefly lists changes between Internet-Draft versions 428 for convenience. 430 Changes in Version 01: 432 o Now obsoletes RFC 3662. 434 o Tried to be more precise in section 1.1 (Applicability) according 435 to R. Geib's suggestions, so rephrased several paragraphs. Added 436 text about congestion control 438 o Change section 2 (PHB Description) according to R. Geib's 439 suggestions. 441 o Added RFC 2119 language to several sentences. 443 o Detailed the description of remarking implications and 444 recommendations in Section 5. 446 o Added Section 6 to explicitly list changes with respect to RFC 447 4594, because this document will update it. 449 Appendix D. Note to RFC Editor 451 This section lists actions for the RFC editor during final 452 formatting. 454 o Please replace the occurrence of RFCXXXX in Section 6 with the 455 assigned RFC number for this document. 457 o Delete Appendix C. 459 o Delete this section. 461 Author's Address 463 Roland Bless 464 Karlsruhe Institute of Technology (KIT) 465 Kaiserstr. 12 466 Karlsruhe 76131 467 Germany 469 Phone: +49 721 608 46413 470 Email: roland.bless@kit.edu