idnits 2.17.1 draft-bless-diffserv-lbe-phb-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 9) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (September 1999) is 8988 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 (ref. '3') -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Bless 2 Expires: March 2000 K. Wehrle 3 Universitaet Karlsruhe (TH) 4 September 1999 6 A Lower Than Best-Effort Per-Hop Behavior 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet 16 Engineering Task Force (IETF), its areas, and its working 17 groups. Note that other groups may also distribute working 18 documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use 23 Internet-Drafts as reference material or to cite them other 24 than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed 30 at http://www.ietf.org/shadow.html. 32 Abstract 34 This document describes a Lower than Best-Effort (LBE) per-hop 35 behavior (PHB) for use within and between Differentiated 36 Services domains [3]. The primary objective of this LBE PHB 37 is to separate LBE traffic from best-effort traffic in 38 congestion situations, i.e., when resources become scarce. 39 Furthermore, LBE traffic gets a minimal share of bandwidth so 40 that it will not be fully preempted by best-effort traffic. 41 This is achieved by discarding LBE packets more aggressively 42 than best-effort packets while trying to enqueue them in case 43 of congestion. 45 There are numerous uses for this PHB, e.g., for transmission 46 of background traffic such as bulk data transfers of minor 47 importance, backup data traffic during working hours or 48 traffic caused by web search engines while gathering 49 information from web servers. Thus, it constitutes the 50 network equivalent to a background priority for processes in 51 an operating system. Moreover, it is particularly useful in 52 cases when packets of a better service are re-marked by a node 53 for subsequently receiving a forwarding treatment that is 54 equivalent to the best-effort service. In this situation the 55 LBE PHB helps to protect other best-effort packets from 56 experiencing unfair forwarding treatment because it avoids 57 their preemption by re-marked packets. For instance, this 58 case occurs when heterogeneous multicast groups should be 59 supported. 61 1 Purpose and Overview 63 In some situations changing a per-hop forwarding behavior (PHB) of an 64 incoming packet is desired or required, so that the packet is 65 subsequently forwarded with the lowest available priority. Usually, 66 this forwarding behavior would be equivalent to the Default PHB 67 resulting in a best-effort service. But, simply re-marking the DS 68 codepoint (DSCP) to the DSCP value of the Default PHB will probably 69 result in some unfair share of this re-marked traffic relating to 70 best-effort traffic. This is due to the fact that nearly all packets 71 which previously experienced a better service enter the behavior 72 aggregate (BA) of the Default behavior. Consequently, other incoming 73 packets carrying a DSCP of the Default PHB will be preempted by those 74 re-marked packets if not enough resources are available for the combined 75 traffic. This unfairness against existing best-effort traffic should be 76 avoided. 78 The basic concept behind the proposed Lower-Than-Best-Effort per-hop 79 behavior (LBE PHB) is to discard those re-marked packets more 80 aggressively than packets belonging to the default PHB if resources 81 become scarce. Merely discarding those packets more drastically in the 82 re-marking node is not sufficient, because currently there may be enough 83 resources available in this node, but maybe not in subsequent downstream 84 nodes. Therefore, this re-marked traffic should be identifyable by a 85 separate codepoint. 87 For instance, a re-marking of packets is required when a receiver joins 88 a multicast group and does not want to or even is not able to receive 89 the currently used better service within this group (e.g., 1 Mbit/s 90 Premium service). Instead of this, the receiver wants to get the 91 traffic of this group without any quality of service guarantee, i.e., a 92 best-effort service. The node which connects the new subtree of this 93 receiver to the already existing multicast delivery tree must therefore 94 degrade the quality of service of the incoming packet stream for 95 replicated packets which are sent downstream on the output link of the 96 newly joined subtree (see Fig. 1). 98 Moreover, specific excess traffic of any kind may be marked with the LBE 99 codepoint. For example, this excess traffic could consist of packets 100 belonging to non-responsive flows (e.g., UDP flows). Thus, other 101 best-effort traffic (e.g., responsive TCP flows) is segregated from this 102 excess traffic, consequently not being adversely affected by it. 104 || Multicast Group Flow 105 || 1 Mbit/s Premium service 106 \/ 107 +---------+ 108 | || | 109 | || | 110 | // \*) | *) replicates are re-marked 111 +-//---\--+ with the LBE PHB 112 // \ 113 1 Mbit/s || | 114 Premium || | Lower than Best-Effort (LBE) service 115 service \/ V 116 . \ 117 . \ 118 // \\ . 119 // \\ . 120 . . +---+ 121 . . | R | New receiver wants no QoS 122 +---+ 124 Figure 1: A new receiver without QoS requirements joining a multicast 125 group that uses Premium service 127 As a further example, the LBE can be used as a separate service class 128 for background traffic (e.g., bulk transfers of low priority) that 129 should not impact the usual best-effort traffic. Examples for this kind 130 of background traffic are backup data traffic sent over the network 131 during normal working hours and traffic from web search engines 132 gathering data from web servers. Additionally, applications in DS aware 133 end-systems are able to pre-mark packets of minor importance, while 134 allowing to use the traditional inexpensive best-effort service for all 135 other more important packets. 137 The LBE PHB solves the above mentioned problems by discarding LBE 138 packets more rigorously than those of the best-effort BA in case of 139 resource contention for residual bandwidth, therefore limiting the 140 amount of packets in the LBE class in relation to the best-effort class. 141 This is described more detailed in sections 2.1 and 2.3. 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [4]. 147 2 Description of LBE per-hop behavior 149 A lower than best-effort service can be used in general to protect 150 traffic in the best-effort service class from unfairness that would 151 otherwise have been caused by those packets which are now in the LBE. 152 The latter packets may stem from excess traffic or re-marked traffic 153 that has been experiencing a better service before. Therefore, in order 154 to restrict the impact of those packets on packets in the Default PHB 155 BA, the LBE PHB provides forwarding of IP packets with a higher drop 156 precedence than Default PHB packets. 158 It is not necessary to have an LBE PHB group comprising more than one 159 PHB, because within its BA, LBE PHB essentially resembles best-effort 160 behavior that does not distinguish different types of traffic (e.g., 161 responsive and non-responsive flows), too. 163 The Lower than Best-Effort per-hop behavior is intended for general use. 164 There may be many cases in which the LBE PHB can be applied. Three of 165 them were already mentioned in section 1. 167 Using this PHB between two adjacent service providers is also useful, 168 because the upstream domain possibly had enough resources left to carry 169 the additional LBE traffic volume, whereas the downstream domain has not 170 enough resources, therefore being in need of discarding some portion of 171 this traffic. 173 2.1 Interaction with Other PHB Groups 175 The LBE PHB is essentially defined by its relation to the default PHB: 176 an LBE packet is of minor relative importance compared to a best-effort 177 packet. Thus, in case of contention for bandwidth (i.e., a congestion 178 situation), packets receiving best-effort treatment preempt packets of 179 the LBE behavior aggregate down to a certain share. This share must be 180 considerably lower than that of the best-effort BA, but should not be 181 equal to zero in order to retain a low portion of LBE traffic even when 182 best-effort traffic takes up all available residual bandwidth. 183 Therefore, a minimum configured bandwidth share for LBE traffic exists 184 as a lower bound that guarantees transport of LBE packets even in case 185 of congestion. On the other hand, this bound also constitutes an upper 186 limit for the share of LBE traffic during congestion. This upper bound 187 may be static, that is, fixed in relation to the overall available 188 bandwidth on a particular link (a constant value for 100-Y in Fig. 2), 189 or it may be dynamic, i.e., fixed relative to the BE traffic share, thus 190 variable in relation to the overall available bandwidth, because BE 191 traffic may consume resources currently not used by other BAs (a dynamic 192 value for Y that depends on the amount of BE traffic; corresponding to a 193 constant ratio of (100-Y)/(100-X) in Fig. 2). 195 0% X% Y% 100% 196 +----------------------------------------------------------------+ 197 | Other BAs | Best-Effort | LBE | 198 +----------------------------------------------------------------+ 199 |<-Upper->| 200 | Bound | 202 Figure 2: Bandwidth share limits for LBE traffic. Other behavior 203 aggregates (BA) currently use X% of total available bandwidth, while 204 best-effort and LBE traffic share the residual bandwidth. 206 If enough resources are available for other BAs and BE traffic, i.e., 207 residual bandwidth exists that is not used by best-effort traffic, LBE 208 packets may use more than the previously defined bound on their share of 209 total bandwidth, because this limit is only needed in case of congestion 210 (see Fig. 3 and 4). Therefore, any remaining resources can be used to 211 forward excess LBE traffic, because all BE demand is already met. In 212 this case, there is no reason to discard any of the LBE packets until 213 the residual bandwidth is exhausted by them, because their presence does 214 not adversely affect any of the best-effort packets. 216 OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 40% offered traffic 217 ========================================| 40% upper bound 218 OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 40% admitted traffic 220 BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 45% offered traffic 222 BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 45% admitted traffic 224 LLLLLLLLLLLLLLLLLLLLLLLLLLLL 28% offered traffic 225 ==========| 10% upper bound 226 LLLLLLLLLLLLLLL 15% admitted traffic 227 ---------------------------------------------------> 228 output link bandwidth 230 O: Other BAs, B: Best-Effort BA, L: LBE BA 232 Figure 3: Other BAs fully exploit their allotted resources, LBE BA gets 233 residual bandwidth that best-effort doesn't use. 235 OOOOOOOOOOOOOOOOOOO 15% offered traffic 236 ========================================| 40% upper bound 237 OOOOOOOOOOOOOOOOOOO 15% admitted traffic 239 BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 55% offered 241 BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 55% admitted 243 LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL 40% offered traffic 244 ==========| 10% upper bound 245 LLLLLLLLLLLLLLLLLLLLLLLLLLLLL 30% admitted traffic 246 ---------------------------------------------------> 247 output link bandwidth 249 O: Other BAs, B: Best-Effort BA, L: LBE BA 251 Figure 4: Other BAs do not fully use their allotted resources, 252 best-effort utilizes unused bandwidth of the other BAs, LBE gets 253 residual bandwidth 255 The primary objective of the LBE PHB is to segregate packets of the 256 best-effort behavior aggregate from packets which should receive a lower 257 than best-effort treatment in case of congestion. This is achieved by 258 using a higher drop precedence for LBE packets than for best-effort 259 packets, and by limiting the overall amount of LBE traffic in relation 260 to the best-effort behavior aggregate (see Fig. 5). Therefore, a 261 congested node tries to protect best-effort packets from being lost by 262 preferably discarding LBE packets. 264 OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 36% offered traffic 265 ========================================| 40% upper bound 266 OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 36% admitted traffic 268 BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 60% offered 270 BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 54% admitted 272 LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL 40% offered traffic 273 ==========| 10% upper bound 274 LLLLLLLLLLL 10% admitted traffic 275 ---------------------------------------------------> 276 output link bandwidth 278 O: Other BAs, B: Best-Effort BA, L: LBE BA 280 Figure 5: Other BAs do not fully use their allotted resources, 281 best-effort utilizes unused bandwidth of the other BAs, LBE is limited 282 to its specified upper bound. 284 With exception of the Default PHB, the LBE PHB is entirely independent 285 of all other existing PHB specifications. Thus, any other PHB groups 286 may co-exist with the LBE PHB in the same DS domain, because the LBE PHB 287 does not preempt forwarding resources of other PHB groups. 289 If only a part of all packets belonging to a microflow are marked as 290 LBE, the probability for reordering this microflow's packets may be 291 increased in dependence on the relation of the prior PHB to the LBE PHB 292 and may depend on the actual implementation. However, because the LBE 293 PHB is defined by a special relation to the Default PHB, it is 294 recommended that packets of a microflow are not reordered if they are 295 marked by codepoints associated with these two PHBs. 297 A realization of the LBE PHB may use an already existing PHB of higher 298 drop precedence (e.g., AFx2 or AFx3 from the AF PHB group [2]), if its 299 actual implementation fulfills the requirements of this specification. 301 2.2 Traffic Conditioning Actions 303 Usually, the amount of LBE traffic is implicitly limited by queueing 304 mechanisms and related discard actions. Therefore, there is normally no 305 need to meter and police LBE traffic explicitly. However, a DS domain 306 MAY control the amount of LBE traffic that enters or exits the domain. 307 Traffic conditioning actions MAY include traffic shaping and discarding 308 of packets. 310 2.3 Queueing and Discard Behavior 312 All packets of an arbitrary microflow that are marked for the LBE PHB 313 MUST NOT be reordered. The dropping algorithm MUST treat all packets 314 within the LBE BA identically, i.e., the discard rate of a particular 315 microflow's packets will be proportional to that flow's percentage of 316 the total amount of traffic with this LBE BA. 318 It is recommended that LBE packets use the same queue as best-effort 319 packets in order to avoid reordering of a microflow's packets that are 320 marked intermittently for best-effort or LBE forwarding. 322 One way to achieve the above objectives is to use a common queue for 323 best-effort and LBE packets that is actively managed by a Random Early 324 Detection (RED) scheme [5]. A separate RED parameter set is managed for 325 each traffic type. If the "current" queue length (usually a weighted 326 average value) grows beyond a lower threshold, new arriving LBE packets 327 for this queue are going to be dropped randomly with increasing 328 probability, until the queue length reaches an upper threshold. Beyond 329 this upper threshold every new incoming LBE packet for this queue is 330 going to be discarded. If the threshold values for LBE packets are 331 lower than those for best-effort packets, the RED queue will start 332 discarding packets earlier. 334 2.4 Recommended Codepoint for this PHB 336 As long as this a PHB proposal, the temporary recommended code point is 337 taken from the experimental/local use (EXP/LU) portion of the codepoint 338 space. The recommended temporary codepoint is '101011' (see section 3 339 of [1] for the meaning of this notation). 341 2.5 Configuration and Management Issues 343 There is no need for providing any resource-based admission control 344 mechanisms for this PHB. As described in section 2.1, a configurable 345 minimal bandwidth share, respectively upper bound, exists for bandwidth 346 used by the LBE BA if no residual bandwidth is left and all other 347 bandwidth is used for best-effort. 349 3 Security Considerations 351 Basically, the LBE PHB causes no other security implications besides the 352 ones already mentioned in [1]. Because LBE PHB provides a quality that 353 is even lower compared to the usual best-effort delivery, there is now 354 one more possible PHB to reduce a packet's service. 356 On the other hand, there is currently no PHB providing a worse service, 357 so LBE packets cannot be further reduced in service by re-marking. 358 Consequently, re-marking the inner header's codepoint of LBE packets at 359 the egress of a tunnel with a codepoint of another PHB would have only a 360 positive effect on these packets. However, this would possibly 361 eliminate the primary objective of the LBE and lead to depletion of 362 forwarding resources for other traffic streams in congestion situations. 364 4 Tunneling 366 When LBE packets are tunneled, the tunneling packets must also be marked 367 as LBE. 369 5 Implications on Services 371 As described in section 2.1, traffic using the current best-effort 372 service should be segregated and protected from LBE traffic in 373 congestion situations. Therefore, performance of the common best-effort 374 service is increased under those conditions. 376 6 Mapping to link-layer QoS mechanisms 378 In a shared medium LBE traffic has a very good counterpart in the 379 link-layer QoS mechanisms as defined by IEEE 802.1p: the background 380 traffic type. Therefore, packets carrying a DSCP value of the LBE PHB 381 can be mapped to 802.1p background traffic priority, i.e., setting the 382 "user_priority" field to value 1 in all link-layer frames that carry a 383 part of an LBE packet as payload. In order to achieve a real support 384 for LBE packets, link-layer frames containing best-effort packets should 385 use the default user_priority of 0 for indicating traffic type "Best 386 Effort". 388 LBE packets within a switched link-layer could also use available means 389 to indicate a higher drop precedence for LBE packets. For instance, 390 when using ATM as link-layer, the value encoded in the Cell Loss 391 Priority (CLP) field of the ATM cell header [6] may be set to 1 in all 392 ATM cells carrying a part of an LBE packet as payload, whereas cells 393 carrying a part of a best-effort packet as payload should use a CLP 394 value of 0. 396 As another example, when using Frame Relay as link-layer, the Discard 397 Eligibility Indicator (DE) bit can be set to 1 for frames containing an 398 LBE packet as payload, indicating that this frame should be discarded in 399 preference to other frames in a congestion situation [7]. All frames 400 carrying a part of a best-effort packet as payload should use a DE bit 401 value of 0. 403 7 Acknowledgments 405 Thanks to Jochen Schiller for discussion of the LBE PHB. 407 References 409 [1] F. Baker, D. Black, S. Blake, and K. Nichols. Definition of the 410 Differentiated Services Field (DS Field) in the IPv4 and IPv6 411 Headers. RFC 2474, Dec. 1998. 413 [2] F. Baker, J. Heinanen, W. Weiss, and J. Wroclawski. Assured 414 Forwarding PHB Group. RFC2597, June 1999. 416 [3] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss. 417 An Architecture for Differentiated Services. RFC 2475, Dec. 1998. 419 [4] S. Bradner. Key words for use in RFCs to Indicate Requirement 420 Levels. RFC 2119, Mar. 1997. 422 [5] S. Floyd and V. Jacobson. Random Early Detection Gateways for 423 Congestion Avoidance. IEEE/ACM Transaction on Networking, 424 1(4):397--413, Aug. 1993. 426 [6] ITU-T. B-ISDN ATM Layer Specification. ITU-T Recommendation I.361, 427 11/1995. 429 [7] ITU-T. ISDN Data Link Layer Specification for Frame Mode Bearer 430 Services. ITU-T Recommendation Q.922, 1992. 432 8 Authors' addresses 434 Comments and questions related to this draft can be addressed to one of 435 the authors listed below. 437 Roland Bless 438 Institute of Telematics 439 Universitaet Karlsruhe (TH) 440 Zirkel 2 441 D-76128 Karlsruhe 442 Germany 443 Tel.: +49 721 608 6396 444 bless@telematik.informatik.uni-karlsruhe.de 446 Klaus Wehrle 447 Institute of Telematics 448 Universitaet Karlsruhe (TH) 449 Zirkel 2 450 D-76128 Karlsruhe 451 Germany 452 Tel.: +49 721 608 6414 453 wehrle@telematik.informatik.uni-karlsruhe.de