idnits 2.17.1 draft-charny-pcn-single-marking-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1274. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1285. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1292. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1298. 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 abstract seems to contain references ([I-D.briscoe-tsvwg-cl-architecture]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (March 5, 2007) is 6234 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) == Unused Reference: 'I-D.briscoe-tsvwg-re-ecn-tcp' is defined on line 1213, but no explicit reference was found in the text == Unused Reference: 'I-D.lefaucheur-emergency-rsvp' is defined on line 1222, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-briscoe-tsvwg-re-ecn-tcp-03 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Charny 2 Internet-Draft Cisco Systems, Inc. 3 Intended status: Standards Track J. Zhang 4 Expires: September 6, 2007 Cisco Systems, Inc. and Cornell 5 University 6 F. Le Faucheur 7 V. Liatsos 8 Cisco Systems, Inc. 9 March 5, 2007 11 Pre-Congestion Notification Using Single Marking for Admission and Pre- 12 emption 13 draft-charny-pcn-single-marking-01.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on September 6, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 Pre-Congestion Notification [I-D.briscoe-tsvwg-cl-architecture] 47 approach proposes the use of an Admission Control mechanism to limit 48 the amount of real-time PCN traffic to a configured level during the 49 normal operating conditions, and the use of a Pre-emption mechanism 50 to tear-down some of the flows to bring the PCN traffic level down to 51 a desirable amount during unexpected events such as network failures, 52 with the goal of maintaining the QoS assurances to the remaining 53 flows. In [I-D.briscoe-tsvwg-cl-architecture], Admission and Pre- 54 emption use two different markings and two different metering 55 mechanisms in the internal nodes of the PCN region. This draft 56 proposes a mechanism using a single marking and metering for both 57 Admission and Pre-emption, and presents a preliminary analysis of the 58 tradeoffs. A side-effect of this proposal that a different marking 59 and metering Admission mechanism than that proposed 60 in[I-D.briscoe-tsvwg-cl-architecture] may be also feasible. 62 Requirements Language 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in RFC 2119 [RFC2119]. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.1. Changes from -00 version . . . . . . . . . . . . . . . . . 4 72 1.2. Background and Motivation . . . . . . . . . . . . . . . . 4 73 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 74 2. The Single Marking Approach . . . . . . . . . . . . . . . . . 6 75 2.1. High Level description . . . . . . . . . . . . . . . . . . 6 76 2.2. Operation at the PIN . . . . . . . . . . . . . . . . . . . 7 77 2.3. Operation at the Egress PEN . . . . . . . . . . . . . . . 7 78 2.4. Operation at the Ingress PEN . . . . . . . . . . . . . . . 8 79 2.4.1. Admission Decision . . . . . . . . . . . . . . . . . . 8 80 2.4.2. Pre-emption Decision . . . . . . . . . . . . . . . . . 9 81 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 3.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 3.2. Tradeoffs, Issues and Discussion . . . . . . . . . . . . . 10 84 3.2.1. Restrictions on Pre-emption-to-admission Thresholds . 10 85 3.2.2. Assumptions on Loss . . . . . . . . . . . . . . . . . 10 86 3.2.3. Effect of Reaction Timescale of Admission Mechanism . 10 87 3.2.4. Performance Implications and Tradeoffs . . . . . . . . 11 88 3.2.5. Effect on Proposed Anti-cheating Mechanisms . . . . . 11 89 3.2.6. Standards Implications . . . . . . . . . . . . . . . . 12 90 4. Performance Evaluation Comparison . . . . . . . . . . . . . . 12 91 4.1. Relationship to other drafts . . . . . . . . . . . . . . . 12 92 4.2. Limitations, Conclusions and Direction for Future Work . . 12 93 4.2.1. High Level Conclusions . . . . . . . . . . . . . . . . 12 94 4.2.2. Future work . . . . . . . . . . . . . . . . . . . . . 13 95 5. Appendix A: Simulation Details . . . . . . . . . . . . . . . 14 96 5.1. Network and Signaling Model . . . . . . . . . . . . . . . 14 97 5.2. Traffic Models . . . . . . . . . . . . . . . . . . . . . . 16 98 5.2.1. CBR Voice (CBR) . . . . . . . . . . . . . . . . . . . 17 99 5.2.2. VBR Voice (VBR) . . . . . . . . . . . . . . . . . . . 17 100 5.2.3. "Synthetic Video": High Rate ON-OFF traffic with 101 Video-like Mean and Peak Rates ("SVD") . . . . . . . 17 102 5.2.4. Real Video Traces (VTR) . . . . . . . . . . . . . . . 17 103 5.3. Parameter Settings . . . . . . . . . . . . . . . . . . . . 18 104 5.3.1. Queue-based settings . . . . . . . . . . . . . . . . . 18 105 5.3.2. Token Bucket Settings . . . . . . . . . . . . . . . . 18 106 5.4. Simulation Details . . . . . . . . . . . . . . . . . . . . 19 107 5.4.1. Queue-based Results . . . . . . . . . . . . . . . . . 19 108 5.4.2. Token Bucket-based Results . . . . . . . . . . . . . . 23 109 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 110 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 111 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 112 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27 113 8.2. Informative References . . . . . . . . . . . . . . . . . . 27 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 115 Intellectual Property and Copyright Statements . . . . . . . . . . 30 117 1. Introduction 119 1.1. Changes from -00 version 121 Added miscellaneous clarifications based on comments received on 122 version -00. Added simulation results for multi-hop topologies and 123 video trace data to the Appendix. 125 1.2. Background and Motivation 127 Pre-Congestion Notification [I-D.briscoe-tsvwg-cl-architecture] 128 approach proposes to use an Admission Control mechanism to limit the 129 amount of real-time PCN traffic to a configured level during the 130 normal operating conditions, and to use a Pre-emption mechanism to 131 tear-down some of the flows to bring the PCN traffic level down to a 132 desirable amount during unexpected events such as network failures, 133 with the goal of maintaining the QoS assurances to the remaining 134 flows. In [I-D.briscoe-tsvwg-cl-architecture], Admission and Pre- 135 emption use different two different markings and two different 136 metering mechanisms in the internal nodes of the PCN region. 137 Admission Control algorithms for variable-rate real-time traffic such 138 as video have traditionally been based on the observation of the 139 queue length, and hence re-using these techniques and ideas in the 140 context of pre-congestion notification is highly attractive, and 141 motivated the virtual-queue-based marking and metering approach 142 specified in [I-D.briscoe-tsvwg-cl-architecture] for Admission. On 143 the other hand, for Pre-emption, it is desirable to know how much 144 traffic needs to be pre-empted, and that in turn motivates rate-based 145 Pre-emption metering. This provides some motivation for employing 146 different metering algorithm for Admission and for Preemption. 148 Furthermore, it is frequently desirable to trigger Pre-emption at a 149 substantially higher traffic level than the level at which no new 150 flows are to be admitted. There are multiple reasons for the 151 requirement to enforce a different Admission Threshold and Preemption 152 Threshold. These include, for example: 154 o End-users are typically more annoyed by their established call 155 dying than by getting a busy tone at call establishment. 157 o There are often very tight (possibly legal) obligations on network 158 operators to not drop established calls. 160 o Voice Call Routing often has the ability to route/establish the 161 call on another network (e.g., PSTN) if it is determined at call 162 establishment that one network (e.g., packet network) can not 163 accept the call. Therefore, not admitting a call on the packet 164 network at initial establishment may not impact the end-user. In 165 contrast, it is usually not possible to reroute an established 166 call onto another network mid-call. This means that call 167 Preemption can not be hidden to the end-user. 169 o Preemption is typically useful in failure situations where some 170 loads get rerouted thereby increasing the load on remaining links. 171 Because the failure may only be temporary, the operator may be 172 ready to tolerate a small degradation during the interim failure 173 period. 175 o A congestion notification based Admission scheme has some inherent 176 inaccuracies because of its reactive nature and thus may 177 potentially over admit in some situations (such as burst of calls 178 arrival). If the Preemption scheme reacted at the same Threshold 179 as the Admission Threshold, calls may get routinely dropped after 180 establishment because of over admission, even under steady state 181 conditions. 183 These considerations argue for metering for Admission and Pre-emption 184 at different traffic levels and hence, implicitly, for different 185 markings and metering schemes. 187 Different marking schemes require different codepoints. Thus, such 188 separate markings consume valuable real-estate in the packet header, 189 especially scarce in the case of MPLS Pre-Congestion Notification 190 [I-D.davie-ecn-mpls] . Furthermore, two different measurement/ 191 metering techniques involve additional complexity in the datapath of 192 the internal routers of the PCN domain. 194 To this end, [I-D.briscoe-tsvwg-cl-architecture] proposes an 195 approach, referred to as implicit pre-emption marking, that does not 196 require separate pre-emption marking. However, it does require two 197 separate measurement schemes: one measurement for Admission and 198 another measurement for Preemption/Dropping. Furthermore, this 199 approach mandates that the configured preemption rate be set to a 200 drop rate. This approach effectively uses dropping as the way to 201 convey information about how much traffic can "fit" under the 202 preemption limit, instead of using a separate preemption marking. 203 This is a significant restriction in that it results in preemption 204 only taking effect once packets actually get dropped. 206 This document presents an approach that allows the use of a single 207 PCN marking and a single metering technique at the internal devices 208 without requiring that the dropping and pre-emption thresholds be the 209 same. This document also investigates some of the tradeoffs 210 associated with this approach. 212 1.3. Terminology 214 o Pre-Congestion Notification (PCN): two algorithms that determine 215 when a PCN-enabled router Admission Marks and Pre-emption Marks a 216 packet, depending on the traffic level. 218 o Admission Marking condition- the traffic level is such that the 219 router Admission Marks packets. The router provides an "early 220 warning" that the load is nearing the engineered admission control 221 capacity, before there is any significant build-up in the queue of 222 packets belonging to the specified real-time service class. 224 o Pre-emption Marking condition- the traffic level is such that the 225 router Pre-emption Marks packets. The router warns explicitly 226 that pre-emption may be needed. 228 o Configured-admission-rate - the reference rate used by the 229 admission marking algorithm in a PCN-enabled router. 231 o Configured-pre-emption-rate - the reference rate used by the pre- 232 emption marking algorithm in a PCN-enabled router. 234 o CLE - congestion level estimate computed by the egress node by 235 estimating as the fraction of admission-marked packets it 236 receives. 238 o PIN - PCN internal node - an internal node in the PCN region. 240 o PEN - PCN edge node - an ingress or egress edge node of the PCN 241 region. 243 o SAR - Sustainable Admission rate - the rate of unmarked traffic 244 received by the Ingress PEN from the egress PEN 246 o SPR - Sustainable Preemption rate 248 2. The Single Marking Approach 250 2.1. High Level description 252 The proposed approach is based on several simple ideas: 254 o Replace virtual-queue-based marking for Admission Control by 255 excess rate marking: 257 * meter traffic exceeding the Admission Threshold and mark excess 258 traffic (e.g. using a token bucket with the rate configured to 259 Admission Rate Threshold) 261 * at the edges, stop admitting traffic when the fraction of 262 marked traffic for a given edge-to-edge aggregate exceeds a 263 configured threshold (e.g. stop admitting when 3% of all 264 traffic in the edge-to-edge aggregate received at the ingress 265 is marked) 267 o Impose a PCN-region-wide constraint on the ratio between the 268 Admission threshold on a link and Pre-emption threshold on that 269 link (e.g. pre-emption threshold is 20% higher than Admission 270 threshold on all links in the PCN region) 272 o The edge PCN device determines whether Pre-emption level is 273 reached anywhere in the network *implicitly* by measuring the 274 amount of unmarked traffic (assuming the marked traffic actually 275 is above the threshold triggering blocking admission), i.e. the 276 traffic that did not get admission marked. This is analogous to 277 the notion of sustainable pre-emption rate in 278 [I-D.briscoe-tsvwg-cl-architecture]. The rate of unmarked traffic 279 in this case signifies the bottleneck admission threshold. The 280 bottleneck pre-emption threshold is by design within the chosen 281 ratio of that admission threshold. The ingress PCN edge device 282 preempts all traffic above the bottleneck preemption threshold. 284 The remaining part of this section gives more detailed of a possible 285 operation of the system. 287 2.2. Operation at the PIN 289 The PCN Internal Node (PIN) meters the aggregate PCN traffic and 290 marks the excess rate. A number of implementations are possible to 291 achieve that. A token bucket implementation is particularly 292 attractive because of its relative simplicity, and even more so 293 because a token bucket implementation is readily available in the 294 vast majority of existing equipment. The rate of the token bucket is 295 configured to correspond to the target Admission rate, and the depth 296 of the token bucket can be configured by an operator based on the 297 desired tolerance to PCN traffic burstiness. 299 Note that no preemption threshold is explicitly configured at the 300 PIN, and the PIN does nothing at all to enforce it or mark traffic 301 based on Pre-emption threshold. 303 2.3. Operation at the Egress PEN 305 The PCN Egress Node (PEN) measures the rate of both marked and 306 unmarked traffic on a per-ingress PEN basis, and reports to the 307 ingress PEN two values: the rate of unmarked traffic from this 308 ingress PEN, which we deem Sustainable Admission Rate (SAR) and the 309 Congestion Level Estimate (CLE), which is the fraction of the marked 310 traffic received from this ingress PEN. Note that Sustainable 311 Admission Rate is analogous to the sustainable pre-emption rate of 312 [I-D.briscoe-tsvwg-cl-architecture], except in this case it is based 313 on the admission threshold rather than pre-emption threshold, while 314 the CLE is exactly the same as that of 315 [I-D.briscoe-tsvwg-cl-architecture]. The details of the rate 316 measurement are outside the scope of this draft. 318 2.4. Operation at the Ingress PEN 320 2.4.1. Admission Decision 322 Just as in [I-D.briscoe-tsvwg-cl-architecture], the admission 323 decision is based on the CLE. The ingress PEN stops admission of new 324 flows if the CLE is above a pre-defined threshold (e.g. 3%). Note 325 that although the logic of the decision is exactly the same as in the 326 case of [I-D.briscoe-tsvwg-cl-architecture], the detailed semantics 327 of the marking is different. This is because the marking used for 328 admission in this proposal reflects the excess rate over the 329 admission threshold, while in [I-D.briscoe-tsvwg-cl-architecture], 330 the marking is based on exceeding a virtual queue threshold. 331 Notably, in the current proposal, if the average sustained rate of 332 admitted traffic is 5% over the admission threshold, then 5% of the 333 traffic is expected to be marked, whereas in the context of 334 [I-D.briscoe-tsvwg-cl-architecture] a steady 5% overload should 335 eventually result in 100% of all traffic being admission marked. A 336 consequence of this is that for smooth traffic, the approach 337 presented here will not mark any traffic at all until the rate of the 338 traffic exceeds the configured admission threshold by the amount 339 corresponding to the chosen CLE threshold. At first glance this may 340 seem to result in a violation of the pre-congestion notification 341 premise that attempts to stop admission before the desired traffic 342 level is reached. However, in reality one can simply embed the CLE 343 level into the desired configuration of the admission threshold. 344 That is, if a certain rate X is the actual target admission 345 threshold, then one should configure the rate of the metering device 346 (e.g. the rate of the token bucket) to X-y where y corresponds to the 347 level of CLE that would trigger admission blocking decision. 349 A more important distinction is that virtual-queue based marking 350 reacts to short-term burstiness of traffic, while the excess-rate 351 based marking is only capable of reacting to rate violations at the 352 timescale chosen for rate measurement. Based on our investigation, 353 it seems that this distinction is not crucial in the context of PCN 354 when no actual queuing is expected even if the virtual queue is full. 356 More discussion on this is presented later in the draft. 358 2.4.2. Pre-emption Decision 360 When the ingress observes a non-zero CLE and Sustainable Admission 361 Rate (SAR), it first computes the Sustainable Pre-Emption rate (SPR) 362 by simply multiplying SAR by the system-wide constant u, where u is 363 the system-wide ratio between pre-emption and admission thresholds on 364 all links in the PCN domain: SPR = SAR*u. The ingress PEN then 365 performs exactly the same operation as is proposed in 366 [I-D.briscoe-tsvwg-cl-architecture] with respect to SPR. Namely, it 367 pre-empts the appropriate number of flows to ensure that the rate of 368 traffic it sends to the corresponding egress PEN does not exceed SPR. 369 Just as in the case of [I-D.briscoe-tsvwg-cl-architecture], an 370 implementation may decide to slow down the pre-emption process by 371 preempting fewer flows than is necessary to cap its traffic to SPR by 372 employing a variety of techniques such as safety factors or 373 hysteresis. In summary, the operation of pre-emption at the ingress 374 PEN is identical to that of [I-D.briscoe-tsvwg-cl-architecture], with 375 the only exception that the sustainable pre-emption rate is computed 376 from the sustainable admission rate rather than derived from a 377 separate marking. As discussed earlier, this is enabled by imposing 378 a system-wide restriction on the pre-emption-to-admission thresholds 379 ratio and changing the semantics of the admission marking. 381 3. Discussion 383 3.1. Benefits 385 The key benefits of using a single metering/marking scheme for both 386 Admission and Preemption presented in this document are summarized 387 below: 389 o Reduced implementation requirements on core routers due to a 390 single metering implementation instead of two different ones. 392 o Ease of use on existing hardware: given that the proposed approach 393 is particularly amenable to a token bucket implementation, the 394 availability of token buckets on virtually all commercially 395 available routers makes this approach especially attractive. 397 o Reduced number of codepoints which need to be conveyed in the 398 packet header. If the PCN-bits used in the packets header to 399 convey the congestion notification information are the ECN-bits in 400 an IP core and the EXP-bits in an MPLS core, as is currently 401 proposed in [put marking draft reference here] and 402 [I-D.davie-ecn-mpls], those are very expensive real-estate. The 403 current proposals need 5 codepoints, which is especially important 404 in the context of MPLS where there is only a total of 8 EXP 405 codepoints which must also be shared with Diffserv. Eliminating 406 one codepoint considerably helps. 408 o A possibility of using a token-bucket-, excess-rate- based 409 implementation for admission provides extra flexibility for the 410 choice of an admission mechanism, even if two separate markings 411 and thresholds are used. 413 3.2. Tradeoffs, Issues and Discussion 415 While the benefits of the proposed approach are attractive, there are 416 several issues and tradeoffs that need to be carefully considered. 418 3.2.1. Restrictions on Pre-emption-to-admission Thresholds 420 An obvious restriction necessary for the single-marking approach is 421 that the ratio of (implicit) pre-emption and admission thresholds 422 remains the same on all links in the PCN region. While clearly a 423 limitation, this does not appear to be particularly crippling, and 424 does not appear to outweigh the benefits of reducing the overhead in 425 the router implementation and savings in codepoints in the case of a 426 single PCN domain, or in the case of multiple concatenated PCN 427 regions. The case when this limitation becomes more inconvenient is 428 when an operator wants to merge two previously separate PCN regions 429 (which may have different admission-to-preemption ratios) into a 430 single PCN region. In this case it becomes necessary to do a 431 network-wide reconfiguration to align the settings. 433 3.2.2. Assumptions on Loss 435 Just as in the case of [I-D.briscoe-tsvwg-cl-architecture], the 436 approach presented in this draft assumes that the Admission Threshold 437 is configured at each link below the service rate of the traffic 438 using PCN. This assumption is significant because the algorithm 439 relies on the fact that if admission threshold is exceeded, enough 440 marked traffic reaches the egress PEN to reach the configured CLE 441 level. If this condition does not hold, then traffic may get dropped 442 without ever triggering admission decision. 444 3.2.3. Effect of Reaction Timescale of Admission Mechanism 446 As mentioned earlier in this draft, there is a potential concern that 447 slower reaction time of admissions mechanism presented in this draft 448 compared to [I-D.briscoe-tsvwg-cl-architecture] may result in 449 overshoot when the load grows rapidly, and undershoot when the load 450 drops rapidly. While this is a valid concern theoretically, it 451 should be noted that at least for the traffic and parameters used in 452 the simulation study reported here, there was no indication that this 453 was a problem. However, the comparison has so far been done for 454 Poisson arrivals only. Future work would look in performing a 455 similar comparison for burstier arrivals. 457 3.2.4. Performance Implications and Tradeoffs 459 Replacement of a relatively well-studied queue-based measurement- 460 based admission control approach by a cruder excess-rate measurement 461 technique raises a number of algorithmic and performance concerns 462 that need to be carefully evaluated. For example, a token-bucket 463 excess rate measurement is expected to be substantially more 464 sensitive to traffic burstiness and parameter setting, which may have 465 a significant effect in the case of lower levels of traffic 466 aggregation, especially for variable-rate traffic such as video. In 467 addition, the appropriate timescale of rate measurement needs to be 468 carefully evaluated, and in general it depends on the degree of 469 expected traffic variability which is frequently unknown. 471 In view of that, an initial performance comparison of the token- 472 bucket based measurement is presented in the following section. 473 Within the constraints of this preliminary study, the performance 474 tradeoffs observed between the queue-based technique suggested in 475 [I-D.briscoe-tsvwg-cl-architecture] and a simpler token-bucket-based 476 excess rate measurement do not appear to be a cause of substantial 477 concern for cases when traffic aggregation is reasonably high at the 478 bottleneck links as well as on a per ingress-egress pair basis. 479 Details of the simulation study, as well as additional discussion of 480 its implications are presented in section 4. 482 Also, one mitigating consideration in favor of the simpler mechanism 483 is that in a typical DiffServ environment, the real-time traffic is 484 expected to be served at a higher priority and/or the target 485 admission rate is expected to be substantially below the speed at 486 which the real-time queue is actually served. If these assumptions 487 hold, then there is some margin of safety for an admission control 488 algorithm, making the requirements for admission control more 489 forgiving to bounded errors - see additional discussion in section 4. 491 3.2.5. Effect on Proposed Anti-cheating Mechanisms 493 Replacement of the queue-based admission control mechanism of 494 [I-D.briscoe-tsvwg-cl-architecture] by an excess-rate based admission 495 marking changing the semantics of the pre-congestion marking, and 496 consequently interfereres with mechanisms for cheating detection 497 discussed in [I-D.briscoe-tsvwg-re-ecn-border-cheat]. Implications 498 of excess-rate based marking on the anti-cheating mechanisms need to 499 be considered. 501 3.2.6. Standards Implications 503 The change of the meaning of admission marking for pre-congestion 504 notification from the queue-based to excess-rate marking poses a 505 question of coexistence of devices having different interpretation of 506 admissions marking (and hence different metering and marking 507 mechanisms in the core. The question of how and if the two 508 mechanisms can co-exist in one PCN region has obvious impact on 509 standardization efforts, and needs to be carefully considered. 511 4. Performance Evaluation Comparison 513 4.1. Relationship to other drafts 515 Initial simulation results of admission and pre-emption mechanisms of 516 [I-D.briscoe-tsvwg-cl-architecture] were reported in 517 [I-D.briscoe-tsvwg-cl-phb]. A follow-up study of these mechanisms is 518 presented in a companion draft 519 draft-zhang-cl-performance-evaluation-01.txt. The current draft 520 concentrates on a performance comparison of the admission control 521 mechanism of [I-D.briscoe-tsvwg-cl-phb] and the token-bucket-based 522 admission control described in section 2 of this draft. 524 4.2. Limitations, Conclusions and Direction for Future Work 526 Due to time constraints, the study performed so far was limited to a 527 small set of topologies, described in the Appendix. The key 528 questions that have been investigated are the comparative sensitivity 529 of the two schemes to parameter settings and the effect of traffic 530 burstiness and of the degree of aggregation on a per ingress-egress 531 pair on the performance of the admission control algorithms under 532 study. The study is limited to the case where there is no packet 533 loss. While this is a reasonable initial assumption for an admission 534 control algorithm that is supposed to maintain the traffic level 535 significantly below the service capacity of the corresponding queue, 536 nevertheless future study is necessary to evaluate the effect of 537 packet loss. 539 4.2.1. High Level Conclusions 541 The results of this (preliminary) study indicate that there is a 542 potential that a reasonable complexity/performance tradeoff may be 543 viable for the choice of admission control algorithm. In turn, this 544 suggests that using a single codepoint and metering technique for 545 admission and pre-emption may be a viable option. 547 The key high-level conclusions of the simulation study comparing the 548 performance of queue-based and token-based admission control 549 algorithms are summarized below: 551 1. At reasonable level of aggregation at the bottleneck and per 552 ingress-egress pair traffic, both algorithms perform reasonably 553 well for the range of traffic models considered (see section 4.3. 554 for detail). 556 2. Both schemes are stressed for small levels of ingress-egress pair 557 aggregation levels of bursty traffic (e.g. a single video-like 558 bursty SVD flow per ingress-egress pair). However, while the 559 queue-based scheme results in tolerable performance even at low 560 levels of per ingress-egress aggregation, the token-bucket-based 561 scheme is substantially more sensitive to parameter setting than 562 the queue-based scheme, and its performance for the high rate 563 bursty SVD traffic with low levels of ingress-egress aggregation 564 is quite poor unless parameters are chosen carefully to curb the 565 error. It should be noted that the SVD traffic model used in 566 this study is expected to be substantially more challenging for 567 both admission and pre-emption mechanisms that the actual video 568 traffic, as the latter is expected to be much smoother than the 569 busrty on-off model with high peak-to-mean ratio we used. This 570 expectation is confirmed by the fact that simulations with actual 571 video traces reported in this version of the draft reveal that 572 the performance of the video traces is much closer to that of VBR 573 voice than of our crude SVD on-off model. 575 3. Even for small per ingress-egress pair aggregation, reasonable 576 performance across a range of traffic models can be obtained for 577 both algorithms (with a narrower range of parameter setting for 578 the token-bucket based approach) . 580 4. The absolute value of round-trip time (RTT) or the RTT difference 581 between different ingress-egress pair within the range of 582 continental propagation delays does not appear to have a visible 583 effect on the performance of both algorithms. 585 4.2.2. Future work 587 This study is but the first step in performance evaluation of the 588 token-bucket based admission control. Further evaluation should 589 include a range of investigation, including the following: 591 o fairness issues (how different ingress-egress pairs get access to 592 bottleneck bandwidth) 594 o interactions between admission control and preemption 596 o effect of loss of marked packets 598 o much more 600 5. Appendix A: Simulation Details 602 5.1. Network and Signaling Model 604 Network topologies used in this study are shown in the Figures below. 605 The network is modeled as either Single Link (Fig. A.1), Multi Link 606 Network with a single bottleneck (termed "RTT", Fig. A.2), or a range 607 of multi-bottleneck topologies shown in Fig. A.3 (termed "Parking 608 Lot"). 610 A --- B 612 Figure A.1: Simulated Single Link Network. 614 A 616 \ 618 B - D - F 620 / 622 C 624 Figure A.2: Simulated Multi Link Network. 626 A--B--C A--B--C--D A--B--C--D--E--F 627 | | | | | | | | | | | | | 628 | | | | | | | | | | | | | 629 D E F E F G H G H I J K L 631 (a) (b) (c) 633 Figure A.3: Simulated Multiple-bottleneck (Parking Lot )Topologies. 635 Figure A.1 shows a single link between an ingress and an egress node, 636 all flows enter at node A and depart at node B. In Figure A.2, A set 637 of ingresses (A,B,C) connected to an interior node in the network 638 (D). The number of ingresses varied in different simulation 639 experiments in the range of 2-100. All links have generally 640 different propagation delays, in the range 1ms - 100 ms. This node D 641 in turn is connected to the egress (F). In this topology, different 642 sets of flows between each ingress and the egress converge on the 643 single link D-F, where pre-congestion notification algorithm is 644 enabled. The capacities of the ingress links are not limiting, and 645 hence no PCN is enable on those. The bottleneck link D-F is modeled 646 with a 10ms propagation delay in all simulations. Therefore the 647 range of round-trip delays in the experiments is from 22ms to 220ms. 648 Our simulations concentrated primarily on capacities of 'bottleneck' 649 links with sufficient aggregation - OC3 for voice and for SVD 650 traffic, up to 1 Gbps. In the simulation model, a call requests 651 arrive at the ingress and immediately sends a message to the egress. 652 The message arrives at the egress after the propagation time plus 653 link processing time (but no queuing delay). When the egress 654 receives this message, it immediately responds to the ingress with 655 the current Congestion-Level-Estimate. If the Congestion-Level- 656 Estimate is below the specified CLE-threshold, the call is admitted, 657 otherwise it is rejected. An admitted call sends packets according 658 to one of the chosen traffic models for the duration of the call (see 659 next section). Propagation delay from source to the ingress and from 660 destination to the egress is assumed negligible and is not modeled. 662 Another type of network of interest is multi-bottleneck (or Parking 663 Lot, PLT for short) topology. The simplest PLT with 2 bottlenecks is 664 illustrated in Fig A.3(a). An example traffic matrix with this 665 network on this topology is as follows: 667 o an aggregate of "2-hop" flows entering the network at A and 668 leaving at C (via the two links A-B-C) 670 o an aggregate of "1-hop" flows entering the network at D and 671 leaving at E (via A-B) 673 o an aggregate of "1-hop" flows entering the network at E and 674 leaving at F (via B-C) 676 In the 2-hop PLT shown in Fig. A.3(a) the points of congestion are 677 links A--B and B--C. Capacity of all other links is not limiting. 678 We also experiment with larger PLT topologies with 3 bottlenecks(see 679 Fig A.3(b)) and 5 bottlenecks ( Fig A.3 (c)). In all cases, we 680 simulated one ingress-egress pair that carries the aggregate of 681 "long" flows traversing all the N bottlenecks (where N is the number 682 of bottleneck links in the PLT topology), and N ingress-egress pairs 683 that carry flows traversing a single bottleneck link and exiting at 684 the next "hop". In all cases, only the "horizontal" links in Fig. 686 A.3 were the bottlenecks, with capacities of all "vertical" links 687 non-limiting. Propagation delays for all links in all PLT topologies 688 are set to 1ms. 690 Due to time limitations, other possible traffic matrices (e.g. some 691 of the flows traversing a subset of several bottleneck links) have 692 not yet been considered and remain the area for future investigation. 693 Our simulations concentrated primarily on the range of capacities of 694 'bottleneck' links with sufficient aggregation - above 10 Mbps for 695 voice and 622 Mbps for SVD, up to 2.4 Gbps. But we also investigated 696 slower 'bottleneck' links down to 512 Kbps in some experiments. In 697 the simulation model of admission control, a call request arrives at 698 the ingress and immediately sends a message to the egress. The 699 message arrives at the egress after the propagation time plus link 700 processing time (but no queuing delay). When the egress receives 701 this message, it immediately responds to the ingress with the current 702 Congestion Level Estimate. If the Congestion Level Estimate is below 703 the specified CLE- threshold, the call is admitted, otherwise it is 704 rejected. For preemption, once the ingress node of a PCN region 705 decides to preempt a call, that call is preempted immediately and 706 sends no more packets from that time on. The life of a call outside 707 the domain described above is not modelled. Propagation delay from 708 source to the ingress and from destination to the egress is assumed 709 negligible and is not modelled. 711 5.2. Traffic Models 713 Four types of traffic were simulated (CBR voice, on-off traffic 714 approximating voice with silence compression, and on-off traffic with 715 higher peak and mean rates (we termed the latter synthetic video 716 (SDV) as the chosen peak and mean rate was similar to that of an MPEG 717 video stream, although no attempt was made to match any other 718 parameters of this traffic to those of a video stream), and finally 719 real video traces. The distribution of flow duration was chosen to 720 be exponentially distributed with mean 1min, regardless of the 721 traffic type. In most of the experiments flows arrived according to 722 a Poisson distribution with mean arrival rate chosen to achieve a 723 desired amount of overload over the configured-admission-limit in 724 each experiment. Overloads in the range 1x to 5x and underload with 725 0.95x have been investigated. Note that the rationale for looking at 726 the load 1and below is to see if any significant amount of "false 727 rejects" would be seen (i.e. one would assume that all traffic should 728 be accepted if the total demand is below the admission threshold). 729 For on-off traffic, on and off periods were exponentially distributed 730 with the specified mean. Traffic parameters for each type are 731 summarized below: 733 5.2.1. CBR Voice (CBR) 735 o Average rate 64 Kbps 737 o Packet length 160 bytes 739 o packet inter-arrival time 20ms 741 5.2.2. VBR Voice (VBR) 743 o Packet length 160 bytes 745 o Long-term average rate 21.76 Kbps 747 o On Period mean duration 340ms; during the on period traffic is 748 sent with the CBR voice parameters described above 750 o Off Period mean duration 660ms; no traffic is sent during the off 751 period. 753 5.2.3. "Synthetic Video": High Rate ON-OFF traffic with Video-like 754 Mean and Peak Rates ("SVD") 756 This model is on-off traffic with video-like mean-to-peak ratio and 757 mean rate approximating that of an MPEG-2 video stream. No attempt 758 is made to simulate any other aspects of a video stream, and this 759 model is merely that of on-off traffic. Although there is no claim 760 that this model represents the performance of video traffic under the 761 algorithms in question adequately, intuitively, this model should be 762 more challenging for a measurement-based algorithm than the actual 763 MPEG video, and as a result, 'good' or "reasonable" performance on 764 this traffic model indicates that MPEG traffic should perform at 765 least as well. We term this type of traffic SVD for "Synthetic 766 Video". 768 o Long term average rate 4 Mbps 770 o On Period mean duration 340ms; during the on-period the packets 771 are sent at 12 Mbps (1500 byte packets, packet inter-arrival: 1ms) 773 o Off Period mean duration 660m 775 5.2.4. Real Video Traces (VTR) 777 We used a publicly available library of frame size traces of long 778 MPEG-4 and H.263 encoded video obtained from 779 http://www.tkn.tu-berlin.de/research/trace/trace.html (courtesy 780 Telecommunication Networks Group of Technical University of Berlin). 782 Each trace is roughly 60 minutes in length, consisting of a list of 783 records in the format of . Among the 784 160 available traces, we picked the two with the highest average rate 785 (averaged over the trace length, in this case, 60 minutes. In 786 addition, the two also have a similar average rate). The trace file 787 used in the simulation is the concatenation of the two. Since the 788 duration of the flow is much smaller than the length of the trace, we 789 need to check how does the expect rate of flow related the trace's 790 long term average. To do so, we simulate a number of flows starting 791 from random locations in the trace with duration chosen to be 792 exponentially distributed with mean 1min. The results show that the 793 expected rate of flow is roughly the same as the trace's average. 794 Traffic characteristics are summarized below: 796 o Average rate 769 Kbps 798 o Each frame is sent with packet length 1500 bytes and packet inter- 799 arrival time 1ms 801 o No traffic is sent between frames. 803 5.3. Parameter Settings 805 5.3.1. Queue-based settings 807 All the queue-based simulations were run with the following Virtual 808 Queue thresholds: 810 o virtual-queue-rate: configured admission rate, 1/2 link speed 812 o min-marking-threshold: 5ms at virtual-queue-rate 814 o max-marking-threshold: 15ms at virtual-queue-rate 816 o virtual-queue-upper-limit: 20ms at virtual-queue-rate 818 At the egress, the CLE is computed as an exponential weighted moving 819 average (EWMA) on an interval basis, with 100ms measurement interval 820 chosen in all simulations. We simulated the weight ranging 0.1 to 821 0.9. The CLE threshold is chosen to be 0.05, 0.15, 0.25, and 0.5. 823 5.3.2. Token Bucket Settings 825 The token bucket rate is set to the configured admission rate, which 826 is half of the link speed in all experiments. Token bucket depth 827 ranges from 64 to 512 packets. Our simulation results indicate that 828 depth of token bucket has no significant impact on the performance of 829 the algorithms and hence, in the rest of the section, we only present 830 the result with 256 packets bucket depth. 832 The CLE is calculated in the same way as in queue-based approach with 833 weights from 0.1 to 0.9. The CLE thresholds are chosen to be 0.0001, 834 0.001, 0.01, 0.05 in this case. Note that the since meaning of the 835 CLE is different for the Token bucket and queue-based algorithms, so 836 there is no direct correspondence between the choice of the CLE 837 thresholds in the two cases. 839 5.4. Simulation Details 841 To evaluate the performance of the algorithms, we recorded the actual 842 admitted load at a granularity of 50ms, from which the mean admitted 843 load over the duration of the simulation run can be computed. We 844 verified that the actual admitted load at any time does not deviate 845 much from the mean admitted load in each experiment by computing the 846 coefficient of variation (CV is consistently 0.07 for CBR, 0.15 for 847 VBR, 0.17 for VTR and 0.51 for SVD for all experiments). Finally, 848 the performance of the algorithms is evaluated using a metric called 849 over-admission-percentage, which is calculated as a percentage 850 difference between the mean admitted load and the configured 851 admission rate. Given reasonably small deviation of the admitted 852 rate from the mean admitted in the experiments, this seems 853 reasonable. 855 5.4.1. Queue-based Results 857 We found that the virtual-queue admission control algorithm works 858 reliably with the range of parameters we simulated, for all four 859 types of traffic. In addition, for both CBR, VBR and VTR traffic, 860 the performance is insensitive to the parameters change under all 861 tested topologies. 863 Table A.1 summarized over-admission-percentage values from 15 864 experiments with different [weight, CLE threshold] settings for CBR, 865 VBR and VTR traffic. For the single bottleneck topologies (S. Link 866 and RTT) the overload column represents the ratio of the demand on 867 the bottleneck link to the configured admission threshold. For 868 parking lot topologies we report the worst case result across all 869 bottlenecks. 871 While in our simulations we tested the range of overload from 0.95 to 872 5, we present here only the results of the endpoints of this overload 873 interval. For the intermediate values of overload the results are 874 even closer to the expected ones than at the two boundary loads. The 875 statistics show that for CBR, VBR and VTR traffic these over- 876 admission-percentage values are rather similar across these traffic 877 types, with the admitted load roughly staying within -2%+2% range of 878 the desired admission threshold, with quite limited variability 879 across the experiments (see the Standard Deviation column). Note 880 also that this is not always true for all experiments with 0.95 881 average load due to the variability of traffic generation. 883 ---------------------------------------------------------- 884 | Over Admission Perc Stats | Over | Topo | Type | 885 | Min | Mean | Max | SD | Load | | | 886 ---------------------------------------------------------- 887 | 0 | 0 | 0 | 0 | 0.95 | | | 888 |------------------------------------------| S.Link | | 889 | 0.224 | 0.849 | 1.905 | 0.275 | 5 | | | 890 |---------------------------------------------------| | 891 | 0 | 0 | 0 | 0 | 0.95 | | | 892 |------------------------------------------| RTT | CBR | 893 | 0.200 | 0.899 | 1.956 | 0.279 | 5 | | | 894 |---------------------------------------------------| | 895 | -1.06 | -0.33 | -0.15 | 0.228 | 0.95 | | | 896 |------------------------------------------| PLT | | 897 | -0.58 | 0.740 | 1.149 | 0.404 | 5 | | | 898 |---------------------------------------------------------- 899 | -1.45 | -0.98 | -0.86 | 0.117 | 0.95 | | | 900 |------------------------------------------| S.Link | | 901 | -0.07 | 1.405 | 1.948 | 0.421 | 5 | | | 902 |---------------------------------------------------| | 903 | -1.56 | -0.80 | -0.69 | 0.16 | 0.95 | | | 904 |------------------------------------------| RTT | VBR | 905 | -0.11 | 1.463 | 2.199 | 0.462 | 5 | | | 906 |---------------------------------------------------| | 907 | -3.49 | -2.23 | -1.80 | 0.606 | 0.95 | | | 908 |------------------------------------------| PLT | | 909 | -1.37 | 0.978 | 1.501 | 0.744 | 5 | | | 910 ---------------------------------------------------------- 911 | 0 | 0 | 0 | 0 | 0.95 | | | 912 |------------------------------------------| S.Link | | 913 | -0.53 | 1.004 | 1.539 | 0.453 | 5 | | | 914 |---------------------------------------------------| | 915 | 0 | 0 | 0 | 0 | 0.95 | | | 916 |------------------------------------------| RTT | VTR | 917 | -0.21 | 1.382 | 1.868 | 0.503 | 5 | | | 918 |---------------------------------------------------| | 919 | 0 | 0 | 0 | 0 | 0.95 | | | 920 |------------------------------------------| PLT | | 921 | -0.86 | 0.686 | 1.117 | 0.452 | 5 | | | 922 ---------------------------------------------------------- 923 Table A.1 Summarized performance for CBR, VBR and VTR across 924 different settings. 926 For SVD, the algorithms does show certain sensitivity to the tested 927 parameters. Table A.2 recorded the over-admission-percentage for 928 each combination of weights and CLE threshold. 930 ------------------------------------------------------------------- 931 | | EWMA Weights | Over | Topo | 932 | | 0.1 | 0.3 | 0.5 | 0.7 | 0.9 | Load | | 933 ------------------------------------------------------------------- 934 | 0.05 | -4.87 | -3.05 | -2.92 | -2.40 | -2.40 | | | 935 | 0.15 | -3.67 | -2.99 | -2.40 | -2.40 | -2.40 | 0.95 | | 936 | 0.25 | -2.67 | -2.40 | -2.40 | -2.40 | -2.40 | | | 937 | -------------------------------------------------------| Single | 938 | C 0.05 | -4.03 | 2.52 | 3.45 | 5.70 | 5.17 | | Link | 939 | L 0.15 | -0.81 | 3.29 | 6.35 | 6.80 | 8.13 | 5 | | 940 | E 0.25 | 2.15 | 5.83 | 6.81 | 8.62 | 7.95 | | | 941 | ---------------------------------------------------------------- 942 | T 0.05 | -11.77 | -8.35 | -5.23 | -2.64 | -2.35 | | | 943 | H 0.15 | -9.71 | -7.14 | -2.01 | -2.21 | -1.13 | 0.95 | | 944 | R 0.25 | -5.54 | -6.04 | -3.28 | -0.88 | -0.27 | | | 945 | E -------------------------------------------------------| RTT | 946 | S 0.05 | -5.04 | -0.65 | 4.21 | 6.65 | 9.90 | | | 947 | S 0.15 | -1.02 | 1.58 | 7.21 | 8.24 | 10.07 | 5 | | 948 | H 0.25 | -0.76 | 1.96 | 7.43 | 9.66 | 11.26 | | | 949 | E ---------------------------------------------------------------- 950 | L 0.05 | -2.51 | -0.85 | -0.63 | 0.025 | -0.00 | | | 951 | D 0.15 | -1.50 | -0.63 | -0.02 | 0.052 | -0.02 | 0.95 | | 952 | 0.25 | -0.26 | 0.122 | 0.041 | -0.02 | 0.132 | | | 953 | -------------------------------------------------------| PLT | 954 | 0.05 | -3.50 | 0.422 | 1.899 | 3.339 | 3.770 | | | 955 | 0.15 | -1.04 | 2.016 | 3.251 | 3.880 | 3.991 | 5 | | 956 | 0.25 | 0.449 | 2.965 | 3.066 | 4.107 | 4.737 | | | 957 ------------------------------------------------------------------- 958 Table A.2 Over-admission-percentage for SVD 960 It follows from these results that while performance is tolerable 961 across the entire range of parameters, choosing the CLE and EWMA 962 weights in the middle of the tested range appear to be more 963 beneficial for the overall performance across the chosen range of 964 overload, assuming the chosen values for the remaining parameters. 965 The high level conclusion that can be drawn from Table A.2. is that 966 (predictably) high peak-to-mean ratio SVD traffic is substantially 967 more stressful to the queue-based admission control algorithm, but a 968 set of parameters exists that keeps the overadmission within about 969 -3% - +10% of the expected load even for the bursty SVD traffic. 971 Note that for SVD traffic these results hold even though there is no 972 aggregation at all on a per-ingress-egress pair in the chosen RTT 973 topology there is only a single SVD flow per ingress. In addition, 974 there seems to be no visible influence by multiple bottleneck 975 topology, as the results appears to be comparable to the ones in 976 single bottleneck cases. (Note that it may seem from the data in 977 A.2, PLT out-performs the Single Link. The reason is that the 978 bottleneck links in PLT happen to be twice the size of the ones in 979 SingleLink cases. Given the same admission threshold, this implies 980 that level of aggregation in PLT is twice as much as in the 981 SingleLink. Hence, the better results in PLT should be viewed as the 982 effect of the aggregation rather than the effect multi-bottleneck 983 topology.) 985 5.4.2. Token Bucket-based Results 987 Just as for the case of the queue-based algorithm, under the under- 988 loaded conditions for voice-like CBR, VBR and VTR traffic the 989 sensitivity to the tested parameters remains limited for the token- 990 bucket as well (the latter is summarized in Table A.3). 992 ---------------------------------------------------------- 993 | Over Admission Perc Stat | Load | Topo | Type | 994 | Min | Mean | Max | SD | | | | 995 ---------------------------------------------------------- 996 | 0 | 0 | 0 | 0 | 0.95 | S.Link | | 997 |---------------------------------------------------| | 998 | 0 | 0 | 0 | 0 | 0.95 | RTT | CBR | 999 |---------------------------------------------------| | 1000 | -1.17 | -0.24 | 0.023 | 0.294 | 0.95 | PLT | | 1001 ---------------------------------------------------------- 1002 | -2.00 | -0.78 | -0.95 | 0.268 | 0.95 | S.Link | | 1003 |---------------------------------------------------| | 1004 | -2.83 | -0.70 | -1.20 | 0.510 | 0.95 | RTT | VBR | 1005 |---------------------------------------------------| | 1006 | -6.19 | -2.43 | -1.32 | 1.223 | 0.95 | PLT | | 1007 ---------------------------------------------------------- 1008 | 0 | 0 | 0 | 0 | 0.95 | S.Link | | 1009 |---------------------------------------------------| | 1010 | 0 | 0 | 0 | 0 | 0.95 | RTT | VTR | 1011 |---------------------------------------------------| | 1012 | 0 | 0 | 0 | 0 | 0.95 | PLT | | 1013 ---------------------------------------------------------- 1014 Table A.3 Summarized performance for CBR, VBR and VTR across 1015 different settings for under-loaded conditions. 1017 However, for the overload conditions (overload greater than 1), the 1018 token bucket-based admission control algorithm shows substantially 1019 higher sensitivity to the parameter settings compared to the virtual 1020 queue based algorithm. Table A.4 shows over-admission-percentage for 1021 different settings. It is important to note here that for the token 1022 bucket-based admission control no traffic will be marked until the 1023 rate of traffic exceeds the configured admission rate by the chosen 1024 CLE. As a consequence, even with the ideal performance of the 1025 algorithms, the over-admission-percentage will not be 0, rather it is 1026 expected to equal to CLE threshold if the algorithm performs as 1027 expected. Therefore, a more meaningful metric for the token-based 1028 results is actually the over-admission-percentage (listed below) 1029 minus the corresponding (CLE threshold * 100). For example, for CLE 1030 = 0.05, one would expect that 5% overadmission is inherently embedded 1031 in the algorithm, with the algorithm by design reacting to 5% 1032 overload (or more) only. Hence, with CLE = 0.05 a 10% over-admission 1033 in the token-bucket case should be compared to a 5% overadmission in 1034 the queue-based algorithm. When comparing the performance of token 1035 bucket (with the adjusted over-admission-percentage) to its 1036 corresponding virtual queue result, we found that token bucket 1037 performs only slightly worse for voice-like CBR VBR, and VTR traffic. 1039 The results for SVD traffic require some additional commentary. Note 1040 from the results in Table A.4. that even for SVD traffic, in the 1041 Single Link topology the performance of the token-based solution is 1042 comparable to the performance of the queue-based scheme in table A.2, 1043 (adjusted by the CLE as discussed above). However, for the RTT 1044 topology, especially for the larger EWMA weights, the performance for 1045 SVD traffic becomes very bad, with up to 42% (adjusted by CLE) over- 1046 admission in a high overload situation (5x). We investigated two 1047 potential causes of this drastic degradation of performance by 1048 concentrating on two key differences between the Single Link and the 1049 RTT topologies: the difference in the round-trip times and the degree 1050 of aggregation in a per ingress-egress pair aggregate. 1052 To investigate the effect of the difference in round-trip times, we 1053 also conducted a subset of the experiments described above using the 1054 RTT topology that has the same RTT across all ingress-egress pairs 1055 rather than the range of RTTs in one experiment. We found out that 1056 neither the absolute nor the relative difference in RTT between 1057 different ingress-egress pairs appear to have any visible effect on 1058 the over-load performance or the fairness of both algorithms (we do 1059 not present these results here as their are essentially identical to 1060 those in Table A.4). In view of that and noting that in the RTT 1061 topology we used for these experiments for the SVD traffic, there is 1062 only 1 highly bursty flow per ingress, we believe that the severe 1063 degradation of performance in this topology is directly attributable 1064 to the lack of traffic aggregation on the ingress-egress pair basis. 1065 We also note that even for this highly challenging scenario, it is 1066 possible to find a range of parameters that limit the overadmission 1067 case for SVD traffic to quite a reasonable range of -3% + 10% 1068 (adjusted by the CLE). Luckily, these are the same parameter 1069 settings that work quite well for the other types of traffic tested. 1071 The overall performance on the multiple-bottleneck topology, for all 1072 types of traffic, is comparable to the ones on the SingleLink, just 1073 as shown in the queue-based results. Again, the results for the PLT 1074 topology may appear better than those of the SingleLink in the table 1075 below. As discussed earlier, this is due to the fact that the 1076 bottleneck capacity of the PLT topology in these experiments is 1077 higher than that of the SingleLink and RTT, topologies (2.4Gbps vs 1078 1Gbps), so the bottleneck aggregation is higher for PLT than for both 1079 single bottleneck topologies. The ingress-egress aggregation of the 1080 PLT topology corresponds to that of a SingleLink. 1082 ------------------------------------------------------------------- 1083 | | EWMA Weights |Over| Topo | Type| 1084 | | 0.1 | 0.3 | 0.5 | 0.7 | 0.9 |Load| | | 1085 ------------------------------------------------------------------- 1086 | C 0.0001| -0.99 | 0.09 | 0.24 | 0.41 | 0.43 | | | | 1087 | L 0.001 | 0.02 | 0.37 | 0.43 | 0.46 | 0.45 | 5 | S. | | 1088 | E 0.01 | 1.37 | 1.32 | 1.32 | 1.31 | 1.31 | | Link | | 1089 | ---------------------------------------------------------- | 1090 | T 0.0001| 6.50 | 7.96 | 8.37 | 8.42 | 8.84 | | | | 1091 | H 0.001 | 7.07 | 8.54 | 8.65 | 8.55 | 8.66 | 5 | RTT | CBR | 1092 | R 0.01 | 7.93 | 9.08 | 8.71 | 8.63 | 9.40 | | | | 1093 | S ---------------------------------------------------------- | 1094 | H 0.0001| -1.88 | 0.21 | 0.58 | 0.65 | 0.62 | | | | 1095 | L 0.001 | -0.31 | 0.69 | 0.63 | 0.61 | 0.56 | 5 | PLT | | 1096 | D 0.01 | 2.032 | 1.98 | 1.97 | 1.99 | 1.96 | | | | 1097 ------------------------------------------------------------------- 1098 ------------------------------------------------------------------- 1099 | C 0.0001| -2.95 | -1.39 | -0.63 | 0.23 | 0.78 | | | | 1100 | L 0.001 | -1.51 | -0.23 | 0.44 | 0.63 | 1.39 | 5 | S. | | 1101 | E 0.01 | 1.37 | 2.01 | 2.29 | 2.60 | 2.76 | | Link | | 1102 | ---------------------------------------------------------- | 1103 | T 0.0001| -1.93 | -0.23 | 0.99 | 2.09 | 3.38 | | | | 1104 | H 0.001 | -0.75 | 0.89 | 2.07 | 3.12 | 4.27 | 5 | RTT | VBR | 1105 | R 0.01 | 1.91 | 3.42 | 4.35 | 5.36 | 6.38 | | | | 1106 | S ---------------------------------------------------------- | 1107 | H 0.0001| -3.78 | -0.57 | 0.35 | 1.08 | 1.82 | | | | 1108 | L 0.001 | -1.64 | 0.46 | 1.28 | 1.89 | 2.37 | 5 | PLT | | 1109 | D 0.01 | 1.871 | 2.74 | 3.24 | 3.39 | 3.86 | | | | 1110 ------------------------------------------------------------------- 1111 ------------------------------------------------------------------- 1112 | C 0.0001| -2.37 | 0.00 | 0.79 | 0.83 | 1.07 | | | | 1113 | L 0.001 | -0.64 | 0.67 | 0.79 | 1.04 | 1.08 | 5 | S. | | 1114 | E 0.01 | 1.59 | 1.64 | 1.66 | 1.79 | 2.04 | | Link | | 1115 | ---------------------------------------------------------- | 1116 | T 0.0001| -1.09 | 0.86 | 1.29 | 1.57 | 1.98 | | | | 1117 | H 0.001 | 0.00 | 1.39 | 1.63 | 1.86 | 2.58 | 5 | RTT | VTR | 1118 | R 0.01 | 1.99 | 2.32 | 2.88 | 3.54 | 4.35 | | | | 1119 | S ---------------------------------------------------------- | 1120 | H 0.0001| -1.99 | 0.09 | 0.58 | 0.96 | 1.15 | | | | 1121 | L 0.001 | -0.55 | 0.57 | 1.09 | 1.30 | 1.49 | 5 | PLT | | 1122 | D 0.01 | 2.22 | 2.44 | 2.42 | 2.61 | 2.65 | | | | 1123 ------------------------------------------------------------------- 1124 ------------------------------------------------------------------- 1125 | 0.0001| -10.67|-10.58 | -7.95 | -6.27 | -4.99 | | | | 1126 | 0.001 | -8.67 | -8.04 | -7.61 | -4.37 | -2.89 |0.95| | | 1127 | 0.01 | -4.28 | -2.59 | -4.44 | -2.13 | -2.20 | | S. | | 1128 | C ---------------------------------------------------| Link | | 1129 | L 0.0001| -16.36|-10.24 | -6.50 | -2.17 | 2.74 | | | | 1130 | E 0.001 | -10.54| -5.63 | -2.70 | 0.94 | 3.54 | 5 | | | 1131 | 0.01 | -4.11 | 1.26 | 5.38 | 5.75 | 8.82 | | | | 1132 | ---------------------------------------------------------- | 1133 | T 0.0001| -15.83|-10.35 | -2.96 | 0.17 | 5.42 | | | | 1134 | H 0.001 | -12.82| -7.62 | -0.47 | 2.24 | 6.59 |0.95| | | 1135 | R 0.01 | -6.17 | -0.11 | 2.16 | 5.28 | 10.34 | | | | 1136 | E ---------------------------------------------------| RTT | SVD | 1137 | S 0.0001| -8.51 | 1.86 | 11.14 | 22.51 | 30.24 | | | | 1138 | S 0.001 | -4.80 | 1.49 | 15.35 | 24.56 | 33.96 | 5 | | | 1139 | H 0.01 | 0.56 | 8.26 | 25.71 | 35.63 | 42.72 | | | | 1140 | O ---------------------------------------------------------- | 1141 | L 0.0001| -12.35| -8.73 | -7.46 | -5.97 | -5.95 | | | | 1142 | D 0.001 | -9.06 | -7.66 | -5.99 | -5.19 | -4.77 |0.95| | | 1143 | 0.01 | -5.13 | -4.77 | -4.62 | -3.54 | -3.52 | | | | 1144 | ---------------------------------------------------| PLT | | 1145 | 0.0001| -10.07| -5.05 | -3.17 | 0.75 | 2.138 | | | | 1146 | 0.001 | -7.41 | -3.38 | -0.53 | 1.89 | 5.071 | 5 | | | 1147 | 0.01 | -0.81 | 2.816 | 5.115 | 6.03 | 6.421 | | | | 1148 ------------------------------------------------------------------- 1149 Table A.4. Token bucket admission control performance. 1151 An additional differences in token-bucket case vs the queue-based 1152 admissions in the PLT topology case revealed in our experiments is 1153 that there appears to be a consistent relationship between the 1154 position of the bottleneck link (how far downstream it is) and its 1155 over-admission-percentage. In Table A.5, we show a snapshot of the 1156 behavior with 5 bottleneck topology. Here, the over-admission- 1157 percentage displayed is an average across all 15 experiments with 1158 different [weight, CLE] setting. (We do observe the same behavior in 1159 each of the individual experiment, hence providing a summarized 1160 statistics does not invalidate the results). The data shows the 1161 further downstream the bottleneck is, the more it tends to over- 1162 admit, regardless the type of the traffic. The exact cause of this 1163 phenomenon is yet to be explained, but the effect of it seems to be 1164 insignificant in magnitude, at least in the experiments we ran. 1166 -------------------------------------------------------- 1167 | Traffic | Bottleneck LinkId | Over | 1168 | Type | 1 | 2 | 3 | 4 | 5 | Load | 1169 -------------------------------------------------------- 1170 | CBR | 0.270 | 0.421 | 0.529 | 0.669 | 0.791 | 5 | 1171 |-------------------------------------------------------- 1172 | VBR | 0.152 | 0.512 | 0.715 | 0.901 | 1.169 | 5 | 1173 |-------------------------------------------------------- 1174 | VTR | 0.350 | 0.492 | 0.756 | 0.874 | 1.125 | 5 | 1175 -------------------------------------------------------- 1177 Table A.5 Summarized performance for CBR, VBR and VTR across the 1178 links in the PLT topology for Token Bucket Admission 1180 6. IANA Considerations 1182 This document places no requests on IANA. 1184 7. Security Considerations 1186 TBD 1188 8. References 1190 8.1. Normative References 1192 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1193 Requirement Levels", BCP 14, RFC 2119, March 1997. 1195 8.2. Informative References 1197 [I-D.briscoe-tsvwg-cl-architecture] 1198 Briscoe, B., "An edge-to-edge Deployment Model for Pre- 1199 Congestion Notification: Admission Control over a 1200 DiffServ Region", draft-briscoe-tsvwg-cl-architecture-04 1201 (work in progress), October 2006. 1203 [I-D.briscoe-tsvwg-cl-phb] 1204 Briscoe, B., "Pre-Congestion Notification marking", 1205 draft-briscoe-tsvwg-cl-phb-03 (work in progress), 1206 October 2006. 1208 [I-D.briscoe-tsvwg-re-ecn-border-cheat] 1209 Briscoe, B., "Emulating Border Flow Policing using Re-ECN 1210 on Bulk Data", draft-briscoe-tsvwg-re-ecn-border-cheat-01 1211 (work in progress), June 2006. 1213 [I-D.briscoe-tsvwg-re-ecn-tcp] 1214 Briscoe, B., "Re-ECN: Adding Accountability for Causing 1215 Congestion to TCP/IP", draft-briscoe-tsvwg-re-ecn-tcp-03 1216 (work in progress), October 2006. 1218 [I-D.davie-ecn-mpls] 1219 Davie, B., "Explicit Congestion Marking in MPLS", 1220 draft-davie-ecn-mpls-01 (work in progress), October 2006. 1222 [I-D.lefaucheur-emergency-rsvp] 1223 Faucheur, F., "RSVP Extensions for Emergency Services", 1224 draft-lefaucheur-emergency-rsvp-02 (work in progress), 1225 June 2006. 1227 Authors' Addresses 1229 Anna Charny 1230 Cisco Systems, Inc. 1231 1414 Mass. Ave. 1232 Boxborough, MA 01719 1233 USA 1235 Email: acharny@cisco.com 1237 Xinyang (Joy) Zhang 1238 Cisco Systems, Inc. and Cornell University 1239 1414 Mass. Ave. 1240 Boxborough, MA 01719 1241 USA 1243 Email: joyzhang@cisco.com 1245 Francois Le Faucheur 1246 Cisco Systems, Inc. 1247 Village d'Entreprise Green Side - Batiment T3 , 1248 400 Avenue de Roumanille, 06410 Biot Sophia-Antipolis, 1249 France 1251 Email: flefauch@cisco.com 1252 Vassilis Liatsos 1253 Cisco Systems, Inc. 1254 1414 Mass. Ave. 1255 Boxborough, MA 01719 1256 USA 1258 Email: vliatsos@cisco.com 1260 Full Copyright Statement 1262 Copyright (C) The IETF Trust (2007). 1264 This document is subject to the rights, licenses and restrictions 1265 contained in BCP 78, and except as set forth therein, the authors 1266 retain all their rights. 1268 This document and the information contained herein are provided on an 1269 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1270 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1271 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1272 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1273 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1274 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1276 Intellectual Property 1278 The IETF takes no position regarding the validity or scope of any 1279 Intellectual Property Rights or other rights that might be claimed to 1280 pertain to the implementation or use of the technology described in 1281 this document or the extent to which any license under such rights 1282 might or might not be available; nor does it represent that it has 1283 made any independent effort to identify any such rights. Information 1284 on the procedures with respect to rights in RFC documents can be 1285 found in BCP 78 and BCP 79. 1287 Copies of IPR disclosures made to the IETF Secretariat and any 1288 assurances of licenses to be made available, or the result of an 1289 attempt made to obtain a general license or permission for the use of 1290 such proprietary rights by implementers or users of this 1291 specification can be obtained from the IETF on-line IPR repository at 1292 http://www.ietf.org/ipr. 1294 The IETF invites any interested party to bring to its attention any 1295 copyrights, patents or patent applications, or other proprietary 1296 rights that may cover technology that may be required to implement 1297 this standard. Please address the information to the IETF at 1298 ietf-ipr@ietf.org. 1300 Acknowledgment 1302 Funding for the RFC Editor function is provided by the IETF 1303 Administrative Support Activity (IASA).