idnits 2.17.1 draft-charny-pcn-comparison-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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1428. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1439. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1446. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1452. 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 : ---------------------------------------------------------------------------- ** There are 15 instances of too long lines in the document, the longest one being 20 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 614 has weird spacing: '...compute sus- ...' == 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 (November 11, 2007) is 6010 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TR437' is mentioned on line 1377, but not defined == Missing Reference: 'Menth' is mentioned on line 1374, but not defined == Unused Reference: 'I-D.briscoe-tsvwg-re-ecn-tcp' is defined on line 1336, but no explicit reference was found in the text == Unused Reference: 'I-D.davie-ecn-mpls' is defined on line 1347, but no explicit reference was found in the text == Unused Reference: 'I-D.lefaucheur-emergency-rsvp' is defined on line 1356, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-babiarz-pcn-3sm-00 == Outdated reference: A later version (-02) exists of draft-babiarz-pcn-explicit-marking-01 == Outdated reference: A later version (-09) exists of draft-briscoe-tsvwg-re-ecn-tcp-04 == Outdated reference: A later version (-03) exists of draft-charny-pcn-single-marking-02 == Outdated reference: A later version (-11) exists of draft-ietf-pcn-architecture-01 == Outdated reference: A later version (-05) exists of draft-westberg-pcn-load-control-01 Summary: 2 errors (**), 0 flaws (~~), 14 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 Cisco Systems, Inc. 4 Intended status: Informational J. Babiarz 5 Expires: May 14, 2008 Nortel 6 M. Menth 7 University of Wuerzburg 8 J. Zhang 9 Cisco Systems, Inc & Cornell 10 University 11 November 11, 2007 13 Comparison of Proposed PCN Approaches 14 draft-charny-pcn-comparison-00.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on May 14, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 Several, sometimes conflicting proposals have been offered for the 48 consideration of the PCN WG regarding PCN internal node and PCN edge 49 node behaviors. Based on the WG charter, the WG needs to make a 50 decision on which of the proposed PCN-interior-node and PCN-boundary- 51 nodes behaviors to endorse. The primary goal of this draft is 52 twofold. First, we attempt to summarize the functional differences 53 between the proposed alternatives. Second, we provide a brief 54 summary of performance evaluation results. Finally we propose a view 55 on how a (parameterized) specification of the PCN-interior-node 56 metering and marking function can be described to enable several of 57 the proposed behaviors. We argue that if this parameterized 58 specification is used for specifying the PCN-interior-node behavior, 59 then it can support a range of behaviors at the PCN-boundary-node. 60 The decision on which of the PCN-boundary-node behaviors to choose 61 can then be considered separately. We also discuss complexities 62 associated with choosing such uniform approach. 64 Requirements Language 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in RFC 2119 [RFC2119]. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. PCN-Interior-Node Metering and Marking Functions . . . . . . . 5 76 2.1. Metering and Marking Types . . . . . . . . . . . . . . . . 5 77 2.2. Metering and Re-Marking of Previously Marked Packets . . . 6 78 2.2.1. Admission Marking . . . . . . . . . . . . . . . . . . 7 79 2.2.2. Termination Marking . . . . . . . . . . . . . . . . . 7 80 2.3. Number of Metering Functions and Marking Codepoints . . . 7 81 3. Dropping Policies . . . . . . . . . . . . . . . . . . . . . . 7 82 4. PCN-Boundary-Node Behaviors . . . . . . . . . . . . . . . . . 8 83 4.1. CL Boundary Behavior . . . . . . . . . . . . . . . . . . . 8 84 4.2. SM Boundary Behavior . . . . . . . . . . . . . . . . . . . 9 85 4.3. 3SM Boundary Behavior . . . . . . . . . . . . . . . . . . 9 86 4.4. Notes on Using Different Boundary Behaviors with 87 Different Marking/Metering Behaviors . . . . . . . . . . . 10 88 5. Informationed Signaled Between the Boundary Nodes . . . . . . 10 89 6. Dealing with ECMP . . . . . . . . . . . . . . . . . . . . . . 11 90 7. Suitability for Probing for Admission Control . . . . . . . . 11 91 8. Configuration Complexity and Configuratio Restrictions . . . . 12 92 9. Functional Comparison Summary . . . . . . . . . . . . . . . . 13 93 10. Other Comparison Criteria . . . . . . . . . . . . . . . . . . 17 94 10.1. Performance Comparison . . . . . . . . . . . . . . . . . . 17 95 11. Unified Descriprion of Marking and Metering Functions . . . . 19 96 12. Difficulties with Allowing Multiple Marking Behaviors . . . . 23 97 13. Security Considerations . . . . . . . . . . . . . . . . . . . 24 98 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 99 15. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 100 15.1. Formulation of the Simple Generalized Metering and 101 Marking Algorithm . . . . . . . . . . . . . . . . . . . . 24 102 15.2. VQ Formulation of the Complex Generalized Metering and 103 Marking Algorithm . . . . . . . . . . . . . . . . . . . . 26 104 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 105 16.1. Normative References . . . . . . . . . . . . . . . . . . . 29 106 16.2. Informative References . . . . . . . . . . . . . . . . . . 29 107 16.3. References . . . . . . . . . . . . . . . . . . . . . . . . 31 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 109 Intellectual Property and Copyright Statements . . . . . . . . . . 33 111 1. Introduction 113 1.1. Terminology 115 This draft uses the terminology defined in 116 [I-D.ietf-pcn-architecture] 118 1.2. Introduction 120 A number of seemingly diverse approaches have been presented in the 121 context of the work in the PCN WG, encompassing both the PCN- 122 interior-node and PCN-boundary-node node behaviors. The goal of this 123 informational draft is to provide a functional comparison of several 124 candidate approaches for PCN behaviors. We refer the reader to 125 [I-D.ietf-pcn-architecture] for an architectural overview of PCN. 127 The first draft of this document concentrates on the CL approach 128 proposed in [I-D.briscoe-tsvwg-cl-architecture] , the 3SM approach 129 described in [I-D.babiarz-pcn-3sm] , and the Single-Marking (SM) 130 approach proposed in [I-D.charny-pcn-single-marking]. The approach 131 proposed in [I-D.westberg-pcn-load-control] is not covered in the 132 initial version of this draft, pending clarifications on the open 133 questions regarding the details of the algorithms described in that 134 draft. 136 At the time of writing of this draft, several performance studies 137 have been undertaken and are on-going. The studies performed in 138 [I-D.zhang-pcn-performance-evaluation] and 139 [I-D.charny-pcn-single-marking] provide a side-by-side comparison of 140 performance of the CL and SM proposals. A performance evaluation of 141 the 3SM approach was reported in [I-D.babiarz-pcn-explicit-marking] 142 and [TR437]. However, due to a number of differences in the 143 experimental setups in different simulation studies, a side-by-side 144 performance comparison between 3SM and the other two approaches is 145 not fully possible at this point. Therefore, we present only a short 146 overview of some of the performance evaluation results where 147 possible. 149 We then argue that a unified (parameterized) formulation of the 150 metering and marking behavior at the PCN-interior-nodes can be 151 defined. Thus defined unified PCN-interior-node behavior may support 152 multiple PCN-boundary-node behaviors, and hence in principle can be 153 used in a variety of environments. We also discuss some of the 154 tradeoffs and additional complexities associated with such unified 155 PCN-interior-node behavior definition. 157 Sections 2-8 provide an overview of the three proposals, followed by 158 a summary of functional differences between the proposals in Section 159 9. Section 10 briefly covers other comparison criteria not covered 160 in this draft, including a brief summary of performance evaluation 161 efforts as of the time of writing of this document. Section 11 162 provides a unified description of admission and termination functions 163 of the PCN-interior-node covering all three proposals of CL, SM and 164 3SM, followed by a brief discussion of the tradeoffs associated with 165 such unified definition in Section 12. 167 2. PCN-Interior-Node Metering and Marking Functions 169 This section provides a high level functional comparison of the 170 metering and marking functions at the PCN-interior-node. For more 171 detail, please see [I-D.briscoe-tsvwg-cl-phb], 172 [I-D.charny-pcn-single-marking], and [I-D.babiarz-pcn-3sm]. 174 2.1. Metering and Marking Types 176 Metering functions are defined in different proposals via the notions 177 of Token Bucket (TB) or Virtual Queue (VQ). These two formulations 178 are equivalent in the sense that each one can be implemented via the 179 other with appropriate settings. They may count packet or bytes. 180 The marking functions differ with respect to how the queue length of 181 the Q or the fill state of the TB is used which has a direct 182 influence on the marking result. The following are the marking 183 behaviours used in [I-D.briscoe-tsvwg-cl-phb], 184 [I-D.charny-pcn-single-marking] and [I-D.babiarz-pcn-3sm]. 186 o Excess-rate-marking marks packets which exceed the configured 187 rate. In the TB formulation, the packets are marked when the 188 arriving packet does not find enough tokens in the token bucket 189 (and the marked packet does not consume tokens from the TB). In 190 the VQ formulation, the packets are marked when the arriving 191 packet would exceed the configured maximum size of the VQ (and the 192 marked packet is not added to the Q). These two formulations are 193 equivalent with the same rates of the TB and VQ, and the depth of 194 the TB numerically equal to the maximum size of the Q. This is the 195 marking used for termination in CL, and for both admission and 196 termination in SM. 198 o Excess-rate-marking-with-marking-frequency-reduction is similar to 199 the Excess-rate-marking in the sense that it also marks packets 200 which do not find tokens in the TB (in the TB formulation), or 201 would exceed the maximum size of the VQ (in the VQ formulation). 202 However, to reduce the number of marked packets, whenever a packet 203 is marked a certain amount of tokens are added to the TB (in the 204 TB formulation) or the same number of bytes is removed from the 205 queue of the VQ (in the VQ formulation). This is the marking used 206 for termination in 3SM. 208 o Ramp-marking is defined as follows. In the VQ formulation, two VQ 209 thresholds are defined (below the maximum VQ size). Packets are 210 marked with a certain probability depending on the VQ size at the 211 time of the packet arrival. This probability is 0 for VQ queue 212 length from 0 to a lower VQ threshold, it rises linearly from 0 to 213 1 between the lower and a upper VQ threshold, and it is 1 above 214 the upper VQ threshold. As a result, no packets are marked when 215 the queue length is below the lower VQ threshold, a few packets 216 are marked when the queue length is between the lower and the 217 upper VQ thresholds, and all packets are marked when the queue 218 length is above the upper VQ threshold. In the equivalent TB 219 formulation, two additional TB fill thresholds (called the lower 220 and upper TB thresholds, both not exceeding the TB depth) are 221 defined . The packers are marked with the probability 1 for a TB 222 fill state from 0 to a lower TB threshold. The probability 223 decreases linearly from 1 to 0 between the lower and upper TB 224 thresholds, and it is 0 above the upper TB threshold. As a 225 result, all packets are marked when the fill state is below the 226 lower threshold, a few packets are marked when the fill state is 227 between the lower and the upper threshold, and no packets are 228 marked above the upper threshold. This is the marking described 229 in [I-D.briscoe-tsvwg-cl-phb] (in the VQ formulation) where it is 230 used for admission. 232 o Threshold-marking marks packets that make the queue length of the 233 VQ exceed a certain threshold which is lower than the queue size. 234 As a result, all packets are marked when the metered traffic 235 exceeds the VQ rate. In the equivalent TB formulation, Threshold- 236 marking marks packets that make the number of tokens in the TB 237 fall below a certain threshold which is larger than zero. As a 238 result, all packets are marked when the metered traffic exceeds 239 the TB rate. The VQ and TB formulations are equivalent with the 240 VQ of rate R, maximum size S and VQ threshold T, and TB with rate 241 R, depth B and threshold T, and TB threshold B-T. Threshold- 242 marking s a special case of Ramp marking when the lower and the 243 upper (TB or Q) thresholds are identical. It is used for 244 admission in CL and 3SM. 246 2.2. Metering and Re-Marking of Previously Marked Packets 248 When packets travel over several links within a PCN domain, they are 249 possibly marked. This section clarifies the question concerning 250 packets of which markings should be taken into account for the 251 metering process on subsequent links and if so which markings are re- 252 marked. 254 2.2.1. Admission Marking 256 3SM and CL consider packets of all markings for metering, but TM- 257 marked packets must not be re-marked to AM. SM requires that 258 previously marked packets are excluded from metering, as not doing so 259 would result in underestimation of sustainable admission rate in the 260 multiple bottleneck scenarios, and consequently will result in the 261 under-estimation of the sustainable termination rate at the PCN- 262 ingress-node, in turn causing over-termination in the multiple 263 bottlenecks scenarios. 265 2.2.2. Termination Marking 267 CL needs to exclude all previously termination-marked packets from 268 metering in order to prevent underestimation of sustainable 269 termination rate. If previously termination-marked packets are not 270 excluded from metering, substantial over-termination in the multiple 271 bottleneck scenarios might occur. 3SM can accommodate previously 272 termination- marked packets being included for termination metering 273 (although the exact impact of doing so needs to be further 274 evaluated). Both in CL and 3SM, AM-marked packets may be remarked to 275 TM. Note that SM does not employ termination marking at the PCN- 276 ingress-node, an hence does not have any termination-marked packets 277 at all. 279 2.3. Number of Metering Functions and Marking Codepoints 281 Both CL and 3SM require 2 different metering functions - one (pcn- 282 lower-threshold) for admission and one (pcn-upper-threshold) for 283 termination. Three marking codepoints are needed for both: unmarked, 284 admission-marked (first PCN encoding) for admission, and termination- 285 marked (second PCN encoding) to terminate flows. 287 In contrast, SM requires a single metering threshold and two 288 different marking codepoints: marked and unmarked. (Note: There is a 289 choice to be made whether the "marked" codepoint should use the first 290 or the second PCN encoding state, if both are defined.) 292 3. Dropping Policies 294 A subtle difference in existing proposals for the PCN-interior-node 295 behavior is related to how already marked packets need to be treated 296 in the presence of loss. It turns out that all three approaches 297 assume different drop preferences. 299 CL needs preferential dropping of termination-marked packets. If 300 such preferential dropping is not implemented, then possible over- 301 termination may occur. It can be argued that the admission function 302 of CL is not sensitive to whether or not admission-marked packets are 303 preferentially dropped or not. 305 SM relies on preferential drop of marked packets. While admission 306 function of this approach appears to be insensitive to the drop 307 preference just as CL admission function, the termination function of 308 SM will result in over-termination if preferential dropping of 309 already marked packets is not implemented. While, insensitivity of 310 CL admission function to marked packet drop remains to be studied, 311 especially in the presence of large differences in packet sizes. 313 In contrast, the proposal in 3SM can benefit from preferential 314 dropping of unmarked flow-termination packets, but it can function 315 without at the expense of longer termination time. It can be argued 316 that the admission function of 3SM is not sensitive to whether or not 317 admission-marked packets are preferentially dropped or not. 319 4. PCN-Boundary-Node Behaviors 321 4.1. CL Boundary Behavior 323 In the CL approach, the PCN-egress-node measures the rate of 324 admission-marked, termination-marked, and unmarked PCN-traffic per 325 ingress-egress-aggregate. In addition, the PCN-ingress-node measures 326 the rate of sent PCN-traffic per ingress-egress-aggregate. To 327 support admission control, the PCN-egress-node calculates the 328 Congestion Level Estimate (CLE) defined as a fraction of (admission- 329 or termination-) marked traffic and the overall traffic, and signals 330 the CLE to the PCN-ingress-node. The PCN-ingress-node accepts or 331 rejects flows based on whether this CLE value for a particular 332 ingress-egress aggregate exceeds a pre-defined threshold. 334 To support flow termination, the PCN-egress-node calculates (on a 335 per-ingress-egress basis) the Sustainable (Termination) Rate, defined 336 as the combined rate of unmarked and admission-marked packets, and 337 signals the Sustainable Rate to the PCN-ingress-node. The PCN- 338 ingress-node measures the ingress sending rate (again on a per- 339 ingress-egress basis) and calculates the difference to the 340 sustainable termination rate. It chooses an appropriate set of flows 341 whose combined rate corresponds to that difference and terminates 342 these flows. (Note: this choice is done without any knowledge of 343 which flows had termination-marked packets.) 345 4.2. SM Boundary Behavior 347 In the SM approach, the PCN-egress-node measures the rate of marked 348 and unmarked traffic per ingress-egress-aggregate. In addition, the 349 PCN-ingress-node measures the rate of sent PCN-traffic per ingress- 350 egress-aggregate. 352 To support admission control, the PCN-egress-node calculates the 353 congestion level estimate (CLE) as the fraction of marked traffic and 354 the overall traffic, and signals the CLE to the PCN-ingress-node. 355 The PCN-ingress-node accepts or rejects flows based on whether this 356 CLE value exceeds a pre-defined threshold. 358 Although the boundary functions necessary to support admission 359 control are similar for CL and SM, an important difference between 360 the two algorithms stems from the fact that CL is using threshold (or 361 ramp) marking, while SM uses excess-rate-marking. As a result, the 362 meaningful value of CLE is also different. For example, in case of 363 small overloads, SM will have only a small fraction of packets marked 364 (and hence the appropriate CLE value needed to detect the overload 365 without over admission is small), while a small (but consistent) 366 overload with CL results in the majority of packets being marked, 367 resulting in CL being quite robust for a range of CLE values. 369 To support flow termination, the PCN-egress-node signals the rate of 370 unmarked packets as the so-called Sustainable (Admission) Rate to the 371 PCN-ingress-node. The PCN-ingress-node multiplies it by a system- 372 wide constant to get the Sustainable Termination Rate. The rest of 373 the termination is done like in the CL approach. The PCN-ingress- 374 node measures the ingress rate and calculates the difference to the 375 sustainable termination rate. It chooses an appropriate set of flows 376 whose overall rate corresponds to that difference and terminates 377 theses flows. (NOTE: This choice is done without any knowledge of 378 which flows had marked packets.) 380 4.3. 3SM Boundary Behavior 382 To support flow admission, a PCN-egress-node analyzes the packet 383 markings per ingress-egress-aggregate. Depending on the markings it 384 sends from time to time "admission-stop" or "admission-continue" 385 messages to the corresponding PCN-ingress-nodes to control their 386 admission of new flows. The PCN-ingress-node admits new flows when 387 the last control message was "admission-continue" and it rejects them 388 when it was "admission-stop". 3SM leaves deliberately open the way 389 how the PCN-egress-node decides when to send a specific control 390 message. A very simple option for the PCN-egress-node is to send an 391 "admission-stop" message when a single packet with admission- or 392 termination-marking is observed and to send an "admission-continue" 393 message some time after the last marked packet has been observed. 394 This is the method used for performance evaluation of 3SM reported in 395 [I-D.babiarz-pcn-explicit-marking]. A more sophisticated option is 396 to calculate a CLE based on an exponentially weighted moving average 397 (EWMA) counting marked messages as 1 and umarked messages as 0. When 398 the CLE exceeds an upper threshold, an "admission-stop" message is 399 sent, and when the CLE falls below a lower threshold, an "admission- 400 continue" message is sent. Other implementations are possible since 401 the decision logic is local to the PCN-egress-node. 403 To support flow termination, the PCN-egress-node in the 3SM approach 404 again monitors the packet markings and signals the flow ID of 405 termination-marked packets to the PCN-ingress-node whereby several 406 flow IDs may be sent in a single message. The PCN-ingress-node 407 terminates these flows. Note that neither the PCN-ingress-node nor 408 the PCN-egress-node are required to perform rate measurements in 3SM. 410 4.4. Notes on Using Different Boundary Behaviors with Different 411 Marking/Metering Behaviors 413 The previous three Subsections describe the PCN-boundary-node 414 behaviors in conjunction with specific proposals where these 415 behaviors were defined. It should be noted, however, that various 416 features of specific boundary behaviors described in the previous 417 sections may be used with different marking/metering strategies. For 418 example, as indicated in Section 4.3, the boundary behavior that CL 419 uses for admission can also be used with 3SM. Likewise, the 420 Termination function of CL may choose to only terminate those flows 421 whose packets are TM-marked - see Section 6 for discussion on how 422 this additional functionality can be used to address ECMP issues. 424 In general, new boundary behaviors may be designed to work with 425 proposed metering and marking mechanism. Nevertheless, in the 426 remaining portion of this document we will assume specific boundary 427 mechanisms as described in sections 4.1 - 4.3 unless stated 428 otherwise. 430 5. Informationed Signaled Between the Boundary Nodes 432 In CL, the PCN-egress-node must send to the PCN-ingress-node two 433 values: a CLE for Admission and Sustainable (Termination) rate for 434 Termination 436 In SM, the PCN-egress-node sends to the PCN-ingress-node the two 437 values as in CL: the CLE and Sustainable (Admission) Rate. (Note 438 that while the format of the signaling information is the same for CL 439 and SM, the meaning of Sustainable Rate is different in the two 440 cases). 442 In 3SM, the PCN-egress-node signals to the PCN-ingress-node using 443 control messages for the Admission process (e.g. admission-stop or 444 admission-continue messages). For Termination, the PCN-egress-node 445 signals to the ingress the flow ID of each flow to be terminated. 446 Note that several IDs can be communicated in a single signalling 447 (i.e. RSVP) message. 449 6. Dealing with ECMP 451 For admission control, neither of the three algorithms considered in 452 this draft address ECMP issue in the absence of probing of some sort. 453 The probing discussion is deferred to the next section. 455 Without probing, in the case when congestion state of different paths 456 in the network differ, flows may be admitted on a congested path 457 while the other path can remain uncongested, or, conversely, 458 admission may stop on all paths, when only one path becomes pre- 459 congested. 461 For termination, 3SM will correctly identify for termination only 462 those flows which pass congested paths even in the presence of ECMP. 463 In contrast, both CL and SM may erroneously terminate flows that do 464 not traverse congested paths. For CL, an option is available to 465 choose for termination only those flows that are termination-marked. 466 However, doing so then requires that the egress needs to additionally 467 signal to the ingress which flows have been marked, on top of the 468 other signaling information described in Section 5. 470 Single-marking does not explicitly mark traffic by termination- 471 marking and so the above option to identify flows of congested path 472 does not work. SM does have an option to terminate only those flows 473 that are marked for admission. However, this may result in erroneous 474 termination of flows on paths where traffic is above the Admission 475 threshold but below the level that should cause Termination. Just as 476 in the case of CL, doing so also involves the necessity to signal 477 additional information (flow IDs) between the PCN-egress-node and 478 PCN-ingress node. 480 7. Suitability for Probing for Admission Control 482 Although probing is currently out-of-scope of the PCN WG charter, it 483 may be useful in a number of situations (in particular, dealing with 484 ECMP for admission, or addressing flash crowd situations in the 485 presence of many small ingress-egress aggregates). We do not attempt 486 here to address the issue of whether or not and exactly how well 487 probing might work, nor do we discuss any protocol issues and 488 complexities associated with probing. Instead we touch upon only one 489 aspect of it - how well the PCN admission marking of by the three 490 proposals in question might work with probing. 492 Threshold-marking employed by both CL and 3SM results in all packets 493 being marked once the traffic rate exceeds PCN-lower-threshold (i.e 494 the admissible rate threshold). Therefore, a single probe packet is 495 guaranteed to be marked if the PCN-traffic rate exceeds the PCN- 496 lower-threshold threshold. Therefore, the admission decision can be 497 reliably made based on a single probe. One possibility may be to use 498 signaling (e.g. RSVP) messages as probes in this case. 500 In SM, admission metering and marking is based on Excess-rate- 501 marking. In this case, only a fraction of traffic is marked when 502 traffic exceeds the configured (admissible rate) threshold. 503 Therefore, when the PCN-traffic rate exceeds this threshold, a single 504 probe will only be marked with a certain probability, and so a series 505 of probes need to be sent to detect congestion with high probability. 507 Thus, Threshold-marking of CL and 3SM allows faster and simpler 508 admission decisions than Excess-rate-marking of SM. 510 In addition it should be noted that the necessity to send multiple 511 probes for SM adds a potential problem with using RSVP messages as 512 probes. Extensions necessary to do so have not been considered at 513 this time. 515 8. Configuration Complexity and Configuratio Restrictions 517 The approach in SM requires a global configuration parameter at the 518 edges reflecting the assumed ratio between the (implicit) termination 519 threshold and (explicit) admission threshold, which is assumed to be 520 global on all links in the PCN domain. This necessitates the use of 521 a global parameter that needs to be configured to the same value on 522 all PCN-boundary-nodes in the network. This clearly leads to an 523 additional configuration complexity of SM compared to CL and 3SM. 525 An additional issue caused by the assumption of the global ratio 526 between (implicit) termination threshold and (explicit) admission 527 threshold of SM is related to the flexibility of resiliency planning. 528 In this context, a natural approach is to use PCN-lower-threshold to 529 represent the expected utilisation on different links for expected 530 traffic matrix under normal, non-failure, conditions, and to view 531 PCN-upper-threshold to represent expected worst case utilization 532 under any of the "planned" failures. 534 As discussed in [Menth] and [I-D.charny-pcn-single-marking] , the 535 global ratio between the termination and admission utilisation levels 536 assumed in SM limits the flexibility of traffic engineering for 537 resiliency to a certain extent. Specifically, While all three 538 approaches can be configured to ensure that the planned matrix can be 539 protected against all the planned failure conditions, the nature of 540 the guarantee for the admitted traffic is different. Both CL and 3SM 541 can be configured to protect all admitted traffic (but would not 542 admit more than the planned traffic matrix), while SM can be 543 configured to admit more traffic than planned, but will not guarantee 544 protection against planned failures for traffic exceeding planned 545 utilization for the planned traffic matrix. 547 It should be noted that in principle, all three algorithms can be 548 configured to protect all admitted traffic (whether or not this 549 admitted traffic exceeds the planned traffic matrix or not). 550 However, as argued in [Menth], in this case SM can generally admit 551 less traffic than CL or 3SM. 553 We refer the reader to [Menth] and [I-D.charny-pcn-single-marking] 554 for a more detailed discussion on this issue. 556 9. Functional Comparison Summary 558 The following Table summarizes the differences between the three 559 approaches discussed so far. 561 (preamble) 562 -------------------------------------------------------------------| 563 |Comparison | SM | 3SM | CL | 564 |criteria | | | | 565 |-------------------------------------------------------------------- 566 |# of encoding | 2 | 3 | 3 | 567 |encoding | | | | 568 |states | | | | 569 |-------------------------------------------------------------------| 570 |# of metering | | | | 571 |mechanisms | 1 | 2 | 2 | 572 |in forwarding | | | | 573 |path of | | | | 574 |interior nodes| | | | 575 |-------------------------------------------------------------------| 576 |Type of | excess-rate | threshold | threshold or | 577 |metering & | marking | marking | ramp marking | 578 |marking for | | | | 579 |admission | | | | 580 |-------------------------------------------------------------------| 581 |Type of | N/A | excess-rate with | excess-rate | 582 |metering and | | marking frequency| marking | 583 |marking for | | reduction | | 584 |termination | | | | 585 |-------------------------------------------------------------------| 586 |Metering and | do not meter | meter all pkts | do not meter | 587 |remarking of | AM-marked | for admission | TM-marked pkts | 588 |previously | packets | and termination;| for termination | 589 |marked | | do not re-mark | meter all pkts;| 590 |packets | | TM-marked pkts | for admission, | 591 | | | | do not re-mark | 592 | | | | TM-marked pkts | 593 |-------------------------------------------------------------------| 594 |Packet Drop |preferentially | no sensitivity | no sensitivity | 595 |preference | drop AM-marked| to moderate drop | to moderate drop| 596 | | packets; over-| of AM-marked pkts| of AM-marked | 597 | |termination | preferentially | packets; | 598 | | otherwise | drop non-TM- | preferentially | 599 | | | marked packets- | drop TM-marked | 600 | | | over-termination | packets - | 601 | | | otherwise, espe- |over-termination | 602 | | | cially under | otherwise | 603 | | | high loss | | 604 |------------------------------------------------ ------------------| 605 |Egress | measure rates | observe packet | measure rates of| 606 |Function | of marked and | markings, send | AM/TM marked and| 607 | | unmarked pkts,| control messages | unmarked packets| 608 | | compute CLE, | to control admis-| compute CLE,send| 609 | | send both to | sion at ingress; | CLE and the rate| 610 | | ingress | send IDs of TM- | of unmarked pkts| 611 | | | marked packets to| to ingress | 612 | | | ingress | | 613 |-------------------------------------------------------------------| 614 |Ingress |compute sus- | terminate those | measure sending | 615 |Termination |tainable rate; | flows whose ids | rate; compute | 616 |function |measure sending| were signalled | rate to termi- | 617 | |rate; compute | by the egress | nate, select | 618 | |rate to | | flows to | 619 | |terminate, se- | | terminate | 620 | |lect flows to | | | 621 | |terminate | | | 622 |-------------------------------------------------------------------| 623 |Ingress |stop admitting | stop admitting |stop admitting | 624 |Admission |when CLE | when notified by |when CLE exceeds | 625 |Function |exceeds confi- | egress; resume |configured value;| 626 | |gured value; | after a timeout |restart admitting| 627 | |restart admit- | or when notified |when CLE reduces | 628 | |ting when CLE | by ingress |below configured | 629 | |falls below | |value | 630 | |configured | | | 631 | |value | | | 632 |-------------------------------------------------------------------| 633 |rate | required | optional | required | 634 |measurement | 1 at ingress | 1 at egress | 1 at ingress | 635 |at boundary | 2 at egress | | 2 at egress | 636 |nodes | | | | 637 |-------------------------------------------------------------------| 638 |Information |CLE, sustaina- |control messages |CLE, sustainable | 639 |signalled |ble(admission) |to stop & possibly|(termination) | 640 |from egress |rate |restart admission;|rate | 641 |to ingress | |ids of flows with | | 642 | | | TM-marked packets| | 643 |-------------------------------------------------------------------| 644 |ECMP support |no; only | yes | no; but full | 645 |for |partial support| | support with | 646 |Termination |with additional| | additional | 647 | | complexity at | | complexity at | 648 | | the edge + | | the edge + | 649 | | signaling flow| | plus signalling | 650 | | flow IDs from | | flow IDs from | 651 | | egress to | | egress to | 652 | | ingress | | ingress | 653 |-------------------------------------------------------------------| 654 |ECMP support |no w/out probes| no w/out probing | no w/out probing| 655 |for Admission |yes with probes| yes with probing | yes with probing| 656 | |but needs many |(needs one probe, |(needs one probe,| 657 | |probes; use of |can use RSVP as | can use RSVP | 658 | |RSVP as probes |probe) | as probe) | 659 | |not understood | | | 660 |-------------------------------------------------------------------| 661 |Network-wide | yes | no | no | 662 |parameter | (one global | | | 663 |configuration | parameter | | | 664 |coordination | at the edges)| | | 665 |-------------------------------------------------------------------| 666 | Support for | yes | yes | yes | 667 | resiliency | but weaker | | | 668 | planning | guarantees | | | 669 | | under planned | | | 670 | | failures for | | | 671 | | traffic excee-| | | 672 | | ding planned | | | 673 | |traffic matrix;| | | 674 | |if all admitted| | | 675 | |traffic is to | | | 676 | |be protected, | | | 677 | |SM can admit | | | 678 | |less traffic | | | 679 | |than CL or 3SM | | | 680 |-------------------------------------------------------------------| 682 (Table 8.1. Functional Comparison of CL, SM and 3SM) 684 Finally, a few words are due on relative complexities of the three 685 schemes. It should be clear from the above table that relative 686 complexity has a number of dimensions. Specifically: 688 o Complexity of the forwarding path. From that standpoint SM 689 appears to be the simplest, as it requires only a single metering 690 mechanism, CL appears to come next, closely followed by 3SM. 692 o Complexity of conditional metering (i.e checking whether a 693 particularly marked packet needs to be metered ). From that 694 standpoint, all three approaches appear to be comparable. (Note 695 that while SM admission function is more complex from this point 696 of view than admission functions of CL and 3SM, the additional 697 complexity of not metering AM-marked packets has to be balanced 698 against similar complexity of the termination functions of CL and 699 3SM). 701 o Complexity of implementing preferential packet loss. From that 702 standpoint all three approaches appear comparable, when both 703 admission and termination functions are considered. 705 o Complexity of boundary behaviors. From that standpoint 3SM 706 appears to be the least complex, CL coming next and SM following 707 closely. 709 o Complexity of support for ECMP. From that standpoint 3SM requires 710 no additional functionality, while CL and SM require extra 711 complexity at the boundary nodes and extra signaling information 712 exchange between the egress and the ingress (and in addition SM 713 has only partial support - see section 6 and table 8.1 for its 714 limitations). 716 o Global configuration complexity. From that standpoint Cl and 3SM 717 come first, with SM being the more complex as the only one 718 requiring global parameter setting. 720 These comparisons are very crude and are only intended to roughly 721 summarize the detailed differences described in Table 8.1. 723 10. Other Comparison Criteria 725 This section discusses a number of other comparison criteria that 726 have not been studied in detail or are currently under consideration 728 1. Co-existence with RFC3168 (work in progress); 730 2. Multicast support (TBD, NOTE: this is out-of-scope for the 731 current charter) 733 3. Future extensions to multiple domains 734 ([I-D.briscoe-tsvwg-re-ecn-border-cheat] for CL, not clarity on 735 other approaches; NOTE: this is out-of-scope of the current 736 charter) 738 4. Extensibility to host-initiated PCN (3SM designed to support 739 host-initiated PCN but performance analysis is ongoing; NOTE: 740 this is out-of-scope for the current charter. 742 5. Extensibility to rate-adaptive traffic (TBD; NOTE: this is out- 743 of-scope of the current charter) 745 6. Support of multiple precedence levels (TBD; NOTE: this is out-of- 746 scope of the current charter) 748 7. Performance comparison (ongoing, see next Subsection). 750 10.1. Performance Comparison 752 As mentioned in the Introduction, at the time of writing this 753 document several performance studies have been reported in 754 [I-D.zhang-pcn-performance-evaluation], 755 [I-D.charny-pcn-single-marking][I-D.babiarz-pcn-explicit-marking], 756 and [TR437]. While the first two studies have attempted a careful 757 side-by-side comparisons of CL and SM, the set of experiments 758 reported is less extensive, and a number of differences existing in 759 the simulation models and experiment setup make a side-by-side 760 apples-to-apples comparison of the 3 schemes difficult. In this we 761 will attempt to summarize performance evaluation criteria that could 762 be used for comparison of the different approaches, as well as 763 provide high level conclusions on some of them, where available 764 studies allow those conclusions. 766 We refer the reader to [I-D.zhang-pcn-performance-evaluation], 767 [I-D.charny-pcn-single-marking], [I-D.babiarz-pcn-explicit-marking], 768 and [TR437] for details that could not be captured within the format 769 of the table below. 771 DISCLAIMER: statements in the table below should be understood only 772 in terms relative to the three considered algorithms and with respect 773 to specific experiments performed; they and are intended for crude 774 qualitative comparison only based on (ongoing) simulation studies as 775 of the time of writing of this document . Quantification of these 776 statements can be found in the corresponding performance studies 777 referenced earlier in this section. 779 (preamble) 780 ------------------------------------------------------------------ 781 |Comparison | SM | 3SM | CL | 782 |Criteria | | | | 783 |-----------------------------------------------------------------| 784 |Sensitivity | poor perfor- | good performance | poor perfor- | 785 |to low | mance at low | at low aggrega- | mance at low | 786 |bottleneck | bottleneck | tion reported | bottleneck | 787 |aggregation | aggregation | (evaluation | aggregation | 788 | | | ongoing) | | 789 |-----------------------------------------------------------------| 790 |Sensitivity | performance | good in reported | admission | 791 |to low |degradation | experiments; | insensitive; | 792 |ingress- |for both | traffic and | termination | 793 |egress |termination | topology | sensitive for | 794 |aggregation |and admission | sensitivity study| some traffic | 795 | |under some | needed | types | 796 | |traffic types | | | 797 |-----------------------------------------------------------------| 798 |Sensitivity | a range of |evaluation ongoing| relatively | 799 |to marking & | params exist |slow-down param. S| insensitive to | 800 |measurement | with consis- |has the biggest | marking and | 801 |parameters | tent perfor- |impact on flow | measurement | 802 | | mance across |termination speed | params across | 803 | | a range of |(its choice de- | a range of | 804 | | traffic types|pends on topology | traffic types | 805 | | & topologies |and traffic rate) | and topologies | 806 |-----------------------------------------------------------------| 807 |Accuracy of |good for large| good | good | 808 |admission |ingress-egress|(but sensitivity | | 809 |across traf- |aggregation |to parameters TBD)| | 810 |fic types and| | | | 811 |topologies | | | | 812 |-----------------------------------------------------------------| 813 |Accuracy of |over- | good | good | 814 |termination |termination | (but sensitivity | | 815 |(single |compared to CL| to params TBD) | | 816 | bottleneck) |if termination| | | 817 | |trigger is not| | | 818 | |smoothed; | | | 819 | |otherwise | | | 820 | |slower reac- | | | 821 | |tion than CL | | | 822 |-----------------------------------------------------------------| 823 |Accuracy of | more over- | not reported | good | 824 |termination | termination | | | 825 |wet bottle- | than CL | | | 826 |neck utile. | | | | 827 |(multi-bot- | | | | 828 |neck case) | | | | 829 |-----------------------------------------------------------------| 830 |Reaction time| slower than | slower than CL, | fast | 831 |time to | CL with | comparison with | | 832 |termination | smoothing of | SM TBD; parameter| | 833 | | termination | sensitivity TBD | | 834 | | trigger, fast| | | 835 | | otherwise | | | 836 | | to 3SM | | | 837 |-----------------------------------------------------------------| 838 |Sensitivity |not reported; |preferentially | not reported ; | 839 |to large and |flow selection|selects large | flow selection | 840 |small flows |at ingress |flows; slow down | at ingress more | 841 |(termination)|more compli- |parameter hard to | complicated (or | 842 | |cated (or less|select for mix of | less accurate) | 843 | |accurate with |traffic rates | with widely dif-| 844 | |widely differ- |(over-termination | ferrent rates; | 845 | |rent rates; |or slower react- | (study ongoing) | 846 | |study ongoing |tion if slowdown | | 847 | | |parameter does | | 848 | | |not reflect | | 849 | | |average rate; | | 850 | | |evaluation ongoing| | 851 |-----------------------------------------------------------------| 852 |Beat-down | more beatdown| not reported | beat-down of | 853 |effect | of long-haul | | flows traversing| 854 |multi-bottle-| aggregates | | more bottlenecks| 855 |neck case) | than CL | | | 856 ------------------------------------------------------------------ 857 (Table 9.1. Summary of (up-to-date) performance comparison. ) 859 11. Unified Descriprion of Marking and Metering Functions 861 In this section we address the question of how the metering and 862 marking functions of the three approaches can be described in a 863 unified way so that different marking behaviors considered in this 864 draft can be obtained by different parametrization choices. A 865 potential benefit of such unified description is that a single PCN- 866 internal-node behavior could support a wider range of different PCN- 867 boundary-node behaviors, and hence, potentially, can be of use under 868 different deployment scenarios. We discuss the difficulties 869 associated with such unified description in the following section, 870 where we also raise the question of whether the benefits of such 871 unified behavior outweigh a number of drawbacks discussed in that 872 section. 874 In Figure 10.1, we show a relatively compact version of such unified 875 algorithm using the notion of Token Bucket (TB) . This pseudocode 876 does not support ramp-marking, as the current performance evaluation 877 studies indicate little additional benefit of ramp-marking compared 878 to threshold-marking. However, in the Appendix we present a (more 879 complex) version of the marking algorithm that does support ramp- 880 marking as well. 882 We note that the algorithm below (as well as a more complex complete 883 version in the Appendix) can be further optimized. We make no 884 optimization attempt in the interest of clarity. 886 The TB has a rate of TB.rate and a depth of TB.size. It has one 887 marking thresholds TB.threshold to support threshold marking. If 888 TB.threshold is configured to be greater than zero, then packets are 889 marked if the TB fill state is below TB.threshold after their arrival 890 and removal of tokens from the queue; otherwise packets are not 891 marked. The "classic" token bucket used by SM and the termination 892 function of CL is obtained by setting TB.theshold = 0. 894 In addition, the slowdown factor TB.slowdown is used to implement 895 marking frequency reduction: TB.slowdown tokens are added to the 896 token bucket when a packet is marked. The metering is applied only 897 to packets whose marking is part of a specific subset that we call 898 TB.meteredMarking. The TB.markingType indicates the type of 899 codepoint that is used for marking. In addition, the TB has a 900 variable TB.fill that records the number of tokens in the bucket and 901 the variable TB.lastUpdate records the last update instant of the 902 bucket. The global variable "now" indicates the current time. 903 Packets have size packet.size (in bytes) and marking packet.mark. 904 The algorithm is followed by a table describing the parameterization 905 necessary to implement Admission and Termination Functions for 906 different proposals. 908 (preamble) 909 Parameters: 910 TB.rate: token rate of TB in bytes/s 911 TB.size: depth of TB in tokens (bytes) 912 TB.threshold: marking threshold of TB in bytes 913 TB.slowdown: slowdown factor for marking frequency reduction of TB in bytes 914 TB.markingType: PCN-first-encoding ("admission") or 915 PCN-second-encoding ("termination"). 916 TB.meteredMarkings: set of packet markings that are eligible for metering by TB, 917 it is a subset of ("unmarked", "admission", "termination"). 918 NOTE: this set depends on whether it is admission or 919 termination that the function below is used for. 920 NOTE: settings of these parameters for different approaches are shown 921 in Tables 10.2 and 10.3 923 Input: packet 924 // take passed time since last update into account 925 TB.fill = min(TB.size, TB.fill+(now-TB.lastUpdate) * TB.rate); 926 TB.lastUpdate = now; 928 // meter and mark 929 If (packet.mark in TB.meteredMarkings) 930 if (TB.fill < packet.size) 931 // re-marking of TM-marked packets to AM not allowed 932 if (!(packet.mark == "termination" and TB.markingType == "admission")) 933 packet.mark = TB.markingType; 934 endif 935 else 936 TB.fill = TB.fill - packet.size; 937 if (TB.fill < TB.threshold) 938 // re-marking of TM-marked packets to AM not allowed 939 if (!(packet.mark == "termination" and TB.markingType == "admission")) 940 packet.mark = TB.markingType; 941 endif 942 endif 943 endif 944 endif 946 // marking frequency reduction 947 if (packet.mark == "termination") 948 TB.fill = min(TB.size, TB.fill + TB.slowdown); 949 endif 951 Output: void 953 (Figure 10.1. Simple generalized metering and marking algorithm 954 based on TB-formulation) 955 (preamble) 956 |----------------------------------------------------------------------| 957 | | CL Admission | SM | 3SM Admission | 958 |----------------|-----------------|-----------------|-----------------| 959 | TB.rate | PCN- | PCN- | PCN- | 960 | | lower-threshold | lower-threshold | lower-threshold | 961 |----------------|-----------------|-----------------|-----------------| 962 | TB.size | configured | configured | configured | 963 |----------------|-----------------|-----------------|-----------------| 964 | TB.threshold | configured | 0 | configured | 965 |----------------|-----------------|-----------------|-----------------| 966 | TB.slowdown | 0 | 0 | 0 | 967 |----------------|-----------------|-----------------|-----------------| 968 | TB.metered- | "unmarked" | "unmarked" | "unmarked" | 969 | Markings | "admission" | | "admission" | 970 | | "termination" | | "termination" | 971 |----------------|-----------------|-----------------|-----------------| 972 | TB.markingType | "admission" | "admission" | "admission" | 973 ----------------------------------------------------------------------| 974 (Figure 10.2 Admission Settings for the Three Algorithms) 976 (preamble) 977 ----------------------------------------------------------------------| 978 | | CL Termination | SM | 3SM Termination | 979 |----------------|-----------------|-----------------|-----------------| 980 | TB.rate | PCN-upper- | N/A | PCN-upper- | 981 | | threshold | | threshold | 982 |----------------|-----------------|-----------------|-----------------| 983 | TB.size | configured | N/A | configured | 984 |----------------|-----------------|-----------------|-----------------| 985 | TB.threshold | 0 | N/A | 0 | 986 |----------------|-----------------|-----------------|-----------------| 987 | TB.slowdown | 0 | N/A | configured | 988 |----------------|-----------------|-----------------|-----------------| 989 | TB.metered- | "unmarked" | N/A | "unmarked" | 990 | Markings | "admission" | | "admission" | 991 | | | | "termination" | 992 |----------------|-----------------|-----------------|-----------------| 993 | TB.markingType | "termination" | N/A | "termination" | 994 ----------------------------------------------------------------------| 995 (Figure 10.3 Termination Settings for the Three Algorithms) 997 Figures 10.2 and 10.3 provide parameter settings corresponding to 998 different metering and marking functions. 1000 It should be noted, that when the algorithm described by the 1001 pseudocode in Figure 10.1 is used to perform threshold-marking, it 1002 has a slightly different behavior than the algorithm described in CL 1003 and 3SM. The packet marking algorithm of 3SM bases its marking 1004 decision on TB.fill before tokens are removed while our algorithm 1005 makes the decision afterwards. In addition, the admission marking 1006 algorithms of both 3SM and CL set TB.fill=0 when TB.fill VQ.size) 1110 if (!(packet.mark == "termination" and VQ.markingType == "admission")) 1111 packet.mark = VQ.markingType; 1112 endif 1113 else 1114 VQ.length = VQ.length + packet.size; 1115 if (VQ.length > VQ.threshold) 1116 // re-marking of TM-marked packets to AM not allowed 1117 if (!(packet.mark == "termination" and VQ.markingType == "admission")) 1118 packet.mark = VQ.markingType; 1119 endif 1120 endif 1121 endif 1122 endif 1124 // marking frequency reduction 1125 if (packet.mark == "termination") 1126 VQ.length = max(0, VQ.length - VQ.slowdown); 1127 endif 1129 Output: void 1131 (Figure 14.1) 1133 The tables in Figs 14.3 and 14.4 at the end of this Section give the 1134 corresponding parameter setting for the three proposals. 1136 NOTE: There are two further optimization options that are possible 1137 for this (and the TB-based) metering and marking algorithm: 1139 1. If TM-packets are not metered for admission-marking, the inner 1140 if-clause to avoid the re-marking of TM-marked packets to AM can 1141 be removed. Current performance results suggest that this could 1142 be done, but for the sake of extensibility towards future rate 1143 adaptation it is better to keep open the option of metering all 1144 packets also for admission marking. 1146 2. The marking frequency reduction may be applied when packets are 1147 re-marked to TM. This is at the expense of increased unfairness 1148 and over termination in the presence of several simultaneously 1149 overloaded links. The advantage is an improved runtime of the 1150 algorithm and a possibly simpler implementation. 1152 15.2. VQ Formulation of the Complex Generalized Metering and Marking 1153 Algorithm 1155 The simple generalized metering and marking algorithm in 14.1 has the 1156 following shortcomings: 1158 1. It does not support ramp marking which may be desirable for CL; 1160 2. If the packet does not fit into the queue, the queue cannot be 1161 filled up to its size. This is a property for admission marking 1162 in CL and 3SM that is not implemented by a simplified algorithm 1163 (although the impact of this change appears to be minimal); 1165 3. If the packet fits into the queue, the marking decision is always 1166 based on the queue size including the size of the new packet. 1167 This leads to a nicer formulation of threshold or ramp marking 1168 (however, the impact of this change seems minimal) If the 1169 generalized algorithm takes also these 3 issues into account, it 1170 becomes significantly more complex. 1172 To improve shortcoming 1, the algorithm has now two marking 1173 thresholds to support ramp and threshold marking instead of a single 1174 one: VQ.lowerThreshold and VQ.upperThreshold. Packets are not marked 1175 if the queue length is below VQ.lowerThreshold, the marking 1176 probability linearly increases from 0 to 1 between VQ.lowerThreshold 1177 and VQ.upperThreshold, and packets are definitely marked if the queue 1178 length is VQ.upperThreshold and above. If both thresholds are set to 1179 the same positive value, threshold marking is performed: packets are 1180 not marked if the queue length is below or equal to that threshold, 1181 otherwise they are marked. 1183 To improve shortcoming 2 and 3, the Boolean variable 1184 VQ.alwaysUpdateState is introduced. If it is set to true, the queue 1185 length should always be increased by the packet size; this is the 1186 desired behaviour for admission marking when all packets are expected 1187 to be marked when the admissible rate is exceeded by the PCN rate. 1188 If it is set to false, the queue length is only increased if the 1189 packet is not marked; this is the desired behaviour for excess-rate- 1190 marking. 1192 (preamble) 1193 Additional parameters: 1194 VQ.lowerThreshold: lower marking threshold of VQ in bytes 1195 VQ.upperThreshold: upper marking threshold of VQ in bytes 1196 VQ.alwaysUpdateState: VQ length state always increased or not 1198 Input: packet 1200 // take passed time since last update into account 1201 VQ.length = max(0, VQ.length-(now-VQ.lastUpdate)*VQ.rate); 1202 VQ.lastUpdate = now; 1204 // meter and mark 1205 if (packet.mark in VQ.meteredMarkings) 1206 if (VQ.alwaysUpdateState == true) 1207 // threshold or ramp-marking 1208 if (VQ.length > VQ.upperThreshold) 1209 // re-marking of TM-marked packets to AM not allowed 1210 if (!(packet.mark == "termination" and VQ.markingType == "admission")) 1211 packet.mark = VQ.markingType; 1212 endif 1213 elseif (VQ.length > VQ.lowerThreshold) 1214 choose random number u (0 < u < 1); 1215 if (u < (VQ.length-VQ.lowerThreshold)/(VQ.upperThreshold-VQ.lowerThreshold)) 1216 // re-marking of TM-marked packets to AM not allowed 1217 if (!(packet.mark == "termination" and VQ.markingType == "admission")) 1218 packet.mark = VQ.markingType; 1219 endif 1220 endif 1221 endif 1222 VQ.length = min(VQ.size, VQ.length+packet.size); 1223 else 1224 // excess-rate-marking 1225 if (VQ.length + packet.size > VQ.size) 1226 // re-marking of TM-marked packets to AM not allowed 1227 if (!(packet.mark == "termination" and VQ.markingType == "admission")) 1228 packet.mark = VQ.markingType; 1229 endif 1230 else 1231 VQ.length = VQ.length + packet.size; 1232 endif 1233 endif 1234 endif 1235 // marking frequency reduction 1236 if (packet.mark == "termination") 1237 VQ.length = max(0, VQ.length - VQ.slowdown); 1238 endif 1240 Output: void 1242 (Figure 14.2) 1244 (preamble) 1245 |----------------------------------------------------------------------| 1246 | | CL Admission | SM | 3SM Admission | 1247 |----------------|-----------------|-----------------|-----------------| 1248 | VQ.rate | PCN- | PCN- | PCN- | 1249 | | lower-threshold | lower-threshold | lower-threshold | 1250 |----------------|-----------------|-----------------|-----------------| 1251 | VQ.size | configured | configured | configured | 1252 |----------------|-----------------|-----------------|-----------------| 1253 | VQ.always- | true | false | true | 1254 | UpdateState | | | | 1255 |----------------|-----------------|-----------------|-----------------| 1256 | VQ. | configured | 0 | configured | 1257 | lowerThreshold | | | | 1258 |----------------|-----------------|-----------------|-----------------| 1259 | VQ. | configured | 0 | configured | 1260 | upperThreshold | | | | 1261 |----------------|-----------------|-----------------|-----------------| 1262 | VQ.slowdown | 0 | 0 | 0 | 1263 |----------------|-----------------|-----------------|-----------------| 1264 | VQ. | "unmarked" | "unmarked" | "unmarked" | 1265 | meteredMarkings| "admission" | | "admission" | 1266 | | "termination" | | "termination" | 1267 |----------------|-----------------|-----------------|-----------------| 1268 | VQ.markingType | "admission" | "admission" | "admission" | 1269 ----------------------------------------------------------------------| 1270 (Figure 14.3. Admission settings for the three algorithms (VQ 1271 formulation)) 1272 (preamble) 1273 ----------------------------------------------------------------------- 1274 | | CL Termination | SM | 3SM Termination | 1275 |----------------|-----------------|-----------------|-----------------| 1276 | VQ.rate | PCN- | N/A | PCN- | 1277 | | lower-threshold | | upper-thrsehold | 1278 |----------------|-----------------|-----------------|-----------------| 1279 | VQ.size | configured | N/A | configured | 1280 |----------------|-----------------|-----------------|-----------------| 1281 | VQ.always- | false | N/A | false | 1282 | UpdateState | | | | 1283 |----------------|-----------------|-----------------|-----------------| 1284 | VQ. | 0 | N/A | 0 | 1285 | lowerThreshold | | | | 1286 |----------------|-----------------|-----------------|-----------------| 1287 | VQ. | 0 | N/A | 0 | 1288 | upperThreshold | | | | 1289 |----------------|-----------------|-----------------|-----------------| 1290 | VQ.slowdown | 0 | N/A | configured | 1291 |----------------|-----------------|-----------------|-----------------| 1292 | VQ. | "unmarked" | N/A | "unmarked" | 1293 | meteredMarkings| "admission" | | "admission" | 1294 | | | | "termination" | 1295 |--------------- |-----------------|-----------------|-----------------| 1296 | VQ.markingType | "termination" | N/A | "termination" | 1297 ---------------------------------------------------------------------- 1299 (Figure 14.4. Termination settings for the three algorithms (VQ 1300 formulation)) 1302 16. References 1304 16.1. Normative References 1306 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1307 Requirement Levels", BCP 14, RFC 2119, March 1997. 1309 16.2. Informative References 1311 [I-D.babiarz-pcn-3sm] 1312 Babiarz, J., "Three State PCN Marking", 1313 draft-babiarz-pcn-3sm-00 (work in progress), July 2007. 1315 [I-D.babiarz-pcn-explicit-marking] 1316 Liu, X. and J. Babiarz, "Simulations Results for 3sM", 1317 draft-babiarz-pcn-explicit-marking-01 (work in progress), 1318 July 2007. 1320 [I-D.briscoe-tsvwg-cl-architecture] 1321 Briscoe, B., "An edge-to-edge Deployment Model for Pre- 1322 Congestion Notification: Admission Control over a 1323 DiffServ Region", draft-briscoe-tsvwg-cl-architecture-04 1324 (work in progress), October 2006. 1326 [I-D.briscoe-tsvwg-cl-phb] 1327 Briscoe, B., "Pre-Congestion Notification marking", 1328 draft-briscoe-tsvwg-cl-phb-03 (work in progress), 1329 October 2006. 1331 [I-D.briscoe-tsvwg-re-ecn-border-cheat] 1332 Briscoe, B., "Emulating Border Flow Policing using Re-ECN 1333 on Bulk Data", draft-briscoe-tsvwg-re-ecn-border-cheat-01 1334 (work in progress), June 2006. 1336 [I-D.briscoe-tsvwg-re-ecn-tcp] 1337 Briscoe, B., "Re-ECN: Adding Accountability for Causing 1338 Congestion to TCP/IP", draft-briscoe-tsvwg-re-ecn-tcp-04 1339 (work in progress), July 2007. 1341 [I-D.charny-pcn-single-marking] 1342 Charny, A., "Pre-Congestion Notification Using Single 1343 Marking for Admission and Termination", 1344 draft-charny-pcn-single-marking-02 (work in progress), 1345 July 2007. 1347 [I-D.davie-ecn-mpls] 1348 Davie, B., "Explicit Congestion Marking in MPLS", 1349 draft-davie-ecn-mpls-01 (work in progress), October 2006. 1351 [I-D.ietf-pcn-architecture] 1352 Eardley, P., "Pre-Congestion Notification Architecture", 1353 draft-ietf-pcn-architecture-01 (work in progress), 1354 October 2007. 1356 [I-D.lefaucheur-emergency-rsvp] 1357 Faucheur, F., "RSVP Extensions for Emergency Services", 1358 draft-lefaucheur-emergency-rsvp-02 (work in progress), 1359 June 2006. 1361 [I-D.westberg-pcn-load-control] 1362 Westberg, L., "LC-PCN: The Load Control PCN Solution", 1363 draft-westberg-pcn-load-control-01 (work in progress), 1364 September 2007. 1366 [I-D.zhang-pcn-performance-evaluation] 1367 Zhang, X., "Performance Evaluation of CL-PHB Admission and 1368 Termination Algorithms", 1369 draft-zhang-pcn-performance-evaluation-02 (work in 1370 progress), July 2007. 1372 16.3. References 1374 [Menth] "PCN-Based Resilient Network Admission Control: The Impact 1375 of a Single Bit", 2007. 1377 [TR437] "Comparison of Marking Algorithms for PCN-Based Admission 1378 Control, Technical Report No. 437, University of 1379 Wuerzburg", October 2007. 1381 Authors' Addresses 1383 Anna Charny 1384 Cisco Systems, Inc. 1385 1414 Mass. Ave. 1386 Boxborough, MA 01719 1387 USA 1389 Email: acharny@cisco.com 1391 Joseph Babiarz 1392 Nortel 1393 3500 Carling Avenue 1394 Ottawa, Ontario K2H 8E9 1395 Canada 1397 Email: babiarz@nortel.com 1399 Michael Menth 1400 University of Wuerzburg 1401 Informatik III Am Hubland 1402 Wuerzburg, 97074 1403 Germany 1405 Email: menth@menth@informatik.uni-wuerzburg.de 1406 Joy Zhang 1407 Cisco Systems, Inc & Cornell University 1408 1414 Mass. Ave. 1409 Boxborough, MA 01719 1410 USA 1412 Email: acharny@cisco.com 1414 Full Copyright Statement 1416 Copyright (C) The IETF Trust (2007). 1418 This document is subject to the rights, licenses and restrictions 1419 contained in BCP 78, and except as set forth therein, the authors 1420 retain all their rights. 1422 This document and the information contained herein are provided on an 1423 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1424 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1425 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1426 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1427 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1428 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1430 Intellectual Property 1432 The IETF takes no position regarding the validity or scope of any 1433 Intellectual Property Rights or other rights that might be claimed to 1434 pertain to the implementation or use of the technology described in 1435 this document or the extent to which any license under such rights 1436 might or might not be available; nor does it represent that it has 1437 made any independent effort to identify any such rights. Information 1438 on the procedures with respect to rights in RFC documents can be 1439 found in BCP 78 and BCP 79. 1441 Copies of IPR disclosures made to the IETF Secretariat and any 1442 assurances of licenses to be made available, or the result of an 1443 attempt made to obtain a general license or permission for the use of 1444 such proprietary rights by implementers or users of this 1445 specification can be obtained from the IETF on-line IPR repository at 1446 http://www.ietf.org/ipr. 1448 The IETF invites any interested party to bring to its attention any 1449 copyrights, patents or patent applications, or other proprietary 1450 rights that may cover technology that may be required to implement 1451 this standard. Please address the information to the IETF at 1452 ietf-ipr@ietf.org. 1454 Acknowledgment 1456 Funding for the RFC Editor function is provided by the IETF 1457 Administrative Support Activity (IASA).