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