idnits 2.17.1 draft-charny-pcn-single-marking-00.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 on line 1018. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1029. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1036. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1042. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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 (October 15, 2006) is 6403 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 956, but no explicit reference was found in the text == Unused Reference: 'I-D.lefaucheur-emergency-rsvp' is defined on line 965, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-briscoe-tsvwg-cl-architecture-03 == Outdated reference: A later version (-03) exists of draft-briscoe-tsvwg-cl-phb-02 == Outdated reference: A later version (-09) exists of draft-briscoe-tsvwg-re-ecn-tcp-02 == Outdated reference: A later version (-01) exists of draft-davie-ecn-mpls-00 Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Charny 3 Internet-Draft F. Le Faucheur 4 Intended status: Standards Track V. Liatsos 5 Expires: April 18, 2007 Cisco Systems, Inc. 6 J. Zhang 7 Cisco Systems, Inc. and Cornell 8 University 9 October 15, 2006 11 Pre-Congestion Notification Using Single Marking for Admission and Pre- 12 emption 13 draft-charny-pcn-single-marking-00.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 April 18, 2007. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 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 [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. Background and Motivation . . . . . . . . . . . . . . . . 4 72 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 73 2. The Single Marking Approach . . . . . . . . . . . . . . . . . 6 74 2.1. High Level description . . . . . . . . . . . . . . . . . . 6 75 2.2. Operation at the PIN . . . . . . . . . . . . . . . . . . . 7 76 2.3. Operation at the Egress PEN . . . . . . . . . . . . . . . 7 77 2.4. Operation at the Ingress PEN . . . . . . . . . . . . . . . 7 78 2.4.1. Admission Decision . . . . . . . . . . . . . . . . . . 8 79 2.4.2. Pre-emption Decision . . . . . . . . . . . . . . . . . 8 80 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 3.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 3.2. Tradeoffs and Issues . . . . . . . . . . . . . . . . . . . 10 83 3.2.1. Restrictions on Pre-emption-to-admission Thresholds . 10 84 3.2.2. Performance Implications and Tradeoffs . . . . . . . . 10 85 3.2.3. Effect on Proposed Anti-cheating Mechanisms . . . . . 11 86 3.2.4. Standards Implications . . . . . . . . . . . . . . . . 11 87 4. Performance Evaluation Comparison . . . . . . . . . . . . . . 11 88 4.1. Relationship to other drafts . . . . . . . . . . . . . . . 11 89 4.2. Limitations, Conclusions and Direction for Future Work . . 11 90 4.2.1. Limitations . . . . . . . . . . . . . . . . . . . . . 11 91 4.2.2. High Level Conclusions . . . . . . . . . . . . . . . . 12 92 4.2.3. Future work . . . . . . . . . . . . . . . . . . . . . 13 93 5. Appendix A: Simulation Details . . . . . . . . . . . . . . . 13 94 5.1. Network and Signaling Model . . . . . . . . . . . . . . . 13 95 5.2. Traffic Models . . . . . . . . . . . . . . . . . . . . . . 14 96 5.2.1. CBR Voice (CBR) . . . . . . . . . . . . . . . . . . . 15 97 5.2.2. VBR Voice (VBR) . . . . . . . . . . . . . . . . . . . 15 98 5.2.3. High Rate ON-OFF traffic with Video-like Mean and 99 Peak Rates ("Video") . . . . . . . . . . . . . . . . . 15 100 5.3. Parameter Settings . . . . . . . . . . . . . . . . . . . . 15 101 5.3.1. Queue-based settings . . . . . . . . . . . . . . . . . 15 102 5.3.2. Token Bucket Settings . . . . . . . . . . . . . . . . 16 103 5.4. Simulation Details . . . . . . . . . . . . . . . . . . . . 16 104 5.4.1. Queue-based Results . . . . . . . . . . . . . . . . . 16 105 5.4.2. Token Bucket-based Results . . . . . . . . . . . . . . 18 106 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 107 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 108 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 109 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22 110 8.2. Informative References . . . . . . . . . . . . . . . . . . 22 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 112 Intellectual Property and Copyright Statements . . . . . . . . . . 24 114 1. Introduction 116 1.1. Background and Motivation 118 Pre-Congestion Notification [I-D.briscoe-tsvwg-cl-architecture] 119 approach proposes to use an Admission Control mechanism to limit the 120 amount of real-time PCN traffic to a configured level during the 121 normal operating conditions, and to use a Pre-emption mechanism to 122 tear-down some of the flows to bring the PCN traffic level down to a 123 desirable amount during unexpected events such as network failures, 124 with the goal of maintaining the QoS assurances to the remaining 125 flows. In [I-D.briscoe-tsvwg-cl-architecture], Admission and Pre- 126 emption use different two different markings and two different 127 metering mechanisms in the internal nodes of the PCN region. 128 Admission Control algorithms for variable-rate real-time traffic such 129 as video have traditionally been based on the observation of the 130 queue length, and hence re-using these technques and ideas in the 131 context of pre-congestion notification is highly attractive, and 132 motivated the virtual-queue-based marking and metering approach 133 specified in [I-D.briscoe-tsvwg-cl-architecture] for Admission. On 134 the other hand, for Pre-emption, it is desirable to know how much 135 traffic needs to be pre-empted, and that in turn motivates rate-based 136 Pre-emption metering. This provides some motivation for employing 137 different metering algorithm for Admission and for Preemption. 139 Furthermore, it is frequently desirable to trigger Pre-emption at a 140 substantially higher traffic level than the level at which no new 141 flows are to be admitted. There are multiple reasons for the 142 requirement to enforce a different Admission Threshold and Preemption 143 Threshold. These include, for example: 145 o End-users are typically more annoyed by their established call 146 dying than by getting a busy tone at call establishment. 148 o There are often very tight (possibly legal) obligations on network 149 operators to not drop established calls. 151 o Voice Call Routing often has the ability to route/establish the 152 call on another network (e.g., PSTN) if it is determined at call 153 establishment that one network (e.g., packet network) can not 154 accept the call. Therefore, not admitting a call on the packet 155 network at initial establishment may not impact the end-user. In 156 contrast, it is usually not possible to reroute an established 157 call onto another network mid-call. This means that call 158 Preemption can not be hidden to the end-user. 160 o Preemption is typically useful in failure situations where some 161 loads get rerouted thereby increasing the load on remaining links. 163 Because the failure may only be temporary, the operator may be 164 ready to tolerate a small degradation during the interim failure 165 period. 167 o A congestion notification based Admission scheme has some inherent 168 inaccuracies because of its reactive nature and thus may 169 potentially over admit in some situations (such as burst of calls 170 arrival). If the Preemption scheme reacted at the same Threshold 171 as the Admission Threshold, calls may get routinely dropped after 172 establishment because of over admission, even under steady state 173 conditions. 175 These considerations argue for meetering for Admission and Pre- 176 emption at different traffic levels and hence, implicitly, for 177 different markings and metering schemes. 179 Different marking schemes require different codepoints. Thus, such 180 separate markings consume valuable real-estate in the packet header, 181 especially scarce in the case of MPLS Pre-Congestion Notification 182 [I-D.davie-ecn-mpls] . Furthermore, two different measurement/ 183 metering techniques involve additional complexity in the datapath of 184 the internal routers of the PCN domain. 186 To this end, [I-D.briscoe-tsvwg-cl-architecture] proposes an 187 approach, referred to as implicit pre-emption marking, that does not 188 require separate pre-emption marking. However, it does require two 189 separate measurement schemes: one measurement for Admission and 190 another measurement for Preemption/Dropping. Furthermore, this 191 approach mandates that the configured preemption rate be set to a 192 drop rate. This approach effectively uses dropping as the way to 193 convey information about how much traffic can fit under the 194 preemption limit, instead of using a separate preemption marking. 195 This is a significant restriction in that it results in preemption 196 only taking effect once packets actually get dropped. 198 This document presents an approach that allows the use of a single 199 PCN marking and a single metering technique at the internal devices 200 without requiring that the dropping and pre-emption thresholds be the 201 same. This document also investigates some of the tradeoffs 202 associated with this approach. 204 1.2. Terminology 206 o Pre-Congestion Notification (PCN): two algorithms that determine 207 when a PCN-enabled router Admission Marks and Pre- emption Marks a 208 packet, depending on the traffic level. 210 o Admission Marking condition- the traffic level is such that the 211 router Admission Marks packets. The router provides an "early 212 warning" that the load is nearing the engineered admission control 213 capacity, before there is any significant build-up in the queue of 214 packets belonging to the specified real-time service class. 216 o Pre-emption Marking condition- the traffic level is such that the 217 router Pre-emption Marks packets. The router warns explicitly 218 that pre-emption may be needed. 220 o Configured-admission-rate - the reference rate used by the 221 admission marking algorithm in a PCN-enabled router. 223 o Configured-pre-emption-rate - the reference rate used by the pre- 224 emption marking algorithm in a PCN-enabled router. 226 o CLE - congestion level estimate computed by the egress node by 227 estimating as the fraction of admission-marked packets it 228 receives. 230 o PIN - PCN internal node - an internal node in the PCN region. 232 o PEN - PCN edge node - an ingree or egress edge node of the PCN 233 region. 235 2. The Single Marking Approach 237 2.1. High Level description 239 The proposed approach is based on several simple ideas: 241 o Replace virtual-queue-based marking for Admission Control by 242 excess rate marking: 244 * meter traffic exceeding the Admission Threshold and mark excess 245 traffic (e.g. using a token bucket with the rate configured to 246 Admission Rate Threshold) 248 * at the edges, stop admitting traffic when the fraction of 249 marked traffic for a given edge-to-edge aggregate exceeds a 250 configured threshold (e.g. stop admitting when 3% of all 251 traffic in the edge-to-edge aggregate received at the ingress 252 is marked) 254 o Impose a PCN-region-wide constraint on the ratio between the 255 Admission threshold on a link and Pre-emption threshold on that 256 link (e.g. pre-emption threshold is 20% higher than Admission 257 threshold on all links in the PCN region) 259 o The edge PCN device determines whether Pre-emption level is 260 reached anywhere in the network by measuring the amount of 261 unmarked traffic (assuming the marked traffic actually is above 262 the threshold triggering blocking admission), i.e. the traffic 263 that did not get admission marked. This is analogous to the 264 notion of sustainable pre-emption rate in 265 [I-D.briscoe-tsvwg-cl-architecture] . 267 The remaining part of this section gives more detailed of a possible 268 operation of the system. 270 2.2. Operation at the PIN 272 The PCN Internal Node (PIN) meters the aggregate PCN traffic and 273 marks the excess rate. A number of implementations are possible to 274 achieve that. A token bucket implementation is particularly 275 attractive because of its relative simplicity, and even more so 276 because a token bucket implementation is readily available in the 277 vast majority of existing equipment. The rate of the token bucket is 278 configured to correspond to the target Admission rate, and the depth 279 of the token bucket can be configured by an operator based on the 280 desired tolerance to PCN traffic burstiness. 282 Note that no preemption threshold is explicitly configured at the 283 PIN, and the PIN does nothing at all to enforce it or mark traffic 284 based on Pre-emption threshold. 286 2.3. Operation at the Egress PEN 288 The PCN Egress Node (PEN) measures the rate of both marked and 289 unmarked traffic on a per-ingress PEN basis, and reports to the 290 ingress PEN two values: the rate of unmarked traffic from this 291 ingress PEN, which we deem Sustainable Admission Rate and the 292 Congestion Level Estimate (CLE), which is the fraction of the marked 293 traffic received from this ingress PEN. Note that Sustainable 294 Admission Rate is analogous to the sustainable pre-emption rate of 295 [I-D.briscoe-tsvwg-cl-architecture], except in this case it is based 296 on the admission threshold rather than pre-emption threshold, while 297 the CLE is exactly the same as that of 298 [I-D.briscoe-tsvwg-cl-architecture]. The details of the rate 299 measurement are outside the scope of this draft. 301 2.4. Operation at the Ingress PEN 302 2.4.1. Admission Decision 304 Just as in [I-D.briscoe-tsvwg-cl-architecture], the admission 305 decision is based on the CLE. The ingress PEN stops admission of new 306 flows if the CLE is above a pre-defined threshold (e.g. 3%). Note 307 that although the logic of the decision is exactly the same as in the 308 case of [I-D.briscoe-tsvwg-cl-architecture], the detailed semantics 309 of the marking is different. This is because the marking used for 310 admission in this proposal reflects the excess rate over the 311 admission threshold, while in the marking is based on exceeding a 312 virtual queue threshold. Notably, in the current proposal, if the 313 average sustained rate of admitted traffic is 5% over the admission 314 threshold, then 5% of the traffic is expected to be marked, whereas 315 in the context of [I-D.briscoe-tsvwg-cl-architecture] a steady 5% 316 overload should eventually result in 100% of all traffic being 317 admission marked. A consequence of this is that for smooth traffic, 318 the approach presented here will not mark any traffic at all until 319 the rate of the traffic exceeds the configured admission threshold by 320 the amount corresponding to the chosen CLE threshold. At first 321 glance this may seem to result in a violation of the pre-congestion 322 notification premise that attempts to stop admission before the 323 desired traffic level is reached. However, in reality one can simply 324 embed the CLE level into the desired configuration of the admission 325 threshold. That is, if a certain rate X is the actual target 326 admission threshold, then one should configure the rate of the 327 metering device (e.g. the rate of the token bucket) to X-y where y 328 corresponds to the level of CLE that would trigger admission blocking 329 decision. A more important distinction is that virtual-queue based 330 marking reacts to short-term busrtiness of traffic, while the excess- 331 rate based marking is only capable of reacting to rate violations at 332 the timescale chosen for rate measument. Whether this distinction is 333 sufficiently important for the case when no actual queuing is 334 expected even if the virtual queue is full is an open question, which 335 we attempt to start answering in the performance evaluation presented 336 at the end of this draft. 338 2.4.2. Pre-emption Decision 340 When the ingress observes a non-zero CLE and Sustainable Admission 341 Rate Ra, it first computes the Sustainable Pre-Emption rate Rp by 342 simply multiplying Ra by the system-wide constant u, where u is the 343 system-wide ratio between pre-emption and admission thresholds on all 344 links in the PCN domain: Rp = Ra*u. The ingress PEN then performs 345 exactly the same operation as is proposed in 346 [I-D.briscoe-tsvwg-cl-architecture] with respect to Rp, namely, it 347 pre-empts the appropriate number of flows to ensure that the rate of 348 traffic it sends to the corresponding egress PEN does not exceed the 349 sustainable pre-emption rate Rp. Just as in the case of 351 [I-D.briscoe-tsvwg-cl-architecture], an implementation may decide to 352 slow down the pre-emption process by preempting fewer flows than is 353 necessary to cap its traffic to Rp by employing a variety of 354 techniques such as safety factors or hysteresis. In summary, the 355 operation of pre-emption at the ingress PEN is identical to that of 356 [I-D.briscoe-tsvwg-cl-architecture], with the only exception that the 357 sustainable pre-emption rate is computed from the sustainable 358 admission rate rather than derived from a separate marking. This is 359 enabled by imposing a system-wide restriction on the pre-emption-to- 360 admission thresholds ratio and changing the semantics of the 361 admission marking. 363 3. Discussion 365 3.1. Benefits 367 The key benefits of using a single metering/marking scheme for both 368 Admission and Preemption presented in this document are summarized 369 below: 371 o Reduced implementation requirements on core routers due to a 372 single metering implementation instead of two different ones. 374 o Ease of use on existing hardware: given that the proposed approach 375 is particularly amenable to a token bucket implementation, the 376 availability of token buckets on virtually all commercially 377 available routers makes this approach especially attractive. 379 o Reduced number of codepoints which need to be conveyed in the 380 packet header. If the PCN-bits used in the packets header to 381 convey the congestion notification information are the ECN-bits in 382 an IP core and the EXP-bits in an MPLS core, as is currently 383 proposed in [put marking draft reference here] and 384 [I-D.davie-ecn-mpls], those are very expensive real-estate. The 385 current proposals need 5 codepoints, which is especially important 386 in the context of MPLS where there is only a total of 8 EXP 387 codepoints which must also be shared with Diffserv. Eliminating 388 one codepoint considerably helps. 390 o A possibility of using a token-bucket-, excess-rate- based 391 implementation for admission provides extra flexibility for the 392 choice of an admission mechanism, even if two separate markings 393 and thresholds are used. 395 3.2. Tradeoffs and Issues 397 While the benefits of the proposed approach are attractive, there are 398 several issues and tradeoffs that need to be carefully considered. 400 3.2.1. Restrictions on Pre-emption-to-admission Thresholds 402 An obvious restriction necessary for the single-marking approach is 403 that the ratio of 9implicit) pre-emption and admission thresholds 404 remains the same on all links in the PCN region. While clearly a 405 limitation, this does not appear to be particularly crippling, and 406 does not appear to outweigh the benefits of reducing the overhead in 407 the router implementation and savings in codepoints. 409 3.2.2. Performance Implications and Tradeoffs 411 Replacement of a relatively well-studied queue-based measurement- 412 based admission control approach by a cruder excess-rate measurement 413 technique raises a number of algorithmic and performance concerns 414 that need to be carefully evaluated. For example, a token-bucket 415 excess rate measurement is expected to be substantially more 416 sensitive to traffic burstiness and parameter setting, which may have 417 a significant effect in the case of lower levels of traffic 418 aggregation, especially for variable-rate traffic such as video. In 419 addition, the appropriate timescale of rate measurement needs to be 420 carefully evaluated, and in general it depends on the degree of 421 expected traffic variability which is frequently unknown. 423 In view of that, an initial performance comparison of the token- 424 bucket based measurement is presented in the following section. 425 Within the constraints of this preliminary study, the performance 426 tradeoffs observed between the queue-based technique suggested in 427 [I-D.briscoe-tsvwg-cl-architecture] and a simpler token-bucket-based 428 excess rate measurement do not appear to be a cause of substantial 429 concern for cases when traffic aggregation is reasonably high at the 430 bottleneck links as well as on a per ingress-egress pair basis. 431 Details of the simulation study, as well as additional discussion of 432 its implications are presented in section 4. 434 Also, one mitigating consideration in favor of the simpler mechanism 435 is that in a typical DiffServ environment, the real-time traffic is 436 expected to be served at a higher priority and/or the target 437 admission rate is expected to be substantially below the speed at 438 which the real-time queue is actually served. If these assumptions 439 hold, then there is some margin of safety for an admission control 440 algorithm, making the requirements for admission control more 441 forgiving to bounded errors - see additional discussion in section 4. 443 Note that an implication of the above that even if two markings and 444 two metering mechanisms are used, these consideration may imply that 445 an excess-rate token bucket implementation of admission metering and 446 marking may be feasible, which could be a benefit for existing 447 equipment routinely supporting a token-bucket implementation. 449 3.2.3. Effect on Proposed Anti-cheating Mechanisms 451 Replacement of the queue-based admission control mechanism of 452 [I-D.briscoe-tsvwg-cl-architecture] by an excess-rate based admission 453 marking changing the semantics of the pre-congestion marking, and 454 consequently interfereres with mechanisms for cheating detection 455 discussed in [I-D.briscoe-tsvwg-re-ecn-border-cheat]. Implications 456 of excess-rate based marking on the anti-cheating mechanisms need to 457 be considered. 459 3.2.4. Standards Implications 461 The change of the meaning of admission marking for pre-congestion 462 notification from the queue-based to excess-rate marking poses a 463 question of coexistence of devices having different interpretation of 464 admissions marking (and hence different metering and marking 465 mechanisms in the core. The question of how and if the two 466 mechanisms can co-exist in one PCN region has obvious impact on 467 standardization efforts, and needs to be carefully considered. 469 4. Performance Evaluation Comparison 471 4.1. Relationship to other drafts 473 Initial simulation results of admission and pre-emption mechanisms of 474 [I-D.briscoe-tsvwg-cl-architecture] were reported in 475 [I-D.briscoe-tsvwg-cl-phb]. A follow-up study of these mechanisms is 476 presented in a companion draft 477 draft-zhang-cl-performance-evaluation-00.txt. The current draft 478 concentrates on a preliminary performance comparison of the admission 479 control mechanism of [I-D.briscoe-tsvwg-cl-phb] and the token-bucket- 480 based admission control described in section 2 of this draft. 482 4.2. Limitations, Conclusions and Direction for Future Work 484 4.2.1. Limitations 486 Due to time constraints, the study performed so far was limited to a 487 single bottlneck case. The key questions that have been investigated 488 are the comparative sensitivity of the two schemes to parameter 489 settings and the effect of traffic burstiness and of the degree of 490 aggregation on a per ingress-egress pair on the performance of the 491 admission control algorithms under study. The study is limited to 492 the case where there is no packet loss. While this is a reasonable 493 initial assumption for an admission control algorithm that is 494 supposed to maintain the traffic level significantly below the 495 service capacity of the corresponding queue, nevertheless future 496 study is necessary to evaluate the effect of packet loss. 498 This draft does not discuss performance of the pre-emption algorithm, 499 as it does not differ between the approach described in this draft 500 and that of draft [I-D.briscoe-tsvwg-cl-architecture]. 502 4.2.2. High Level Conclusions 504 The results of this (preliminary) study indicate that there is some 505 potential that a reasonable complexity/performance trafdeoff may be 506 viable for the choice of admission control algorithm. In turn, this 507 suggests that using a single codepoint and metering technique for 508 admission and pre-emption may be a viable option warranting further 509 investigation. 511 The key high-level conclusions of the simulation study comparing the 512 performance of queue-based and token-based admission control 513 algorithms are summarized below: 515 1. At reasonable level of aggregation at the bottleneck and per 516 ingress-egress pair traffic, both algorithms perform reasonably 517 well for the range of traffic models considered (see section 4.3. 518 for detail). 520 2. Both schemes are stressed for small levels of ingress-egress pair 521 aggregation levels (e.g. a single video-like bursty VBR flow per 522 ingress-egress pair). However, while the queue-based scheme 523 results in tolerable performance even at low levels of per 524 ingress-egress aggregation, the token-bucket-based scheme is 525 substantially more sensitive to parameter setting than the queue- 526 based scheme, and its performance for the high rate bursty 527 "video-like" traffic with low levels of ingress-egress 528 aggregation is quite poor unless parameters are chosen carefully 529 to curb the error. 531 3. Even for small per ingress-egress pair aggregation, reasonable 532 performance across a range of traffic models can be obtained for 533 both algorithms (with a narrower range of parameter setting for 534 the token-bucket based approach) . 536 4. The absolute value of round-trip time (RTT) or the RTT difference 537 between different ingress-egress pair within the range of 538 continental propagation delays does not appear to have a visible 539 effect on the performance of both algorithms. 541 4.2.3. Future work 543 This study is but the first step in performance evaluation of the 544 token-bucket based admission control. Further evaluation should 545 include a range of investigation, including the following: 547 o a study in the multiple bottleneck case 549 o a wider range of topologies and traffic matrices 551 o fairness issues (how different ingress-egress pairs get access to 552 bottleneck bandwidth) 554 o interactions between admission control and preemption 556 o effect of loss of marked packets 558 o much more 560 5. Appendix A: Simulation Details 562 5.1. Network and Signaling Model 564 Simulations presented in this document are limited to a single 565 bottleneck case. The network is modeled as either Single Link or 566 Multi Link Network shown in the figures below. (We termed the latter 567 "RTT"). 569 A --- B 571 Figure A.1: Simulated Single Link Network. 573 A 575 \ 577 B - D - F 579 / 581 C 583 Figure A.2: Simulated Multi Link Network. 585 Figure A.1 shows a single link between an ingress and an egress node, 586 all flows enter at node A and depart at node B. In Figure A.2, A set 587 of ingresses (A,B,C) connected to an interior node in the network 588 (D). The number of ingresses varied in different simulation 589 experiments in the range of 2-100. All links have generally 590 different propagation delays, in the range 1ms - 100 ms. This node D 591 in turn is connected to the egress (F). In this topology, different 592 sets of flows between each ingress and the egress converge on the 593 single link D-F, where pre-congestion notification algorithm is 594 enabled. The capacities of the ingress links are not limiting, and 595 hence no PCN is enable on those. The bottleneck link D-F is modeled 596 with a 10ms propagation delay in all simulations. Therefore the 597 range of round-trip delays in the experiments is from 22ms to 220ms. 598 Our simulations concentrated primarily on capacities of 'bottleneck' 599 links with sufficient aggregation - OC3 for voice and for "video- 600 like" traffic, up to 1 Gbps. In the simulation model, a call 601 requests arrive at the ingress and immediately sends a message to the 602 egress. The message arrives at the egress after the propagation time 603 plus link processing time (but no queuing delay). When the egress 604 receives this message, it immediately responds to the ingress with 605 the current Congestion-Level-Estimate. If the Congestion-Level- 606 Estimate is below the specified CLE-threshold, the call is admitted, 607 otherwise it is rejected. An admitted call sends packets according 608 to one of the chosen traffic models for the duration of the call (see 609 next section). Propagation delay from source to the ingress and from 610 destination to the egress is assumed negligible and is not modeled. 612 5.2. Traffic Models 614 Three types of traffic were simulated (CBR voice, on-off traffic 615 approximating voice with silence compression, and on-off traffic with 616 higher peak and mean rates (we termed the latter "video-like" as the 617 chosen peak and mean rate was similar to that of an mpeg video 618 stream, although no attempt was made to match any other parameters of 619 this traffic to those of a video stream). The distribution of flow 620 duration was chosen to be exponentially distributed with mean 2min, 621 regardless of the traffic type. In most of the experiments flows 622 arrived according to a Poisson distribution with mean arrival rate 623 chosen to achieve a desired amount of overload over the configured- 624 admission-limit in each experiment. Overloads in the range 2x to 5x 625 and underload with 0.95x have been investigated. For on-off traffic, 626 on and off periods were exponentially distributed with the specified 627 mean. Traffic parameters for each flow are summarized below: 629 5.2.1. CBR Voice (CBR) 631 o Average rate 64 Kbps 633 o Packet length 160 bytes 635 o packet inter-arrival time 20ms 637 5.2.2. VBR Voice (VBR) 639 o Packet length 160 bytes 641 o Long-term average rate 21.76 Kbps 643 o On Period mean duration 340ms; during the on period traffic is 644 sent with the CBR voice parameters described above 646 o Off Period mean duration 660ms; no traffic is sent during the off 647 period. 649 5.2.3. High Rate ON-OFF traffic with Video-like Mean and Peak Rates 650 ("Video") 652 o Long term average rate 4 Mbps 654 o On Period mean duration 340ms; during the on-period the packets 655 are sent at 12 Mbps (1500 byte packets, packet inter-arrival: 1ms) 657 o Off Period mean duration 660ms 659 5.3. Parameter Settings 661 5.3.1. Queue-based settings 663 All the queue-based simulations were run with the following Virtual 664 Queue thresholds: 666 o virtual-queue-rate: configured admission rate, 1/2 link speed 668 o min-marking-threshold: 5ms at virtual-queue-rate 670 o max-marking-threshold: 15ms at virtual-queue-rate 672 o virtual-queue-upper-limit: 20ms at virtual-queue-rate 674 At the egress, the CLE is computed as an exponential weighted moving 675 average (EWMA) on an interval basis, with 100ms measurement interval 676 chosen in all simulations. We simulated the weight ranging 0.1 to 677 0.9. The CLE threshold is chosen to be 0.05, 0.15, 0.25, and 0.5. 679 5.3.2. Token Bucket Settings 681 The token bucket rate is set to the configured admission rate, which 682 is half of the link speed in all experiments. Token bucket depth 683 ranges from 64 to 512 packets. Our simulation results indicate that 684 depth of token bucket has no significant impact on the performance of 685 the algorithms and hence, in the rest of the section, we only present 686 the result with 64 bucket depth. 688 The CLE is calculated in the same way as in queue-based approach with 689 weights from 0.1 to 0.9. The CLE thresholds are chosen to be 0.0001, 690 0.001, 0.01, 0.05. Note that the meaning of tthe CLE is different 691 for the Token bucket and queue-based algorithms, so there is no 692 direct correspondence between the choice of the CLE thresholds in the 693 two cases. 695 5.4. Simulation Details 697 To evaluate the performance of the algorithms, we recorded the actual 698 admitted load at a granularity of 100ms, from which the mean admitted 699 load over the duration of the simulation run can be computed. We 700 verified that the actual admitted load at any time does not deviate 701 much from the mean admitted load in each experiment by computing the 702 coefficient of variation (CV is consistently 0.06 for CBR, 0.13 for 703 VBR and 0.6 for Video for all experiments). Finally, the performance 704 of the algorithms is evaluated using a metric called over-admission- 705 percentage, which is calculated as a percentage difference between 706 the mean admitted load and the configured admission rate. Given 707 reasonably small deviation of the admitted rate from the mean 708 admitted in the experiments, this seems reasonable. 710 5.4.1. Queue-based Results 712 We found that virtual-queue admission control algorithm works 713 reliably with the range of parameters we simulated, for all three 714 types of traffic. In addition, for both CBR and VBR traffic, the 715 performance is insensitive to the parameters change. Table A.1 716 summarized the over-admission-percentage values from 32 experiments 717 with different [weight, CLE threshold] settings. The overload column 718 represents the ratio of the demand on the bottleneck link to the 719 configured admission threshold. While in our simulations we tested 720 the range of overload from 0.95 to 5, we present here only the 721 results of the endpoints of this overload interval. For the 722 intermediate values of overload the results are even closer to the 723 expected than at the two boundary loads, The statistics show that for 724 CBR and VBR traffic these over-admission-percentage values are rather 725 similar, with the admitted load staying within -2%+2% range of the 726 desired admission threshold, with quite limited variability across 727 the experiments (see the Standard Deviation column) 729 ------------------------------------------------------------------- 730 | Over Admission Perc Stats | Over | Topo | Type | 731 | Min | Median | Mean | Max | SD | Load | | | 732 ------------------------------------------------------------------- 733 | 0.007 | 0.007 | 0.007 | 0.007 | 0 | 0.95 | | | 734 |---------------------------------------------------| S.Link | | 735 | 0.224 | 0.792 | 0.849 | 1.905 | 0.275 | 5 | | | 736 |------------------------------------------------------------| CBR | 737 | 0.008 | 0.008 | 0.008 | 0.008 | 0 | 0.95 | | | 738 |---------------------------------------------------| RTT | | 739 | 0.200 | 0.857 | 0.899 | 1.956 | 0.279 | 5 | | | 740 |------------------------------------------------------------------- 741 | -1.45 | -0.96 | -0.98 | -0.86 | 0.117 | 0.95 | | | 742 |---------------------------------------------------| S.Link | | 743 | -0.07 | 1.507 | 1.405 | 1.948 | 0.421 | 5 | | | 744 |------------------------------------------------------------| VBR | 745 | -1.56 | -0.75 | -0.80 | -0.69 | 0.16 | 0.95 | | | 746 |---------------------------------------------------| RTT | | 747 | -0.11 | 1.577 | 1.463 | 2.199 | 0.462 | 5 | | | 748 ------------------------------------------------------------------- 749 Table A.1 Summarized performance for CBR and VBR across different 750 settings. 752 For Video-like high-rate VBR traffic, the algorithms does show 753 certain sensitivity to the tested parameters. Table A.2 recorded the 754 over-admission-percentage for each combination of weights and CLE 755 threshold. 757 -- ------------------------------------------------------------------ 758 | | EWMA Weights | Over | Topo | 759 | | 0.1 | 0.3 | 0.5 | 0.7 | 0.8 | Load | | 760 -- ------------------------------------------------------------------ 761 | 0.05 | -4.87 | -3.05 | -2.92 | -2.40 | -2.40 | | | 762 | 0.15 | -3.67 | -2.99 | -2.40 | -2.40 | -2.40 | 0.95 | | 763 | 0.25 | -2.67 | -2.40 | -2.40 | -2.40 | -2.40 | | | 764 | C 0.5 | -0.24 | -1.60 | -2.40 | -2.40 | -2.40 | | Single | 765 | L --------------------------------------------------------| Link | 766 | E 0.05 | -4.03 | 2.52 | 3.45 | 5.70 | 5.17 | | | 767 | 0.15 | -0.81 | 3.29 | 6.35 | 6.80 | 8.13 | 5 | | 768 | T 0.25 | 2.15 | 5.83 | 6.81 | 8.62 | 7.95 | | | 769 | H 0.5 | 6.55 | 9.35 | 9.38 | 8.96 | 8.41 | | | 770 | R ------------------------------------------------------------------ 771 | E 0.05 | -11.77 | -8.35 | -5.23 | -2.64 | -2.35 | | | 772 | S 0.15 | -9.71 | -7.14 | -2.01 | -2.21 | -1.13 | 0.95 | | 773 | H 0.25 | -5.54 | -6.04 | -3.28 | -0.88 | -0.27 | | | 774 | O 0.5 | -2.00 | -2.56 | -1.52 | 0.53 | 0.39 | | | 775 | L --------------------------------------------------------| RTT | 776 | D 0.05 | -5.04 | -0.65 | 4.21 | 6.65 | 9.90 | | | 777 | 0.15 | -1.02 | 1.58 | 7.21 | 8.24 | 10.07 | 5 | | 778 | 0.25 | -0.76 | 1.96 | 7.43 | 9.66 | 11.26 | | | 779 | 0.5 | 6.70 | 8.42 | 10.10 | 11.11 | 11.02 | | | 780 -- ------------------------------------------------------------------ 781 Table A.2 Over-admission-percentage for "Video" 783 It follows from these results that while performance is tolerable 784 across the entire range of parameters, choosing the CLE and EWMA 785 weights in the middle of the tested range appear to be more 786 beneficial for the overall performance across the chosen range of 787 overload, assuming the chosen values for the remaining parameters. 788 The high level conclusion that can be drawn from Table A.2. is that 789 (predictably) high peak-to-mean ratio video-like traffic is 790 substantially more stressful to the queue-based admission control 791 algorithm, but a set of parameters exists that keeps the 792 overadmission within about -3% - +10% of the expected load even for 793 the bursty video-like traffic. Note that for vide-like traffic these 794 results hold even though there is no aggregation at all on a per- 795 ingress-egress pair in the chosen RTT topology there is only a single 796 "video" flow per ingress. 798 5.4.2. Token Bucket-based Results 800 Compared to the virtual queue based algorithms, token bucket-based 801 admission control algorithm shows substantially higher sensitivity to 802 the parameter settings for the over-load conditions (overload greater 803 than 1) Under the under-loaded conditions for voice-like CBR and VBR 804 traffic the sensitivity to the tested parameters remains limited for 805 the token-bucket as well (the latter is summarized in Table A.3). 807 ------------------------------------------------------------------- 808 | Over Admission Perc Stats | Load | Topo | Type | 809 | Min | Max | Median | Mean | SD | | | | 810 ------------------------------------------------------------------- 811 | 0.007 | 0.007 | 0.007 | 0.007 | 0 | 0.95 | S.Link | | 812 |------------------------------------------------------------| CBR | 813 | 0.008 | 0.008 | 0.008 | 0.008 | 0 | 0.95 | RTT | | 814 |------------------------------------------------------------------- 815 | -2.00 | -0.95 | -1.02 | -0.78 | 0.268 | 0.95 | S.Link | | 816 |------------------------------------------------------------| VBR | 817 | -2.83 | -1.20 | -1.31 | -0.70 | 0.510 | 0.95 | RTT | | 818 ------------------------------------------------------------------- 819 Table A.3 Summarized performance for CBR and VBR across different 820 settings for under-loaded conditions. 822 Table A.4 shows over-admission-percentage for different settings. It 823 is important to note here that for the token bucket-based admission 824 control no traffic will be marked until the rate of traffic exceeds 825 the configured admission rate by the chosen CLE. As a consequence, 826 even with the ideal performance of the algorithms, the over- 827 admission-percentage will not be 0, rather it is expected to equal to 828 CLE threshold if the algorithm performs as expected. Therefore, a 829 more meaningful metric for the token-based results is actually the 830 over-admission-percentage (listed below) minus the corresponding (CLE 831 threshold * 100). For example, for CLE = 0.05, one would expect that 832 5% overadmission is inherently embedded in the algorithm, with the 833 algorithm by design reacting to 5% overload (or more) only. Hence, 834 with CLE = 0.05 a 10% over-admission in the token-bucket case should 835 be compared to a 5% overadmission in the queue-based algorithm. When 836 comparing the performance of token bucket (with the adjusted over- 837 admission-percentage) to its corresponding virtual queue result, we 838 found that token bucket performs only slightly worse for voice-like 839 CBR and VBR traffic. 841 However the results for Video-like traffic require some additional 842 commentary. Note from the results in Table A.4. that even for video- 843 like traffic, in the Single Link topology the performance of the 844 token-based solution is comparable to the performance of the queue- 845 based scheme in table A.2, (adjusted by the CLE as discussed above). 846 However, for the RTT topology, especially for the larger EWMA 847 weights, the performance for "video" traffic becomes very bad, with 848 up to 48% (adjusted by CLE) over-admission in a high overload 849 situation (5x). We investigated two potential causes of this drastic 850 degradation of performance by concentrating on two key differences 851 between the Single Link and the RTT topologies: the difference in the 852 round-trip times and the degree of aggregation in a per ingress- 853 egress pair aggregate. 855 To investigate the effect of the difference in round-trip times,we 856 also conducted a subset of the experiments described above using the 857 RTT topology that has the same RTT across all ingress-egress pairs 858 rather than the range of RTTs in one experiment. We found out that 859 neither the absolute nor the relative difference in RTT between 860 different ingress-egress pairs appear to have any visible effect on 861 the over-load performance or the fairness of both algorithms (we do 862 not present these results here as their are essentially identical to 863 those in Table A.4). In view of that and noting that in the RTT 864 topology we used for these experiments for the video-like traffic, 865 there is only 1 highly bursty flow per ingress, we believe that the 866 severe degradation of performance in this topology is directly 867 attributable to the lack of traffic aggregation on the ingress-egress 868 pair basis. We also note that even for this highly challenging 869 scenario, it is possible to find a range of parameters that limit the 870 overadmission case for video traffic to quite a reasonable range of 871 -3% + 10% (adjusted by the CLE). Luckily, these are the same 872 parameter settings that work quite well for the other types of 873 traffic tested. 875 -- ------------------------------------------------------------------ 876 | | EWMA Weights | Over | Topo | Type| 877 | | 0.1 | 0.3 | 0.5 | 0.7 | 0.9 | Load | | | 878 -- ------------------------------------------------------------------ 879 | C 0.0001| -0.99 | 0.09 | 0.24 | 0.41 | 0.43 | | | | 880 | L 0.001 | 0.02 | 0.37 | 0.43 | 0.46 | 0.45 | 5 | S. | | 881 | E 0.01 | 1.37 | 1.32 | 1.32 | 1.31 | 1.31 | | Link | | 882 | 0.05 | 5.61 | 5.58 | 5.60 | 5.58 | 5.57 | | | | 883 | T ----------------------------------------------------------- CBR | 884 | H 0.0001| 6.50 | 7.96 | 8.37 | 8.42 | 8.84 | | | | 885 | R 0.001 | 7.07 | 8.54 | 8.65 | 8.55 | 8.66 | 5 | RTT | | 886 | S 0.01 | 7.93 | 9.08 | 8.71 | 8.63 | 9.40 | | | | 887 | 0.05 | 11.01 |10.59 | 10.86 | 10.39 | 10.51| | | | 888 -- ------------------------------------------------------------------ 889 -- ------------------------------------------------------------------ 890 | C 0.0001| -2.95 | -1.39| -0.63 | 0.23 | 0.78 | | | | 891 | L 0.001 | -1.51 | -0.23| 0.44 | 0.63 | 1.39 | 5 | S. | | 892 | E 0.01 | 1.37 | 2.01 | 2.29 | 2.60 | 2.76 | | Link | | 893 | 0.05 | 6.31 | 6.71 | 6.80 | 6.97 | 7.05 | | | | 894 | T ----------------------------------------------------------- VBR | 895 | H 0.0001| -1.93 | -0.23| 0.99 | 2.09 | 3.38 | | | | 896 | R 0.001 | -0.75 | 0.89 | 2.07 | 3.12 | 4.27 | 5 | RTT | | 897 | S 0.01 | 1.91 | 3.42 | 4.35 | 5.36 | 6.38 | | | | 898 | 0.05 | 7.69 | 9.22 | 10.22 | 11.27 | 12.06| | | | 899 -- ------------------------------------------------------------------ 900 -- ------------------------------------------------------------------ 901 | 0.0001| -10.67|-10.58| -7.95 | -6.27 | -4.99| | | | 902 | 0.001 | -8.67 | -8.04| -7.61 | -4.37 | -2.89| 0.95 | | | 903 | 0.01 | -4.28 | -2.59| -4.44 | -2.13 | -2.20| | | | 904 | C 0.05 | -0.24 | -0.66| -1.08 | -0.92 | -0.23| | S. | | 905 | L ----------------------------------------------------| Link | | 906 | E 0.0001| -16.36|-10.24| -6.50 | -2.17 | 2.74 | | | | 907 | 0.001 | -10.54| -5.63| -2.70 | 0.94 | 3.54 | 5 | | | 908 | T 0.01 | -4.11 | 1.26 | 5.38 | 5.75 | 8.82 | | | | 909 | H 0.05 | 6.31 | 10.49| 11.75 | 14.21 | 15.08| | | | 910 | R ----------------------------------------------------------- Video| 911 | E 0.0001| -15.83|-10.35| -2.96 | 0.17 | 5.42 | | | | 912 | S 0.001 | -12.82| -7.62| -0.47 | 2.24 | 6.59 | 0.95 | | | 913 | H 0.01 | -6.17 | -0.11| 2.16 | 5.28 | 10.34| | | | 914 | O 0.05 | 0.52 | 6.14 | 7.34 | 9.32 | 14.07| | | | 915 | L ----------------------------------------------------| RTT | | 916 | D 0.0001| -8.51 | 1.86 | 11.14 | 22.51 | 30.24| | | | 917 | 0.001 | -4.80 | 1.49 | 15.35 | 24.56 | 33.96| 5 | | | 918 | 0.01 | 0.56 | 8.26 | 25.71 | 35.63 | 42.72| | | | 919 | 0.05 | 14.08 | 19.69| 32.50 | 39.55 | 52.28| | | | 920 -- ------------------------------------------------------------------ 921 Table A.4. Token bucket admission control performance. 923 6. IANA Considerations 925 This document places no requests on IANA. 927 7. Security Considerations 929 TBD 931 8. References 933 8.1. Normative References 935 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 936 Requirement Levels", BCP 14, RFC 2119, March 1997. 938 8.2. Informative References 940 [I-D.briscoe-tsvwg-cl-architecture] 941 Briscoe, B., "An edge-to-edge Deployment Model for Pre- 942 Congestion Notification: Admission Control over a 943 DiffServ Region", draft-briscoe-tsvwg-cl-architecture-03 944 (work in progress), June 2006. 946 [I-D.briscoe-tsvwg-cl-phb] 947 Briscoe, B., "Pre-Congestion Notification marking", 948 draft-briscoe-tsvwg-cl-phb-02 (work in progress), 949 June 2006. 951 [I-D.briscoe-tsvwg-re-ecn-border-cheat] 952 Briscoe, B., "Emulating Border Flow Policing using Re-ECN 953 on Bulk Data", draft-briscoe-tsvwg-re-ecn-border-cheat-01 954 (work in progress), June 2006. 956 [I-D.briscoe-tsvwg-re-ecn-tcp] 957 Briscoe, B., "Re-ECN: Adding Accountability for Causing 958 Congestion to TCP/IP", draft-briscoe-tsvwg-re-ecn-tcp-02 959 (work in progress), June 2006. 961 [I-D.davie-ecn-mpls] 962 Davie, B., "Explicit Congestion Marking in MPLS", 963 draft-davie-ecn-mpls-00 (work in progress), June 2006. 965 [I-D.lefaucheur-emergency-rsvp] 966 Faucheur, F., "RSVP Extensions for Emergency Services", 967 draft-lefaucheur-emergency-rsvp-02 (work in progress), 968 June 2006. 970 Authors' Addresses 972 Anna Charny 973 Cisco Systems, Inc. 974 1414 Mass. Ave. 975 Boxborough, MA 01719 976 USA 978 Email: acharny@cisco.com 980 Francois Le Faucheur 981 Cisco Systems, Inc. 982 Village d'Entreprise Green Side - Batiment T3 , 983 400 Avenue de Roumanille, 06410 Biot Sophia-Antipolis, 984 France 986 Email: flefauch@cisco.com 988 Vassilis Liatsos 989 Cisco Systems, Inc. 990 1414 Mass. Ave. 991 Boxborough, MA 01719 992 USA 994 Email: vliatsos@cisco.com 996 Xinyang (Joy) Zhang 997 Cisco Systems, Inc. and Cornell University 998 1414 Mass. Ave. 999 Boxborough, MA 01719 1000 USA 1002 Email: joyzhang@cisco.com 1004 Full Copyright Statement 1006 Copyright (C) The Internet Society (2006). 1008 This document is subject to the rights, licenses and restrictions 1009 contained in BCP 78, and except as set forth therein, the authors 1010 retain all their rights. 1012 This document and the information contained herein are provided on an 1013 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1014 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1015 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1016 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1017 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1018 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1020 Intellectual Property 1022 The IETF takes no position regarding the validity or scope of any 1023 Intellectual Property Rights or other rights that might be claimed to 1024 pertain to the implementation or use of the technology described in 1025 this document or the extent to which any license under such rights 1026 might or might not be available; nor does it represent that it has 1027 made any independent effort to identify any such rights. Information 1028 on the procedures with respect to rights in RFC documents can be 1029 found in BCP 78 and BCP 79. 1031 Copies of IPR disclosures made to the IETF Secretariat and any 1032 assurances of licenses to be made available, or the result of an 1033 attempt made to obtain a general license or permission for the use of 1034 such proprietary rights by implementers or users of this 1035 specification can be obtained from the IETF on-line IPR repository at 1036 http://www.ietf.org/ipr. 1038 The IETF invites any interested party to bring to its attention any 1039 copyrights, patents or patent applications, or other proprietary 1040 rights that may cover technology that may be required to implement 1041 this standard. Please address the information to the IETF at 1042 ietf-ipr@ietf.org. 1044 Acknowledgment 1046 Funding for the RFC Editor function is provided by the IETF 1047 Administrative Support Activity (IASA).