idnits 2.17.1 draft-ietf-tsvwg-le-phb-00.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 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 (Using the creation date from RFC3662, updated by this document, for RFC5378 checks: 2002-06-27) -- 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 (November 14, 2016) is 2712 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 (~~), 1 warning (==), 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 Updates: 3662,4594 (if approved) November 14, 2016 5 Intended status: Standards Track 6 Expires: May 18, 2017 8 A Lower Effort Per-Hop Behavior (LE PHB) 9 draft-ietf-tsvwg-le-phb-00 11 Abstract 13 This document specifies properties and characteristics of a Lower 14 Effort (LE) per-hop behavior (PHB). The primary objective of this LE 15 PHB is to protect best-effort (BE) traffic (packets forwarded with 16 the default PHB) from LE traffic in congestion situations, i.e., when 17 resources become scarce, best-effort traffic has precedence over LE 18 traffic and may preempt it. There are numerous uses for this PHB, 19 e.g., for background traffic of low precedence, such as bulk data 20 transfers with low priority in time, non time-critical backups, 21 larger software updates, web search engines while gathering 22 information from web servers and so on. This document recommends a 23 standard DSCP value for the LE PHB. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 18, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Deployment Considerations . . . . . . . . . . . . . . . . 4 62 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 63 2. PHB Description . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Traffic Conditioning Actions . . . . . . . . . . . . . . . . 5 65 4. Recommended DS Codepoint . . . . . . . . . . . . . . . . . . 5 66 5. Remarking to other DSCPs/PHBs . . . . . . . . . . . . . . . . 5 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 71 8.2. Informative References . . . . . . . . . . . . . . . . . 6 72 Appendix A. History of the LE PHB . . . . . . . . . . . . . . . 7 73 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 7 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 76 1. Introduction 78 This document defines a Differentiated Services per-hop behavior 79 RFC 2474 [RFC2474] called "Lower Effort" (LE) which is intended for 80 traffic of sufficiently low urgency, in which all other traffic takes 81 precedence over LE traffic in consumption of network link bandwidth. 82 Low urgency traffic has got a low priority in time, which does not 83 necessarily imply that it is generally of minor importance. From 84 this viewpoint, it can be considered as a network equivalent to a 85 background priority for processes in an operating system. There may 86 or may not be memory (buffer) resources allocated for this type of 87 traffic. 89 Some networks carry traffic for which delivery is considered 90 optional; that is, packets of this type of traffic ought to consume 91 network resources only when no other traffic is present. 92 Alternatively, the effect of this type of traffic on all other 93 network traffic is strictly limited. This is distinct from "best- 94 effort" (BE) traffic since the network makes no commitment to deliver 95 LE packets. In contrast, BE traffic receives an implied "good faith" 96 commitment of at least some available network resources. This 97 document proposes a Lower Effort Differentiated Services per-hop 98 behavior (LE PHB) for handling this "optional" traffic in a 99 differentiated services node. 101 1.1. Applicability 103 A Lower Effort PHB is for sending extremely non-critical traffic 104 across a Differentiated Services (DS) domain or DS region. There 105 should be an expectation that packets of the LE PHB may be delayed or 106 dropped when any other traffic is present. Use of the LE PHB might 107 assist a network operator in moving certain kinds of traffic or users 108 to off-peak times. Alternatively, or in addition, packets can be 109 designated for the LE PHB when the goal is to protect all other 110 packet traffic from competition with the LE aggregate while not 111 completely banning LE traffic from the network. An LE PHB should not 112 be used for a customer's "normal internet" traffic nor should packets 113 be "downgraded" to the LE PHB used as a substitute for dropping 114 packets that ought simply to be dropped as unauthorized. The LE PHB 115 is expected to have applicability in networks that have at least some 116 unused capacity at some times of day. 118 This is a PHB that allows networks to protect themselves from 119 selected types of traffic rather than giving a selected traffic 120 aggregate preferential treatment. Moreover, it may also exploit all 121 unused resources from other PHBs. 123 There is no intrinsic reason to limit the applicability of the LE PHB 124 to any particular application or type of traffic. It is intended as 125 an additional tool for administrators in engineering networks. For 126 instance, it can be used for filling up protection capacity of 127 transmission links which is otherwise unused. Some network providers 128 keep link utilization below 50% in order to being able carrying all 129 traffic without loss in case of rerouting due to a link failure. LE 130 marked traffic can utilize the normally unused capacity and will be 131 preempted automatically in case of link failure when 100% of the link 132 capacity is required for all other traffic. Ideally, applications 133 mark their packets as LE traffic, since they know the urgency of 134 flows. 136 Example uses for the LE PHB comprise: 138 o For traffic caused by world-wide web search engines while they 139 gather information from web servers. 141 o For software updates or dissemination of new releases of operating 142 systems. 144 o For backup traffic or non-time critical sychronization or 145 mirroring traffic. 147 o For content distribution transfers between caches. 149 o For Netnews and other "bulk mail" of the Internet. 151 o For "downgraded" traffic from some other PHB when this does not 152 violate the operational objectives of the other PHB or the overall 153 network. LE should not be used for the general case of downgraded 154 traffic, but may be used by design, e.g., to protect an internal 155 network from untrusted external traffic sources. In this case 156 there is no way for attackers to preempt internal (non LE) traffic 157 by flooding. Another use case is mentioned in [RFC3754]: non- 158 admitted multicast traffic. 160 1.2. Deployment Considerations 162 Internet-wide deployment of the LE PHB is eased by the following 163 properties: 165 o No harm to other traffic: since the LE PHB has got the lowest 166 priority it does not take resources from other PHBs. Deployment 167 across different provider domains causes no trust issues or attack 168 vectors to existing traffic. 170 o No parameters or configuration: the LE PHB requires no parameters 171 and no configuration of traffic profiles and so on. 173 o No traffic conditioning mechanisms: the LE PHB requires only a 174 queue and a scheduling mechanism, but no traffic meters, droppers 175 or shapers. 177 Since LE traffic may be starved completely for a longer period of 178 time, transport protocols or applications should be able to detect 179 such a situation and should resume the transfer as soon as possible. 181 1.3. Requirements Language 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in RFC 2119 [RFC2119]. 187 2. PHB Description 189 This PHB is defined in relation to the default PHB (best-effort). A 190 packet forwarded with this PHB SHOULD have lower precedence than 191 packets forwarded with the default PHB. Ideally, LE packets should 192 be forwarded only if no best-effort packet is waiting for its 193 transmission. A straightforward implementation could be a simple 194 priority scheduler serving the default PHB queue with higher priority 195 than the lower-effort PHB queue. Alternative implementations may use 196 scheduling algorithms that assign a very small weight to the LE 197 class. This, however, may sometimes cause better service for LE 198 packets compared to BE packets in cases when the BE share is fully 199 utilized and the LE share not. 201 3. Traffic Conditioning Actions 203 As for most other PHBs an initial classification and marking would 204 usually be performed at the first DS boundary node. In many cases, 205 packets may also be pre-marked in DS aware end systems by 206 applications due to their specific knowledge about the particular 207 precedence of packets. There is no incentive for DS domains to 208 distrust this initial marking, because letting LE traffic enter a DS 209 domain causes no harm. In the worst case it evokes the same effect 210 as it would have been marked with the default PHB, i.e., as best- 211 effort traffic. Thus, any policing such as limiting the traffic rate 212 is not necessary at the DS boundary. 214 Usually, the amount of LE traffic is implicitly limited by queueing 215 mechanisms and related discard actions of the PHB. Therefore, there 216 is normally no need to meter and police LE traffic explicitly. 218 4. Recommended DS Codepoint 220 The recommended codepoint for the LE PHB is 000010. 222 RFC 4594 [RFC4594] recommended to use CS1 as codepoint (as mentioned 223 in [RFC3662]. This is problematic since it may cause a priority 224 inversion resulting in treating LE packets with higher precedence 225 than BE packets. Existing implementations SHOULD therefore use the 226 unambiguous LE codepoint 000010 whenever possible. 228 5. Remarking to other DSCPs/PHBs 230 "DSCP bleaching", i.e., setting the DSCP to 000000 (default PHB) is 231 not recommended for this PHB. This may cause effects that are in 232 contrast to the original intent in protecting BE traffic from LE 233 traffic. In case DS domains do not support the LE PHB, they may 234 treat LE marked packets with the default PHB instead, but they should 235 do so without remarking to the DSCP 000000. The reason for this is 236 that later traversed DS domains may then have still the possibility 237 to treat such packets according the LE PHB. 239 6. IANA Considerations 241 This memo includes a request to assign a Differentiated Services 242 Field Codepoint (DSCP) 000010 from the Differentiated Services Field 243 Codepoints (DSCP) registry https://www.iana.org/assignments/dscp- 244 registry/dscp-registry.xml 246 7. Security Considerations 248 There are no specific security exposures for this PHB. Since it 249 defines a new class of low forwarding priority, other traffic may be 250 downgraded to this LE PHB in case it is remarked as LE traffic. See 251 the general security considerations in RFC 2474 [RFC2474] and RFC 252 2475 [RFC2475]. 254 8. References 256 8.1. Normative References 258 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 259 Requirement Levels", BCP 14, RFC 2119, 260 DOI 10.17487/RFC2119, March 1997, 261 . 263 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 264 "Definition of the Differentiated Services Field (DS 265 Field) in the IPv4 and IPv6 Headers", RFC 2474, 266 DOI 10.17487/RFC2474, December 1998, 267 . 269 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 270 and W. Weiss, "An Architecture for Differentiated 271 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 272 . 274 8.2. Informative References 276 [draft-bless-diffserv-lbe-phb-00] 277 Bless, R. and K. Wehrle, "A Lower Than Best-Effort Per-Hop 278 Behavior", draft-bless-diffserv-lbe-phb-00 (work in 279 progress), September 1999, . 282 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 283 Per-Domain Behavior (PDB) for Differentiated Services", 284 RFC 3662, DOI 10.17487/RFC3662, December 2003, 285 . 287 [RFC3754] Bless, R. and K. Wehrle, "IP Multicast in Differentiated 288 Services (DS) Networks", RFC 3754, DOI 10.17487/RFC3754, 289 April 2004, . 291 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 292 Guidelines for DiffServ Service Classes", RFC 4594, 293 DOI 10.17487/RFC4594, August 2006, 294 . 296 Appendix A. History of the LE PHB 298 A first version of this PHB was suggested by Roland Bless and Klaus 299 Wehrle in 1999 [draft-bless-diffserv-lbe-phb-00]. After some 300 discussion in the DiffServ Working Group Brian Carpenter and Kathie 301 Nichols proposed a bulk handling per-domain behavior and believed a 302 PHB was not necessary. Eventually, Lower Effort was specified as 303 per-domain behavior and finally became [RFC3662]. More detailed 304 information about its history can be found in Section 10 of 305 [RFC3662]. 307 Appendix B. Acknowledgments 309 Since text is borrowed from earlier Internet-Drafts and RFCs the co- 310 authors of previous specifications are acknowledged here: Kathie 311 Nichols and Klaus Wehrle. 313 Author's Address 315 Roland Bless 316 Karlsruhe Institute of Technology (KIT) 317 Kaiserstr. 12 318 Karlsruhe 76131 319 Germany 321 Phone: +49 721 608 46413 322 Email: roland.bless@kit.edu