idnits 2.17.1 draft-bless-diffserv-pdb-le-01.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 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. ** There are 124 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 161: '...or violating the SHOULD. If an AF PHB...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 318 has weird spacing: '...orkshop on "I...' -- 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 19, 2002) is 7827 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: 'MByte' is mentioned on line 643, but not defined ** Downref: Normative reference to an Informational RFC: RFC 3086 ** Downref: Normative reference to an Informational RFC: RFC 2475 -- Possible downref: Non-RFC (?) normative reference: ref. 'CBQ' -- Possible downref: Normative reference to a draft: ref. 'LBE' -- Possible downref: Normative reference to a draft: ref. 'LE' -- Possible downref: Non-RFC (?) normative reference: ref. 'SimKIDS' -- Possible downref: Non-RFC (?) normative reference: ref. 'NRS' Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Differentiated Services Working R. Bless 3 Group Univ. of Karlsruhe 4 Internet-Draft K. Nichols 5 Expires: Mai 20, 2003 Packet Design 6 K. Wehrle 7 Univ. of Karlsruhe/ICSI 8 November 19, 2002 10 A Lower Effort Per-Domain Behavior for Differentiated Services 11 draft-bless-diffserv-pdb-le-01 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on Mai 20, 2003. 36 Copyright Notice 38 Copyright (C) The Internet Society (2002). All Rights Reserved. 40 Abstract 42 This document proposes a differentiated services per-domain behavior 43 (PDB) whose traffic may be "starved" (although starvation is not 44 strictly required) in a properly functioning network. This is in 45 contrast to the Internet's "best-effort" or "normal Internet traffic" 46 model where prolonged starvation indicates network problems. In this 47 sense the proposed PDB's traffic is forwarded with a "lower" priority 48 than the normal "best-effort" Internet traffic, thus the PDB is 49 called "Lower Effort" (LE). Use of this PDB permits a network 50 operator to strictly limit the effect of its traffic on "best- 51 effort"/"normal" or all other Internet traffic. This document gives 52 some example uses, but does not propose constraining the PDB's use to 53 any particular type of traffic. 55 1. Description of the Lower Effort PDB 57 This document proposes a differentiated services per-domain behavior 58 [RFC3086] called "Lower Effort" (LE) which is intended for traffic of 59 sufficiently low value (where "value" may be interpreted in any 60 useful way by the network operator) that any other traffic should 61 take precedence over it in consumption of network link bandwidth. 62 One possible interpretation of "low value" traffic is its low 63 priority in time, which does not necessarily imply that it is 64 generally of minor importance. From this point of view it can be 65 considered as a network equivalent to a background priority for 66 processes in an operating system. There may or may not be memory 67 (buffer) resources allocated for this type of traffic. 69 Some networks carry traffic for which delivery is considered 70 optional; that is, packets of this type of traffic ought to consume 71 network resources only when no other traffic is present. 72 Alternatively, the effect of this type of traffic on all other 73 network traffic is strictly limited. This is distinct from "best- 74 effort" (BE) traffic since the network makes no commitment to deliver 75 LE packets. In contrast, BE traffic receives an implied "good faith" 76 commitment of at least some available network resources. This 77 document proposes a Lower Effort Differentiated Services per-domain 78 behavior (LE PDB) [RFC3086] for handling this "optional" traffic in a 79 differentiated services domain. 81 There is no intrinsic reason to limit the applicability of the LE PDB 82 to any particular application or type of traffic. It is intended as 83 an additional tool for administrators in engineering networks. 85 Note: where not otherwise defined, terminology used in this document 86 is defined in [RFC2474]. 88 2. Applicability 90 A Lower Effort (LE) PDB is for sending extremely non-critical traffic 91 across a DS domain or DS region. There should be an expectation that 92 packets of the LE PDB may be delayed or dropped when any other 93 traffic is present. Use of the LE PDB might assist a network 94 operator in moving certain kinds of traffic or users to off-peak 95 times. Alternatively, or in addition, packets can be designated for 96 the LE PDB when the goal is to protect all other packet traffic from 97 competition with the LE aggregate while not completely banning LE 98 traffic from the network. An LE PDB should not be used for a 99 customer's "normal internet" traffic nor should packets be 100 "downgraded" to the LE PDB used as a substitute for dropping packets 101 that ought simply to be dropped as unauthorized. The LE PDB is 102 expected to have applicability in networks that have at least some 103 unused capacity at some times of day. 105 This is a PDB that allows networks to protect themselves from 106 selected types of traffic rather than giving a selected traffic 107 aggregate preferential treatment. Moreover, it may also exploit all 108 unused resources from other PDBs. 110 3. Technical Specification 112 3.1 Classification and Traffic Conditioning 114 There are no required traffic profiles governing rate and bursts of 115 packets beyond the limits imposed by the ingress link. It is not 116 necessary to limit the LE aggregate using edge techniques since its 117 PHB is configured such that packets of the aggregate will be dropped 118 in the network if no forwarding resources are available. The 119 differentiated services architecture [RFC2475] allows packets to be 120 marked upstream of the DS domain or at the DS domain's edge. When 121 packets arrive pre-marked with the DSCP used by the LE PDB, it should 122 not be necessary for the DS domain boundary to police that marking; 123 further (MF) classification for such packets would only be required 124 if there was some reason that the packets should be marked with a 125 different DSCP. 127 If there is not an agreement on DSCP marking with the upstream domain 128 for a DS domain using the LE PDB the boundary must include a 129 classifier that selects the appropriate LE target group of packets 130 out of all arriving packets and steers them to a marker which sets 131 the appropriate DSCP. No other traffic conditioning is required. 133 3.2 PHB configuration 135 Either a Class Selector (CS) PHB [RFC2474], an Experimental/Local Use 136 (EXP/LU) PHB [RFC2474], or an Assured Forwarding (AF) PHB [RFC2597] 137 may be used as the PHB for the LE traffic aggregate. This document 138 does not specify the exact DSCP to use inside a domain, but instead 139 specifies the necessary properties of the PHB selected by the DSCP. 140 If a CS PHB is used, Class Selector 1 (DSCP=001000) is suggested. 142 The PHB used by the LE aggregate inside a DS domain should be 143 configured so that its packets are forwarded onto the node output 144 link when the link would otherwise be idle; conceptually, this is the 145 behavior of a weighted round-robin scheduler with a weight of zero. 147 An operator might choose to configure a very small link share for the 148 LE aggregate and still achieve the desired goals. That is, if the 149 output link scheduler permits, a small fixed rate might be assigned 150 to the PHB, but the behavior beyond that configured rate should be 151 that packets are forwarded only when the link would otherwise be 152 idle. This behavior could be obtained, for example, by using a CBQ 153 [CBQ] scheduler with a small share and with borrowing permited. A 154 PHB that allows packets of the LE aggregate to send more than the 155 configured rate when packets of other traffic aggregates are waiting 156 for the link is not recommended. 158 If a CS PHB is used, note that this configuration will violate the 159 "SHOULD" of section 4.2.2.2 of RFC 2474 [RFC2474] since CS1 will have 160 a less timely forwarding than CS0. An operator's goal of providing 161 an LE PDB is sufficient cause for violating the SHOULD. If an AF PHB 162 is used, it must be configured and a DSCP assigned such that it does 163 not violate the "MUST" of paragraph three of section 2 of RFC 2597 164 [RFC2597] which provides for a "minimum amount of forwarding 165 resources". 167 4. Attributes 169 The ingress and egress flow of the LE aggregate can be measured but 170 there are no absolute or statistical attributes that arise from the 171 PDB definition. A particular network operator may configure the DS 172 domain in such a way that a statistical metric can be associated with 173 that DS domain. When the DS domain is known to be heavily congested 174 with traffic of other PDBs, a network operator should expect to see 175 no (or very few) packets of the LE PDB egress from the domain. When 176 there is no other traffic present, the proportion of the LE aggregate 177 that successfully crosses the domain should be limited only by the 178 capacity of the network relative to the ingress LE traffic aggregate. 180 5. Parameters 182 None required. 184 6. Assumptions 186 A properly functioning network. 188 7. Example uses 190 o Multimedia applications [this example edited from Yoram Bernet]: 192 Many network managers want to protect their networks from 193 certain applications, in particular, from multimedia 194 applications that typically use such non-adaptive protocols as 195 UDP. 197 Most of the focus in quality-of-service is on achieving 198 attributes that are better than Best Effort. These approaches 199 can provide network managers with the ability to control the 200 amount of multimedia traffic that is given this improved 201 performance with excess relegated to Best Effort. This excess 202 traffic can wreak havoc with network resources even when it is 203 relegated to Best Effort because it is non-adaptive and because 204 it can be significant in volume and duration. These 205 characteristics permit it to seize network resources, thereby 206 compromising the performance of other, more important 207 applications that are included in the Best Effort traffic 208 aggregate but that use adaptive protocols (e.g., TCP). As a 209 result, network managers often simply refuse to allow 210 multimedia applications to be deployed in resource constrained 211 parts of their network. 213 The LE PDB enables a network manager to allow the deployment of 214 multimedia applications without losing control of network 215 resources. A limited amount of multimedia traffic may (or may 216 not) be assigned to PDBs with attributes that are better than 217 Best Effort. Excess multimedia traffic can be prevented from 218 wreaking havoc with network resources by forcing it to the LE 219 PDB. 221 o For Netnews and other "bulk mail" of the Internet. 223 o For "downgraded" traffic from some other PDB when this does not 224 violate the operational objectives of the other PDB or the overall 225 network. As noted in section 2, LE should not be used for the 226 general case of downgraded traffic, but may be used by design, 227 e.g. when multicast is used with a value-added DS-service and 228 consequently the Neglected Reserviation Subtree problem [NRS] 229 arises. 231 o For content distribution, Napster traffic, and the like. 233 o For traffic caused by world-wide web search engines while they 234 gather information from web servers. 236 8. Experiences 238 The authors solicit further experiences for this section. Results 239 from simulations are presented and discussed in Appendix A. 241 9. Security Considerations for LE PDB 243 There are no specific security exposures for this PDB. See the 244 general security considerations in [RFC2474] and [RFC2475]. 246 10. History of the LE PDB 248 The previous name of this PDB, "bulk handling", was loosely based on 249 the United States' Postal Service term for very low priority mail, 250 sent at a reduced rate: it denotes a lower-cost delivery where the 251 items are not handled with the same care or delivered with the same 252 timeliness as items with first-class postage. Finally, the name was 253 changed to "lower effort", because the authors and other DiffServ 254 Working Group members believe that the name should be more generic in 255 order to not imply constraints on the PDB's use to a particular type 256 of traffic (namely that of bulk data). 258 The notion of having something "lower than Best Effort" was raised in 259 the Diffserv Working Group, most notably by Roland Bless and Klaus 260 Wehrle in their Internet Drafts [LBE] and [LE] and by Yoram Bernet 261 for enterprise multimedia applications. One of its first 262 applications was to re-mark packets within multicast groups [NRS]. 263 Therefore, previous discussions centered on the creation of a new PHB 264 which the original authors (Brian Carpenter and Kathleen Nichols) 265 believe is not required. This document was specifically written to 266 explain how to get less than Best Effort without a new PHB. 268 11. Acknowledgments 270 Yoram Bernet contributed significant text for the "Examples" section 271 of this document and other useful comments that helped in editing. 272 Other Diffserv WG members suggested that the LE PDB is needed for 273 Napster traffic, particularly at universities. Special thanks go to 274 Milena Neumann for her extensive efforts in performing the 275 simulations that are described in Appendix A. 277 References 279 [RFC3086] Nichols, K. and B. Carpenter, "Definition of 280 Differentiated Services Per Domain Behaviors and Rules for 281 their Specification", RFC 3086, April 2001. 283 [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, 284 "Definition of the Differentiated Services Field (DS 285 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 286 1998. 288 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. 290 and W. Weiss, "An Architecture for Differentiated 291 Services", RFC 2475, December 1998. 293 [RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, 294 "Assured Forwarding PHB Group", RFC 2597, June 1999. 296 [CBQ] Floyd, S. and V. Jacobson, "Link-sharing and Resource 297 Management Models for Packet Networks", IEEE/ACM 298 Transactions on Networking, Vol. 3, No. 4, pp. 365-386, 299 August 1995. 301 [LBE] Bless, R. and K. Wehrle, "A Lower Than Best-Effort Per-Hop 302 Behavior", draft-bless-diffserv-lbe-phb-00 (work in 303 progress), September 1999. 305 [LE] Bless, R. and K. Wehrle, "A Limited Effort Per-Hop 306 Behavior", draft-bless-diffserv-le-phb-00 (work in 307 progress), February 2001. 309 [SimKIDS] Wehrle, K., Reber, J. and V. Kahmann, "A simulation suite 310 for Internet nodes with the ability to integrate arbitrary 311 Quality of Service behavior", in Proceedings of 312 Communication Networks And Distributed Systems Modeling 313 And Simulation Conference (CNDS 2001), Phoenix (AZ), USA, 314 pp. 115-122, January 2001. 316 [NRS] Bless, R. and K. Wehrle, "Group Communication in 317 Differentiated Services Networks", in Proceedings of IEEE 318 International Workshop on "Internet QoS", Brisbane, 319 Australia, IEEE Press, pp. 618-625, May 2001. 321 Authors' Addresses 323 Roland Bless 324 Institute of Telematics, Universitaet Karlsruhe (TH) 325 Zirkel 2 326 76128 Karlsruhe 327 Germany 329 EMail: bless@tm.uka.de 330 URI: http://www.tm.uka.de/~bless/ 331 Kathleen Nichols 332 Packet Design 333 3400 Hillview Avenue, Building 3 334 Palo Alto, CA 94304 335 USA 337 EMail: nichols@packetdesign.com 339 Klaus Wehrle 340 Instit. of Telematics, Universitaet Karlsruhe (TH) 341 Zirkel 2, 76128 Karlsruhe, Germany & 342 International Computer Science Institute (ICSI) 343 1947 Center Street, Berkeley, CA, 94704, USA 345 EMail: klaus@wehrle.com 346 URI: http://www.icsi.berkeley.edu/~wehrle/ 348 Appendix A. Experiences from a Simulation Model 350 The intention of this appendix is to show that a Lower Effort PDB 351 with a behavior as described in this document can be realized with 352 different implementations and PHBs respectively. Overall, each of 353 these variants show the desired behavior but also minor differences 354 in certain traffic load situations. This comparison could make the 355 choice of a realization variant interesting for a network operator. 357 A.1 Simulation Environment 359 The small DiffServ domain shown in Figure 1 was used to simulate the 360 LE PDB. There are three main sources of traffic (S1-S3) depicted on 361 the left side of the figure. Source S1 sends five aggregated TCP 362 flows (A1-A5) to the receivers R1-R5 respectively. Each aggregated 363 flow Ax consists of 20 TCP connections, where each aggregate 364 experienced a different round trip time between 10ms and 250ms. 365 There are two sources of bulk traffic. B1 consists of 100 TCP 366 connections sending as much data as possible to R6 and B2 is a single 367 UDP flow also sending as much as possible to R7. 369 --------------------------------------------------------------------- 371 ................... 372 . . R1 373 . . / 374 . . /-R2 375 . . / 376 S1==**=>[BR1] [BR4]==**==>---R3 377 . \\ // . \ 378 . \\ // . \-R4 379 . ** ** . \ 380 . \\ // . R5 381 . \\ // . 382 S2=++=>[BR2]-++-[IR1]==**==++==::==[IR2] . 383 (Bulk) . // \\ . 384 . // :: . 385 . :: \\ . 386 . // ++ . 387 .// \\. 388 S3==::==>[BR3] [BR5]==++==>R6 389 (UDP) . . || 390 . . || 391 . . :: 392 .................... || 393 VV 394 R7 396 Figure 1: A DiffServ domain with different flows 398 --------------------------------------------------------------------- 400 In order to show the benefit of using the LE PDB instead of the 401 normal Best Effort (BE) PDB [RFC3086], different scenarios are used: 403 A) B1 and B2 are not present, i.e. the "normal" situation without 404 bulk data present. A1-A5 use the BE PDB. 405 B) B1 and B2 use the BE PDB for their traffic, too. 406 C) B1 and B2 use LE PDB for their traffic 407 with different PHB implementations: 408 1) PHB with Priority Queueing 409 2) PHB with Weighted Fair Queueing (WFQ) 410 3) PHB with Weighted RED (WRED) 411 4) PHB with WFQ and RED 413 C1) represents the case where there are no allocated resources for 414 the LE PDB, i.e. LE traffic is only forwarded if there are unused 415 resources. In scenarios C2)-C4) a bandwidth share of 10% has been 416 allocated for the LE PDB. RED parameters were set to w_q=0.1 and 417 max_p=0.2. In scenario C2) two tail drop queues were used for BE and 418 LE and WFQ scheduling was set up with a weight of 9:1 for the ratio 419 of BE:LE. In scenario C3) a total queue length of 200000 bytes was 420 used and the following thresholds: min_th_BE=19000, max_th_BE=63333, 421 min_th_LE=2346, max_th=7037. WRED allows to mark packets with BE or 422 LE within the same microflow (e.g., letting applications pre-mark 423 packets according to their importance) without causing a reordering 424 of packets within the microflow. In scenario C4) each queue had a 425 length of 50000 bytes and the same thresholds of min_th=18000 and 426 max_th=48000 bytes. WFQ parameters were the same as in C2). 428 The link bandwidth between IR1 and IR2 is limited to 1200 kbit/s, 429 thus creating the bottleneck in the network for the following 430 situations. In all situations the 20 TCP connections within each 431 aggregated flow Ax (flowing from S1 to Rx) used the Best Effort PDB. 432 Sender S2 transmitted bulk flow B1 (consisting of 100 TCP connections 433 to R6) with an aggregated rate of 550 kbit/s, whereas the UDP sender 434 S3 transmitted with a rate of 50 kbit/s. 436 The following four different situations with varying traffic load for 437 the Ax flows (at application level) were simulated. 439 Situation | I | II | III | IV | 440 ----------------------------+------+------+------+------| 441 Sender Rate S1 [kbit/s] | 1200 | 1080 | 1800 | 800 | 442 Sender Rate S2 [kbit/s] | 550 | 550 | 550 | 550 | 443 Sender Rate S3 [kbit/s] | 50 | 50 | 50 | 50 | 444 Bandwidth IR1 -> IR2 | 1200 | 1200 | 1200 | 1200 | 445 Best Effort Load (S1) | 100% | 90% | 150% | 67% | 446 Total load for link IR1->IR2| 150% | 140% | 200% | 117% | 448 In situation I, there are no unused resources left for the B1 and B2 449 flows. In situation II, there is a residual bandwidth of 10% of the 450 bottleneck link between IR1 and IR2. In situation III the traffic 451 load of A1-A5 is 50% higher than the bottleneck link capacity. In 452 situation IV, A1-A5 consume only 2/3 of the bottleneck link capacity. 453 B1 and B2 require together 50% of the bottleneck link capacity. 455 The simulations were performed with the freely available discrete 456 event simulation tool OMNeT++ and a suitable set of QoS mechanisms 457 [SimKIDS]. Results from the different simulation scenarios are 458 discussed in the next section. 460 A.2 Simulation Results 462 QoS parameters listed in the following tables are averaged over the 463 first 160s of the transmission. Results of situation I are shown in 464 Figure 2. When the BE PDB is used for transmission of bulk flows B1 465 and B2 in case B), one can see that flows A1-A5 throttle their 466 sending rate to allow transmission of bulk flows B1 and B2. In case 467 C1) not a single packet is transmitted to the receiver, because all 468 packets get dropped within IR1, thereby protecting Ax flows from Bx 469 flows. In case C2) B1 and B2 consume all resources up to the 470 configured limit of 10% of the link bandwidth, but not more. C3) 471 also limits the share of B1 and B2 flows, but not as precise as with 472 WFQ. C4) shows slightly higher packet losses for Ax flows due to the 473 active queue management. 475 --------------------------------------------------------------------- 477 +-------------------------+--------+-----------------------------------+ 478 | | | Bulk Transfer with PDB: | 479 | QoS Parameter | A) | B) | C) Lower Effort | 480 | |No bulk | Best | 1) 2) 3) 4) | 481 | Flows |transfer|Effort| PQ | WFQ | WRED |RED&WFQ| 482 +----------------+--------+--------+------+------+------+------+-------+ 483 | | A1 | 240 | 71 | 240 | 214 | 225 | 219 | 484 | | A2 | 240 | 137 | 240 | 216 | 223 | 218 | 485 | | A3 | 240 | 209 | 240 | 224 | 220 | 217 | 486 | Throughput | A4 | 239 | 182 | 239 | 222 | 215 | 215 | 487 | [kbit/s] | A5 | 238 | 70 | 238 | 202 | 201 | 208 | 488 | | B1 | - | 491 | 0 | 82 | 85 | 84 | 489 | | B2 | - | 40 | 0 | 39 | 31 | 38 | 490 +----------------+--------+--------+------+------+------+------+-------+ 491 |Total Throughput| normal | 1197 | 669 | 1197 | 1078 | 1084 | 1078 | 492 | [kbit/s] | bulk | - | 531 | 0 | 122 | 116 | 122 | 493 +----------------+--------+--------+------+------+------+------+-------+ 494 | | A1 | 0 | 19.3 | 0 | 6.3 | 5.7 | 8.6 | 495 | | A2 | 0 | 17.5 | 0 | 6.0 | 5.9 | 8.9 | 496 | | A3 | 0 | 10.2 | 0 | 3.2 | 6.2 | 9.1 | 497 | Paket Loss | A4 | 0 | 12.5 | 0 | 4.5 | 6.6 | 9.3 | 498 | [%] | A5 | 0 | 22.0 | 0 | 6.0 | 5.9 | 9.0 | 499 | | B1 | - | 10.5 | 100 | 33.6 | 38.4 | 33.0 | 500 | | B2 | - | 19.6 | 100 | 19.9 | 37.7 | 22.2 | 501 +----------------+--------+--------+------+------+------+------+-------+ 502 | Total Packet | normal | 0 | 14.9 | 0 | 5.2 | 6.1 | 9.0 | 503 | Loss Rate [%] | bulk | 0 | 11.4 | 100 | 29.5 | 38.2 | 29.7 | 504 +----------------+--------+--------+------+------+------+------+-------+ 505 | Transmitted | | | | | | | | 506 | Data [MByte] | normal | 21.9 | 12.6 | 21.9 | 19.6 | 20.3 | 20.3 | 507 +----------------+--------+--------+------+------+------+------+-------+ 509 Figure 2: Situation I - Best Effort traffic uses 100% of the 510 available bandwidth 512 --------------------------------------------------------------------- 514 Results of situation II are shown in Figure 3: In case C1) LE traffic 515 gets exactly the 10% residual bandwidth that is not used by the Ax 516 flows. Cases C2) and C4) show similar results compared to C1), 517 whereas case C3) also drops packets from flows A1-A5 due to active 518 queue management. 520 --------------------------------------------------------------------- 522 +-------------------------+--------+-----------------------------------+ 523 | | | Bulk Transfer with PDB: | 524 | QoS Parameter | A) | B) | C) Lower Effort | 525 | |No bulk | Best | 1) 2) 3) 4) | 526 | Flows |transfer|Effort| PQ | WFQ | WRED |RED&WFQ| 527 +----------------+--------+--------+------+------+------+------+-------+ 528 | | A1 | 216 | 193 | 216 | 216 | 211 | 216 | 529 | | A2 | 216 | 171 | 216 | 216 | 211 | 216 | 530 | | A3 | 216 | 86 | 216 | 216 | 210 | 216 | 531 | Throughput | A4 | 215 | 121 | 215 | 215 | 211 | 215 | 532 | [kbit/s] | A5 | 215 | 101 | 215 | 215 | 210 | 215 | 533 | | B1 | - | 488 | 83 | 83 | 114 | 84 | 534 | | B2 | - | 39 | 39 | 39 | 33 | 38 | 535 +----------------+--------+--------+------+------+------+------+-------+ 536 |Total Throughput| normal | 1078 | 672 | 1077 | 1077 | 1053 | 1077 | 537 | [kbit/s] | bulk | - | 528 | 122 | 122 | 147 | 122 | 538 +----------------+--------+--------+------+------+------+----+-+-------+ 539 | | A1 | 0 | 9.4 | 0 | 0 | 1.8 | 0 | 540 | | A2 | 0 | 14.6 | 0 | 0 | 2.0 | 0 | 541 | | A3 | 0 | 22.4 | 0 | 0 | 2.1 | 0 | 542 | Paket Loss | A4 | 0 | 15.5 | 0 | 0 | 1.8 | 0 | 543 | [%] | A5 | 0 | 17.4 | 0 | 0 | 1.9 | 0 | 544 | | B1 | - | 11.0 | 32.4 | 32.9 | 35.7 | 33.1 | 545 | | B2 | - | 21.1 | 20.3 | 20.7 | 34.0 | 22.2 | 546 +----------------+--------+--------+------+------+------+------+-------+ 547 | Total Packet | normal | 0 | 14.9 | 0 | 0 | 1.9 | 0 | 548 | Loss Rate [%] | bulk | - | 12.0 | 28.7 | 29.1 | 35.3 | 29.8 | 549 +----------------+--------+--------+------+------+------+------+-------+ 550 | Transmitted | | | | | | | | 551 | Data [MByte] | normal | 19.8 | 12.8 | 19.8 | 19.8 | 19.5 | 19.8 | 552 +----------------+--------+--------+------+------+------+------+-------+ 554 Figure 3: Situation II - Best Effort traffic uses 90% of the 555 available bandwidth 557 --------------------------------------------------------------------- 558 Results of simulations for situation III are depicted in Figure 4. 559 Due to overload caused by flows A1-A5, their packets get dropped in 560 all cases. Bulk flows B1 and B2 nearly get their maximum throughput 561 in case B). As one would expect, in case C1) all packets from B1 and 562 B2 are dropped, in cases C2) and C4) resource consumption of bulk 563 data is limited to the configured share of 10%. Again the WRED 564 implementation in C3) is not as accurate as the WFQ variants and lets 565 more BE traffic pass through IR1. 567 --------------------------------------------------------------------- 569 +-------------------------+--------+-----------------------------------+ 570 | | | Bulk Transfer with PDB: | 571 | QoS Parameter | A) | B) | C) Lower Effort | 572 | |No bulk | Best | 1) 2) 3) 4) | 573 | Flows |transfer|Effort| PQ | WFQ | WRED |RED&WFQ| 574 +----------------+--------+--------+------+------+------+------+-------+ 575 | | A1 | 303 | 136 | 241 | 298 | 244 | 276 | 576 | | A2 | 316 | 234 | 286 | 299 | 240 | 219 | 577 | | A3 | 251 | 140 | 287 | 259 | 236 | 225 | 578 | Throughput | A4 | 168 | 84 | 252 | 123 | 209 | 219 | 579 | [kbit/s] | A5 | 159 | 82 | 132 | 101 | 166 | 141 | 580 | | B1 | - | 483 | 0 | 83 | 73 | 83 | 581 | | B2 | - | 41 | 0 | 38 | 31 | 38 | 582 +----------------+--------+--------+------+------+------+------+-------+ 583 |Total Throughput| normal | 1199 | 676 | 1199 | 1079 | 1096 | 1079 | 584 | [kbit/s] | bulk | - | 524 | 0 | 121 | 104 | 121 | 585 +----------------+--------+--------+------+------+------+------+-------+ 586 | | A1 | 9.6 | 17.6 | 12.1 | 9.3 | 8.6 | 12.8 | 587 | | A2 | 8.5 | 13.6 | 8.4 | 9.8 | 8.1 | 14.5 | 588 | | A3 | 8.8 | 18.7 | 7.7 | 11.6 | 7.8 | 13.6 | 589 | Paket Loss | A4 | 14.9 | 22.3 | 11.2 | 18.9 | 8.2 | 12.4 | 590 | [%] | A5 | 12.8 | 19.0 | 15.6 | 19.7 | 8.3 | 14.3 | 591 | | B1 | - | 11.9 | 100 | 32.1 | 39.5 | 33.0 | 592 | | B2 | - | 17.3 | 100 | 22.5 | 37.7 | 22.8 | 593 +----------------+--------+--------+------+------+------+------+-------+ 594 | Total Packet | normal | 10.4 | 17.3 | 10.3 | 12.2 | 8.2 | 13.4 | 595 | Loss Rate [%] | bulk | - | 12.4 | 100 | 29.1 | 39.0 | 29.9 | 596 +----------------+--------+--------+------+------+------+------+-------+ 597 | Transmitted | | | | | | | | 598 | Data [MByte] | normal | 22.0 | 12.6 | 22.0 | 20.2 | 20.6 | 20.3 | 599 +----------------+--------+--------+------+------+------+------+-------+ 601 Figure 4: Situation III - Best Effort traffic load is 150% 603 --------------------------------------------------------------------- 604 In situation IV, 33% or 400 kbit/s are not used by Ax flows and the 605 results are listed in Figure 5. In case B) where bulk data flows B1 606 and B2 use the BE PDB, packets of Ax flows are dropped, whereas in 607 cases C1)-C4) flows Ax are protected from bulk flows B1 and B2. 608 Therefore, by using the LE PDB for Bx flows, the latter get only the 609 residual bandwidth of 400 kbit/s but not more. Packets of Ax flows 610 are not affected by Bx traffic in these cases. 612 --------------------------------------------------------------------- 614 +-------------------------+--------+-----------------------------------+ 615 | | | Bulk Transfer with PDB: | 616 | QoS Parameter | A) | B) | C) Lower Effort | 617 | |No bulk | Best | 1) 2) 3) 4) | 618 | Flows |transfer|Effort| PQ | WFQ | WRED |RED&WFQ| 619 +----------------+--------+--------+------+------+------+------+-------+ 620 | | A1 | 160 | 140 | 160 | 160 | 160 | 160 | 621 | | A2 | 160 | 124 | 160 | 160 | 160 | 160 | 622 | | A3 | 160 | 112 | 160 | 160 | 160 | 160 | 623 | Throughput | A4 | 160 | 137 | 160 | 160 | 159 | 160 | 624 | [kbit/s] | A5 | 159 | 135 | 159 | 159 | 159 | 159 | 625 | | B1 | - | 509 | 361 | 362 | 364 | 362 | 626 | | B2 | - | 43 | 40 | 39 | 38 | 40 | 627 +----------------+--------+--------+------+------+------+------+-------+ 628 |Total Throughput| normal | 798 | 648 | 798 | 798 | 797 | 798 | 629 | [kbit/s] | bulk | - | 551 | 401 | 401 | 402 | 401 | 630 +----------------+--------+--------+------+------+------+------+-------+ 631 | | A1 | 0 | 9.2 | 0 | 0 | 0 | 0 | 632 | | A2 | 0 | 12.2 | 0 | 0 | 0 | 0 | 633 | | A3 | 0 | 14.0 | 0 | 0 | 0 | 0 | 634 | Paket Loss | A4 | 0 | 9.3 | 0 | 0 | 0 | 0 | 635 | [%] | A5 | 0 | 6.6 | 0 | 0 | 0 | 0 | 636 | | B1 | - | 7.3 | 21.2 | 21.8 | 25.0 | 21.3 | 637 | | B2 | - | 14.3 | 19.4 | 20.7 | 24.5 | 20.7 | 638 +----------------+--------+--------+------+------+------+------+-------+ 639 | Total Packet | normal | 0 | 10.2 | 0 | 0 | 0 | 0 | 640 | Loss Rate [%] | bulk | - | 8.0 | 21.0 | 21.7 | 25.0 | 21.2 | 641 +----------------+--------+--------+------+------+------+------+-------+ 642 | Transmitted | | | | | | | | 643 | Data [MByte] | normal | 14.8 | 12.1 | 14.8 | 14.8 | 14.7 | 14.7 | 644 +----------------+--------+--------+------+------+------+------+-------+ 646 Figure 5: Situation IV - Best Effort traffic load is 67% 648 --------------------------------------------------------------------- 650 In summary, all the different scenarios show that the "normal" BE 651 traffic can be protected from traffic in the LE PDB effectively. 652 Either no packets get through if no residual bandwidth is left (LE 653 traffic is starved), or traffic of the LE PDB can only consume 654 resources up to a configurable limit. 656 Furthermore, the results substantiate that mass data transfer can 657 affect adversely "normal" BE traffic (e.g., 14.9% packet loss in 658 situations I and II, even 10.2% in situation IV) in situations 659 without using the LE PDB. 661 Thus, while all presented variants of realizing the LE PDB meet the 662 desired behavior of protecting BE traffic, they also show small 663 differences in detail. So a network operator has the possibility to 664 choose a realization method to fit the desired behavior (showing this 665 is - after the proof of LE's efficacy - the second designation of 666 this appendix). For instance, if operators want to starve LE traffic 667 completely in times of congestion, they could choose PQ. This causes 668 LE traffic to be completely starved and not a single packet would get 669 through in case of full load or overload. 671 On the other hand, for network operators who want to permit some 672 small amount of throughput in the LE PDB, one of the other variants 673 would be a better choice. 675 Referring to this, the WFQ implementation showed a slightly more 676 robust behavior with PQ, but had problems with synchronized TCP 677 flows. WRED behavior is highly dependent of the actual traffic 678 characteristics and packet loss rates are often higher compared to 679 other locations, while the fairness between TCP connections is 680 better. The combined solution of WFQ with RED showed the overall 681 best behavior, when an operator's intent is to keep a small but 682 noticeable throughput in the LE PDB. 684 Full Copyright Statement 686 Copyright (C) The Internet Society (2002). All Rights Reserved. 688 This document and translations of it may be copied and furnished to 689 others, and derivative works that comment on or otherwise explain it 690 or assist in its implementation may be prepared, copied, published 691 and distributed, in whole or in part, without restriction of any 692 kind, provided that the above copyright notice and this paragraph are 693 included on all such copies and derivative works. However, this 694 document itself may not be modified in any way, such as by removing 695 the copyright notice or references to the Internet Society or other 696 Internet organizations, except as needed for the purpose of 697 developing Internet standards in which case the procedures for 698 copyrights defined in the Internet Standards process must be 699 followed, or as required to translate it into languages other than 700 English. 702 The limited permissions granted above are perpetual and will not be 703 revoked by the Internet Society or its successors or assigns. 705 This document and the information contained herein is provided on an 706 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 707 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 708 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 709 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 710 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 712 Acknowledgement 714 Funding for the RFC Editor function is currently provided by the 715 Internet Society.