idnits 2.17.1 draft-ietf-pcn-marking-behaviour-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 3, 2009) is 5378 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) == Outdated reference: A later version (-07) exists of draft-ietf-pcn-baseline-encoding-04 == Outdated reference: A later version (-07) exists of draft-ietf-tsvwg-admitted-realtime-dscp-05 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCN Working Group Philip. Eardley (Editor) 3 Internet-Draft BT 4 Intended status: Standards Track August 3, 2009 5 Expires: February 4, 2010 7 Metering and marking behaviour of PCN-nodes 8 draft-ietf-pcn-marking-behaviour-05 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on February 4, 2010. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 The objective of Pre-Congestion Notification (PCN) is to protect the 57 quality of service (QoS) of inelastic flows within a Diffserv domain, 58 in a simple, scalable, and robust fashion. This document defines the 59 two metering and marking behaviours of PCN-nodes. Threshold-metering 60 and -marking marks all PCN-packets if the rate of PCN-traffic is 61 greater than a configured rate ("PCN-threshold-rate"). Excess- 62 traffic-metering and -marking marks a proportion of PCN-packets, such 63 that the amount marked equals the rate of PCN-traffic in excess of a 64 configured rate ("PCN-excess-rate"). The level of marking allows 65 PCN-boundary-nodes to make decisions about whether to admit or 66 terminate PCN-flows. 68 Requirements Language 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in RFC 2119 [RFC2119]. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 78 2. Specified PCN-metering and -marking behaviours . . . . . . . . 6 79 2.1. Behaviour aggregate classification function . . . . . . . 6 80 2.2. Dropping function . . . . . . . . . . . . . . . . . . . . 6 81 2.3. Threshold-meter function . . . . . . . . . . . . . . . . . 7 82 2.4. Excess-traffic-meter function . . . . . . . . . . . . . . 7 83 2.5. Marking function . . . . . . . . . . . . . . . . . . . . . 8 84 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 85 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 86 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 87 6. Changes (to be removed by RFC Editor) . . . . . . . . . . . . 10 88 6.1. Changes to -05 from -04 . . . . . . . . . . . . . . . . . 10 89 6.2. Changes to -04 from -03 . . . . . . . . . . . . . . . . . 11 90 6.3. Changes to -03 from -02 . . . . . . . . . . . . . . . . . 11 91 6.4. Changes to -02 from -01 . . . . . . . . . . . . . . . . . 12 92 6.5. Changes to -01 from -00 . . . . . . . . . . . . . . . . . 12 93 6.6. Changes to -00 . . . . . . . . . . . . . . . . . . . . . . 13 94 7. References note (to be removed by RFC Editor) . . . . . . . . 13 95 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 96 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 97 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 98 Appendix A. Example algorithms . . . . . . . . . . . . . . . . . 16 99 A.1. Threshold-metering and -marking . . . . . . . . . . . . . 16 100 A.2. Excess-traffic-metering and -marking . . . . . . . . . . . 17 101 Appendix B. Implementation notes . . . . . . . . . . . . . . . . 18 102 B.1. Competing-non-PCN-traffic . . . . . . . . . . . . . . . . 18 103 B.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 19 104 B.3. Behaviour aggregate classification . . . . . . . . . . . . 20 105 B.4. Dropping . . . . . . . . . . . . . . . . . . . . . . . . . 20 106 B.5. Threshold-metering . . . . . . . . . . . . . . . . . . . . 22 107 B.6. Excess-traffic-metering . . . . . . . . . . . . . . . . . 23 108 B.7. Marking . . . . . . . . . . . . . . . . . . . . . . . . . 24 109 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 111 1. Introduction 113 The objective of Pre-Congestion Notification (PCN) is to protect the 114 quality of service (QoS) of inelastic flows within a Diffserv domain, 115 in a simple, scalable, and robust fashion. Two mechanisms are used: 116 admission control, to decide whether to admit or block a new flow 117 request, and (in abnormal circumstances) flow termination to decide 118 whether to terminate some of the existing flows. To achieve this, 119 the overall rate of PCN-traffic is metered on every link in the 120 domain, and PCN-packets are appropriately marked when certain 121 configured rates are exceeded. These configured rates are below the 122 rate of the link thus providing notification to boundary nodes about 123 overloads before any congestion occurs (hence "pre-congestion 124 notification"). The level of marking allows boundary nodes to make 125 decisions about whether to admit or terminate. Within the domain, 126 PCN-traffic is forwarded in a prioritised Diffserv traffic class 127 [RFC2475]. 129 This document defines the two metering and marking behaviours of PCN- 130 nodes. Their aim is to enable PCN-nodes to give an "early warning" 131 of potential congestion before there is any significant build-up of 132 PCN-packets in their queues. In summary, their objectives are: 134 o threshold-metering and -marking: its objective is to mark all PCN- 135 packets (with a "threshold-mark") when the bit rate of PCN-traffic 136 is greater than its configured reference rate ("PCN-threshold- 137 rate"); 139 o excess traffic marking: when the bit rate of PCN-packets is 140 greater than its configured reference rate ("PCN-excess-rate"), 141 its objective is to mark PCN-packets (with an "excess-traffic- 142 mark") at a rate equal to the difference between the rate of PCN- 143 traffic and the PCN-excess-rate. 145 Note that although [RFC3168] defines a broadly RED-like (Random Early 146 Detection) default congestion marking behaviour, it allows 147 alternatives to be defined; this document defines such an 148 alternative. 150 Section 2 below describes the functions involved, which in outline 151 (see Figure 1) are: 153 o Behaviour aggregate (BA) classification: decide whether an 154 incoming packet is a PCN-packet or not. 156 o Dropping (optional): drop packets if the link is overloaded. 158 o Threshold-meter: determine whether the bit rate of PCN-traffic 159 exceeds its configured reference rate (PCN-threshold-rate). The 160 meter operates on all PCN-packets on the link, and not on 161 individual flows. 163 o Excess-traffic-meter: measure by how much the bit rate of PCN- 164 traffic exceeds its configured reference rate (PCN-excess-rate). 165 The meter operates on all PCN-packets on the link, and not on 166 individual flows. 168 o PCN-mark: actually mark the PCN-packets, if the meter functions 169 indicate to do so. 171 +---------+ Result 172 +->|Threshold|-------+ 173 | | Meter | | 174 | +---------+ V 175 +----------+ +- - - - -+ | +------+ 176 | BA | | | | | | Marked 177 Packet =>|Classifier|==>| Dropper |==?===============>|Marker|==> Packet 178 Stream | | | | | | | Stream 179 +----------+ +- - - - -+ | +------+ 180 | +---------+ ^ 181 | | Excess | | 182 +->| Traffic |-------+ 183 | Meter | Result 184 +---------+ 186 Figure 1: Schematic of PCN-interior-node functionality. 188 Appendix A gives an example of algorithms that fulfil the 189 specification of Section 2, and Appendix B provides some explanations 190 of and comments on Section 2. Both the Appendices are informative. 192 The general architecture for PCN is described in [RFC3168], whilst 193 [Menth09] is an overview of PCN. 195 1.1. Terminology 197 In addition to the terminology defined in [RFC5559] and [RFC2474], 198 the following terms are defined: 200 o Competing-non-PCN-packet: a non PCN-packet that shares a link with 201 PCN-packets and competes with them for its forwarding bandwidth. 202 Competing-non-PCN-packets MUST NOT be PCN-marked (only PCN-packets 203 can be PCN-marked). Note: In general it is not advised to have 204 any competing-non-PCN-traffic. Note: there is likely to be 205 traffic (such as best effort) that is forwarded at lower priority 206 than PCN-traffic; although it shares the link with PCN-traffic it 207 doesn't compete for forwarding bandwidth, and hence it is not 208 competing-non-PCN-traffic. See Appendix B.1 for further 209 discussion about competing-non-PCN-traffic. 211 o Metered-packet: a packet that is metered by the metering functions 212 specified in Sections 2.3 and 2.4. A PCN-packet MUST be treated 213 as a metered-packet (with the minor exception noted below in 214 Section 2.4). A competing-non-PCN-packet MAY be treated as a 215 metered-packet. 217 2. Specified PCN-metering and -marking behaviours 219 This section defines the two PCN-metering and -marking behaviours. 220 The descriptions are functional and are not intended to restrict the 221 implementation. The informative Appendices supplement this section. 223 2.1. Behaviour aggregate classification function 225 A PCN-node MUST classify a packet as a PCN-packet if the value of its 226 DSCP and ECN fields correspond to a PCN-enabled codepoint, as defined 227 in the encoding scheme applicable to the PCN-domain (for example, 228 [I-D.ietf-pcn-baseline-encoding] defines the baseline encoding). 229 Otherwise the packet MUST NOT be classified as a PCN-packet. 231 A PCN-node MUST classify a packet as a competing-non-PCN-packet if it 232 is not a PCN-packet and it competes with PCN-packets for its 233 forwarding bandwidth on a link. 235 2.2. Dropping function 237 Note: if the PCN-node's queue overflows then naturally packets are 238 dropped. This section describes additional action. 240 On all links in the PCN-domain, dropping MAY be done by: 242 o metering all metered-packets to determine if the rate of metered- 243 traffic on the link is greater than the rate allowed for such 244 traffic. 246 o if the rate of metered-traffic is too high, then drop metered- 247 packets. 249 If the PCN-node drops PCN-packets then: 251 o PCN-packets that arrive at the PCN-node already excess-traffic- 252 marked SHOULD be preferentially dropped; 254 o the PCN-node's excess-traffic-meter SHOULD NOT meter the PCN- 255 packets that it drops. 257 2.3. Threshold-meter function 259 A PCN-node MUST implement a threshold-meter that has behaviour 260 functionally equivalent to the following. 262 The meter acts like a token bucket, which is sized in bits and has a 263 configured reference rate (bits per second). The amount of tokens in 264 the token bucket is termed F_tm. Tokens are added at the reference 265 rate (PCN-threshold-rate), to a maximum value BS_tm. Tokens are 266 removed equal to the size in bits of the metered-packet, to a minimum 267 F_tm = 0. (Explanation of abbreviations: F is short for Fill of the 268 token bucket, BS for bucket size, and tm for threshold-meter.) 270 The token bucket has a configured intermediate depth, termed 271 threshold. If F_tm < threshold, then the meter indicates to the 272 marking function that the packet is to be threshold-marked; otherwise 273 it does not. 275 2.4. Excess-traffic-meter function 277 A packet SHOULD NOT be metered (by this excess-traffic-meter 278 function) in the following two cases: 280 o If the PCN-packet is already excess-traffic-marked on arrival at 281 the PCN-node; 283 o If this PCN-node drops the packet. 285 Otherwise the PCN-packet MUST be treated as a metered-packet, that is 286 it is metered by the excess-traffic-meter. 288 A PCN-node MUST implement an excess-traffic-meter. The excess- 289 traffic-meter SHOULD indicate packets to be excess-traffic-marked 290 independent of their size ("packet size independent marking"); if 291 "packet size independent marking" is not implemented then the excess- 292 traffic-meter MUST use the "classic" metering behaviour. 294 For the "classic" metering behaviour the excess-traffic-meter has 295 behaviour functionally equivalent to the following. 297 The meter acts like a token bucket, which is sized in bits and has a 298 configured reference rate (bits per second). The amount of tokens in 299 the token bucket is termed F_etm. Tokens are added at the reference 300 rate (PCN-excess-rate), to a maximum value BS_etm. Tokens are 301 removed equal to the size in bits of the metered-packet, to a minimum 302 F_etm = 0. If the token bucket is empty (F_etm = 0), then the meter 303 indicates to the marking function that the packet is to be excess- 304 traffic-marked. (Explanation of abbreviations: F is short for Fill 305 of the token bucket, BS for bucket size, and etm for excess-traffic- 306 meter.) 308 For "packet size independent marking" the excess-traffic-meter has 309 behaviour functionally equivalent to the following. The meter acts 310 like a token bucket, which is sized in bits and has a configured 311 reference rate (bits per second). The amount of tokens in the token 312 bucket is termed F_etm. Tokens are added at the reference rate (PCN- 313 excess-rate), to a maximum value BS_etm. If the token bucket is not 314 negative, then tokens are removed equal to the size in bits of the 315 metered-packet (and the meter does not indicate to the marking 316 function that the packet is to be excess-traffic-marked). If the 317 token bucket is negative (F_etm < 0), then the meter indicates to the 318 marking function that the packet is to be excess-traffic-marked (and 319 no tokens are removed). (Explanation of abbreviations: F is short 320 for Fill of the token bucket, BS for bucket size, and etm for excess- 321 traffic-meter.) 323 Otherwise the meter MUST NOT indicate marking. 325 2.5. Marking function 327 A PCN-packet MUST be marked to reflect the metering results by 328 setting its encoding state appropriately, as specified by the 329 specific encoding scheme that applies in the PCN-domain. A 330 consistent choice of encoding scheme MUST be made throughout a PCN- 331 domain. 333 A PCN-node MUST NOT: 335 o PCN-mark a packet that is not a PCN-packet; 337 o change a non PCN-packet into a PCN-packet; 339 o change a PCN-packet into a non PCN-packet. 341 Note: although competing-non-PCN-packets MAY be metered, they MUST 342 NOT be PCN-marked. 344 3. IANA Considerations 346 This document makes no request of IANA. 348 Note to RFC Editor: this section may be removed on publication as an 349 RFC. 351 4. Security Considerations 353 It is assumed that all PCN-nodes are PCN-enabled and are trusted for 354 truthful PCN-metering and PCN-marking. If this isn't the case then 355 there are numerous potential attacks. For instance, a rogue PCN- 356 interior-node could PCN-mark all packets so that no flows were 357 admitted. Another possibility is that it doesn't PCN-mark any 358 packets, even when it is pre-congested. 360 Note that PCN-interior-nodes are not flow-aware. This prevents some 361 security attacks where an attacker targets specific flows in the data 362 plane -- for instance, for DoS or eavesdropping. 364 As regards Security Operations and Management, PCN adds few specifics 365 to the general good practice required in this field [RFC4778]. For 366 example, it may be sensible for a PCN-node to raise an alarm if it is 367 persistently PCN-marking. 369 Security considerations are further discussed in [RFC5559]. 371 5. Acknowledgements 373 This document is the result of extensive collaboration within the PCN 374 WG. Amongst the most active contributors to the development of the 375 ideas specified in this document have been Jozef Babiarz, Bob 376 Briscoe, Kwok-Ho Chan, Anna Charny, Philip Eardley, Georgios 377 Karagiannis, Michael Menth, Toby Moncaster, Daisuke Satoh, and Joy 378 Zhang. Appendix A is based on text from Michael Menth. 380 This document is a development of [I-D.briscoe-tsvwg-cl-phb]. Its 381 authors are therefore also contributors to this document: Jozef 382 Babiarz, Attila Bader, Bob Briscoe, Kwok-Ho Chan, Anna Charny, 383 Stephen Dudley, Philip Eardley, Georgios Karagiannis, Francois Le 384 Faucheur, Vassilis Liatsos, Dave Songhurst, Lars Westberg. 386 Thanks to those who've made comments on the draft: Joe Babiarz, Fred 387 Baker, David Black, Bob Briscoe, Ken Carlberg, Anna Charny, Ralph 388 Droms, Mehmet Ersue, Adrian Farrel, Ruediger Geib, Wei Gengyu, 389 Fortune Huang, Christian Hublet, Ingemar Johansson, Georgios 390 Karagiannis, Alexey Melnikov, Michael Menth, Toby Moncaster, Dimitri 391 Papadimitriou, Tim Polk, Daisuke Satoh, Magnus Westerlund. 393 6. Changes (to be removed by RFC Editor) 395 6.1. Changes to -05 from -04 397 Updates to take account of IESG comments as follows: 399 o S1: added refs to PCN background 401 o S1: corrected "standardises" to "describes" 403 o S1: for clarity added: "Within the domain, PCN-traffic is 404 forwarded in a prioritised Diffserv traffic class [RFC2475]." 406 o S1.1: added note to clarify that Best Effort traffic isn't 407 competing-non-PCN-traffic: "Note: there is likely to be traffic 408 (such as best effort) that is forwarded at lower priority than 409 PCN-traffic; although it shares the link with PCN-traffic it 410 doesn't compete for forwarding bandwidth, and hence it is not 411 competing-non-PCN-traffic. See Appendix B.1 for further 412 discussion about competing-non-PCN-traffic." 414 o S2.3 & 2.4: added units for reference rate of token buckets: 415 "(bits per second)" 417 o S2.4, "Packet size independent (excess-traffic-)marking": added 418 clarification about behaviour if token bucket is negative: "(and 419 no tokens are removed)". Swapped two sentences round for clarity, 420 so first describe behaviour if token bucket is non negative and 421 then behaviour if token bucket is negative. 423 o S4: deleted the sentence "More subtly...", as this might be 424 misconstrued as implying PCN-interior-nodes are flow-aware. 426 o S8: upgraded RFC2119 to normative ref 428 o SB.6, "Packet size independent (excess-traffic-)marking": added 429 clarification: 434 o Expanded RED, and other minor typos and clarifications 436 6.2. Changes to -04 from -03 438 Updates to take account of IETF last call comments, including a Gen- 439 ART review from David Black and OPS DIR review from Mehmet Ersue, as 440 follows: 442 o re-phrased of S2.2 first bullet for clarity 444 o S2.4 re-phrased, so that competing-non-PCN-packets that are 445 metered are covered by the "SHOULD NOT be metered ..." text 447 o "Packet size independent (excess-traffic-)marking": re-phrased the 448 para in 2.4 for clarity; altered the algorithm in Appendix A so it 449 does PSIM; clarified the explanation in Appendix B.6 in light of 450 this. Clarified that if packet size independent marking (the 451 SHOULD behaviour) is implemented, then the 'classic' marking 452 doesn't have to be (ie it's only a MUST if PSIM isn't 453 implemented). Also added info on 'functionally equivalent' 454 behaviour for PSIM. 456 o added Security Considerations, based on material from RFC5559 458 o other minor typos and clarifications 460 6.3. Changes to -03 from -02 462 Updates to take account of last call comments as follows: 464 o renamed from "marking" to "metering and marking" (throughout) - 465 the former was intended as shorthand for the latter, but this was 466 found confusing 468 o added 'common capsule' summary of PCN to Introduction and removed 469 extraneous material 471 o replaced the term 'traffic conditioning' by 'dropping' 472 (throughout) - since the former has a wider meaning than just 473 dropping. 475 o discussion of the case with baseline encoding where there are two 476 PCN states - this is now done just once - in Section B.2. 478 o added in Section B.5 "The PCN-threshold-rate is configured at less 479 than the rate allocated to the PCN-traffic class" and in B.6 "The 480 PCN-excess-rate is configured at less than (or possibly equal to) 481 the rate allocated to the PCN-traffic class". 483 o configuring the PCN-excess-rate at greater than (or possibly equal 484 to) the PCN-threshold-rate - this is now in one place, as advice 485 is B5 & B6. 487 o SB.1: "voice-admit" corrected with references to I-D ietf-tsvwg- 488 admitted-realtime-dscp and RFC5127. 490 o "CL/SM edge behaviour" altered to the less obscure "controlled 491 load edge behaviour" and a reference added. 493 o S2.3, 2.4 & Appendix A: altered some of the abbreviations, for 494 better consistency with approach of RFC2698. eg TBthreshold.fill 495 => F_tm. 497 o the ACKs section improved 499 o other minor corrections and clarifications 501 6.4. Changes to -02 from -01 503 Updates as follows: 505 o added notes (end of S1.1 & 2.5) to clarify what "excess-traffic- 506 marked" means when there is only one encoding for PCN-marking 508 o added explanations for in Section B.4 and B.6 about why various 509 things are SHOULD or SHOULD NOT rather than MUST or MUST NOT. 511 o Deleted a couple of paragraphs about encoding states, as they are 512 relevant to encoding documents rather than this document. 514 6.5. Changes to -01 from -00 516 Updates as follows: 518 o corrected the term 'not PCN-marked' to 'not-marked' (throughout) 520 o re-phrased the definition of competing-non-PCN-packets 522 o corrected the definition of metered-packet 524 o delete most of Section 2.5 (marking function). The material 525 deleted belongs as part of [I-D.ietf-pcn-baseline-encoding]; other 526 encoding schemes would need to include similar material. 528 o deleted Appendix C (it was only a temporary archive of material 529 concerning per domain behaviour and PCN-boundary-node operation) 531 o clarifications throughout 533 o made all references Informative 535 6.6. Changes to -00 537 First version of WG draft, derived from 538 draft-eardley-pcn-marking-behaviour-01, with the following changes: 540 o Removed material concerning per domain behaviour and PCN-boundary- 541 node operation (temporarily archived to Appendix C) 543 o Removed mention of downgrading as an option for per-hop traffic 544 conditioning. In fact, downgrading is no longer allowed because S 545 2.6 now says "A PCN-node MUST NOT ...change a PCN-packet into a 546 non PCN-packet". 548 o Traffic conditioning is now a MAY. Since in general flow 549 termination (not traffic conditioning) is PCN's method for 550 handling problems of too much traffic. 552 o Metered-packets: competing-non-PCN-packets now MAY be metered. 553 Since it is recommended that the operator doesn't allow any 554 competing-non-PCN-traffic, and (if there is) there are potentially 555 other ways of coping. 557 o No changes (outside traffic conditioning & metering of competing- 558 non-PCN-traffic) to the Normative sections of the draft. 560 o Appendix B.1 added about competing-non-PCN-traffic. Recommended 561 that there is no such traffic, but guidance given if there is. 563 7. References note (to be removed by RFC Editor) 565 Note for RFC Editor: since RFCs can't include reference names such as 566 ietf-pcn-baseline-encoding, please make the following changes: 568 o I-D.ietf-pcn-baseline-encoding => Moncaster09 570 o I-D.ietf-tsvwg-admitted-realtime-dscp => Baker08 572 o I-D.briscoe-tsvwg-byte-pkt-mark => Briscoe08 574 o I-D.briscoe-tsvwg-cl-architecture => Briscoe06-1 576 o I-D.briscoe-tsvwg-cl-phb => Briscoe06-2 577 o I-D.charny-pcn-comparison => Charny07 579 o I-D.taylor-pcn-cl-edge-behaviour => Taylor09 581 Note: For several drafts the I-D database on xml2rfc doesn't pick up 582 all the authors, please correct as follows: 584 o I-D.briscoe-tsvwg-cl-architecture: Briscoe, B., Eardley, P., 585 Songhurst, D., Le Faucheur, F., Charny, A., Babiarz, J., Chan, K., 586 Dudley, S., Karagiannis, G., Bader, A., and L. Westberg 588 o I-D.briscoe-tsvwg-cl-phb: Briscoe, B., Eardley, P., Songhurst, D., 589 Le Faucheur, F., Charny, A., Liatsos, V., Babiarz, J., Chan, K., 590 Dudley, S., Karagiannis, G., Bader, A., and L. Westberg 592 o I-D.charny-pcn-comparison: Charny, A., Babiarz, J., Menth, M., and 593 X. Zhang 595 8. References 597 8.1. Normative References 599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 600 Requirement Levels", BCP 14, RFC 2119, March 1997. 602 8.2. Informative References 604 [I-D.briscoe-tsvwg-byte-pkt-mark] 605 Briscoe, B., "Byte and Packet Congestion Notification", 606 draft-briscoe-tsvwg-byte-pkt-mark-02 (work in progress), 607 February 2008. 609 [I-D.briscoe-tsvwg-cl-architecture] 610 Briscoe, B., "An edge-to-edge Deployment Model for Pre- 611 Congestion Notification: Admission Control over a 612 DiffServ Region", draft-briscoe-tsvwg-cl-architecture-04 613 (work in progress), October 2006. 615 [I-D.briscoe-tsvwg-cl-phb] 616 Briscoe, B., "Pre-Congestion Notification marking", 617 draft-briscoe-tsvwg-cl-phb-03 (work in progress), 618 October 2006. 620 [I-D.charny-pcn-comparison] 621 Charny, A., "Comparison of Proposed PCN Approaches", 622 draft-charny-pcn-comparison-00 (work in progress), 623 November 2007. 625 [I-D.ietf-pcn-baseline-encoding] 626 Moncaster, T., Briscoe, B., and M. Menth, "Baseline 627 Encoding and Transport of Pre-Congestion Information", 628 draft-ietf-pcn-baseline-encoding-04 (work in progress), 629 May 2009. 631 [I-D.ietf-tsvwg-admitted-realtime-dscp] 632 Baker, F., Polk, J., and M. Dolly, "DSCP for Capacity- 633 Admitted Traffic", 634 draft-ietf-tsvwg-admitted-realtime-dscp-05 (work in 635 progress), November 2008. 637 [I-D.taylor-pcn-cl-edge-behaviour] 638 Charny, A., Huang, F., Menth, M., and T. Taylor, "PCN 639 Boundary Node Behaviour for the Controlled Load (CL) Mode 640 of Operation", draft-taylor-pcn-cl-edge-behaviour-00 (work 641 in progress), March 2009. 643 [Menth09] Menth, M., Lehrieder, F., Briscoe, B., Eardley, P., 644 Moncaster, T., Babiarz, J., Chan, K., Charny, A., 645 Karagiannis, G., Zhang, X., Taylor, T., Satoh, D., and R. 646 Geib, "A Survey of PCN-Based Admission Control and Flow 647 Termination", IEEE Communications Surveys and Tutorials, < 648 http://www3.informatik.uni-wuerzburg.de/staff/menth/ 649 Publications/papers/Menth08-PCN-Overview.pdf>. 651 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 652 "Definition of the Differentiated Services Field (DS 653 Field) in the IPv4 and IPv6 Headers", RFC 2474, 654 December 1998. 656 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 657 and W. Weiss, "An Architecture for Differentiated 658 Services", RFC 2475, December 1998. 660 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 661 of Explicit Congestion Notification (ECN) to IP", 662 RFC 3168, September 2001. 664 [RFC4778] Kaeo, M., "Operational Security Current Practices in 665 Internet Service Provider Environments", RFC 4778, 666 January 2007. 668 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 669 DiffServ Service Classes", RFC 5127, February 2008. 671 [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) 672 Architecture", RFC 5559, June 2009. 674 Appendix A. Example algorithms 676 Note: This Appendix is informative, not normative. It is an example 677 of algorithms that implement Section 2 and is based on 678 [I-D.charny-pcn-comparison] and [Menth09]. 680 There is no attempt to optimise the algorithms. The metering and 681 marking functions are implemented together. It is assumed that three 682 encoding states are available (one for threshold-marked, one for 683 excess-traffic-marked, and one for not PCN-marked). It is assumed 684 that all metered-packets are PCN-packets and that the link is never 685 overloaded. For excess-traffic-marking, "packet size independent 686 marking" applies. 688 A.1. Threshold-metering and -marking 690 A token bucket with the following parameters: 692 o PCN-threshold-rate: token rate of token bucket (bits/second) 694 o BS_tm: depth of token bucket (bits) 696 o threshold: marking threshold of token bucket (bits) 698 o lastUpdate: time the token bucket was last updated (seconds) 700 o F_tm: amount of tokens in token bucket (bits) 702 A PCN-packet has the following parameters: 704 o packet_size: the size of the PCN-packet (bits) 706 o packet_mark: the PCN encoding state of the packet 708 In addition there is the parameter: 710 o now: the current time (seconds) 712 The following steps are performed when a PCN-packet arrives on a 713 link: 715 o F_tm = min(BS_tm, F_tm + (now - lastUpdate) * PCN-threshold-rate); 716 // add tokens to token bucket 718 o F_tm = max(0, F_tm - packet_size); // remove tokens from token 719 bucket 721 o if ((F_tm < threshold) AND (packet_mark != excess-traffic-marked)) 722 then packet_mark = threshold-marked; // do threshold marking, but 723 don't re-mark packets that are already excess-traffic-marked 725 o lastUpdate = now // Note: 'now' has the same value as in step 1 727 A.2. Excess-traffic-metering and -marking 729 A token bucket with the following parameters: 731 o PCN-excess-rate: token rate of token bucket (bits/second) 733 o BS_etm: depth of TB in token bucket (bits) 735 o lastUpdate: time the token bucket was last updated (seconds) 737 o F_etm: amount of tokens in token bucket (bits) 739 A PCN-packet has the following parameters: 741 o packet_size: the size of the PCN-packet (bits) 743 o packet_mark: the PCN encoding state of the packet 745 In addition there is the parameter: 747 o now: the current time (seconds) 749 The following steps are performed when a PCN-packet arrives on a 750 link: 752 o F_etm = min(BS_etm, F_etm + (now - lastUpdate) * PCN-excess-rate); 753 // add tokens to token bucket 755 o if (packet_mark != excess-traffic-marked) then // do not meter 756 packets that are already excess-traffic-marked 758 o 760 * if (F_etm < 0) then packet_mark = excess-traffic-marked; // do 761 excess-traffic-marking. The algorithm ensures this is 762 independent of packet size 764 * else F_etm = F_etm - packet_size; // remove tokens from token 765 bucket if don't mark packet 767 o lastUpdate = now // Note: 'now' has the same value as in step 1 769 Appendix B. Implementation notes 771 Note: This Appendix is informative, not normative. It comments on 772 Section 2, including reasoning about whether MUSTs or SHOULDs are 773 required. For guidance on Operations and Management considerations, 774 please see [RFC5559]. 776 B.1. Competing-non-PCN-traffic 778 In general it is not advised to have any competing-non-PCN-traffic, 779 essentially because the unpredictable amount of competing-non-PCN- 780 traffic makes the PCN mechanisms less accurate and so reduces PCN's 781 ability to protect the QoS of admitted PCN-flows [RFC5559]. But if 782 there is competing-non-PCN-traffic, then: 784 1. There should be a mechanism to limit it, for example: 786 * limit the rate at which competing-non-PCN-traffic can be 787 forwarded on each link in the PCN-domain. One method for 788 achieving this is to queue competing-non-PCN-packets 789 separately from PCN-packets, and to limit the scheduling rate 790 of the former. Another method is to drop competing-non-PCN- 791 packets in excess of some rate. 793 * police competing-non-PCN-traffic at the PCN-ingress-nodes. 794 For example, as in the Diffserv architecture - however, its 795 static traffic conditioning agreements risk a focused overload 796 of traffic from several PCN-ingress-nodes onto one link. 798 * by design it is known that the level of competing-non-PCN- 799 traffic is always very small - perhaps it consists of operator 800 control messages only. 802 2. In general PCN's mechanisms should take account of competing-non- 803 PCN-traffic, in order to improve the accuracy of the decision 804 about whether to admit (or terminate) a PCN-flow. For example: 806 * competing-non-PCN-traffic contributes to the PCN meters: 807 competing-non-PCN-packets are treated as metered-packets. 809 * each PCN-node, on its links: (1) reduces the reference rates 810 (PCN-threshold-rate and PCN-excess-rate), in order to allow 811 'headroom' for the competing-non-PCN-traffic; (2) limits the 812 maximum forwarding rate of competing-non-PCN-traffic to be 813 less than the 'headroom'. In this case competing-non-PCN- 814 packets are not treated as metered-packets. 816 3. The operator should decide on what appropriate action. Dropping 817 is discussed further in Section B.4. 819 One specific example of competing-non-PCN-traffic occurs if the PCN- 820 compatible Diffserv codepoint is one of those that 821 [I-D.ietf-tsvwg-admitted-realtime-dscp]) defines as suitable for use 822 with admission control, and there is such non PCN-traffic in the PCN- 823 domain. A similar example could occur for Diffserv codepoints of the 824 Real-Time Treatment Aggregate [RFC5127]). In such cases PCN-traffic 825 and competing-non-PCN-traffic are distinguished by different values 826 of the ECN field [I-D.ietf-pcn-baseline-encoding]. 828 Another example would occur if there is more than one PCN-compatible 829 Diffserv codepoint in a PCN-domain. For instance, suppose there are 830 two PCN-BAs treated at different priorities. Then as far as the 831 lower priority PCN-BA is concerned, the higher priority PCN-traffic 832 needs to be treated as competing-non-PCN-traffic. 834 B.2. Scope 836 It may be known, for instance by the design of the network topology, 837 that some links can never be pre-congested (even in unusual 838 circumstances, such as after the failure of some links). There is 839 then no need to deploy the PCN metering and marking behaviour on 840 those links. 842 The meters can be implemented on the ingoing or outgoing interface of 843 a PCN-node. It may be that existing hardware can support only one 844 meter per ingoing interface and one per outgoing interface. Then for 845 instance threshold-metering could be run on all the ingoing 846 interfaces and excess-traffic-metering on all the outgoing 847 interfaces; note that the same choice must be made for all the links 848 in a PCN-domain to ensure that the two metering behaviours are 849 applied exactly once for all the links. 851 The baseline encoding [I-D.ietf-pcn-baseline-encoding] specifies only 852 two encoding states (PCN-marked and not-marked). In this case, 853 "excess-traffic-marked" means a packet that is PCN-marked as a result 854 of the excess-traffic-meter function, and "threshold-marked" means a 855 packet that is PCN-marked as a result of the threshold-meter 856 function. As far as terminology is concerned, this interpretation is 857 consistent with that defined in [RFC5559]. Note that a deployment 858 needs to make a consistent choice throughout the PCN-domain whether 859 PCN-marked is interpreted as excess-traffic-marked or threshold- 860 marked. 862 Note that even if there are only two encoding states, it is still 863 required that both the meters are implemented, in order to ease 864 compatibility between equipment, and to remove a configuration option 865 and associated complexity. Hardware with limited availability of 866 token buckets could be configured to run only one of the meters, but 867 it must be possible to enable either meter. Although in the scenario 868 with two encoding states, indications from one of the meters are 869 ignored by the marking function, they may be logged or acted upon in 870 some other way, for example by the management system or an explicit 871 signalling protocol; such considerations are out of scope of this 872 document. 874 B.3. Behaviour aggregate classification 876 Configuration of PCN-nodes will define what values of the DSCP and 877 ECN fields indicate a PCN-packet in a particular PCN-domain. For 878 instance [I-D.ietf-pcn-baseline-encoding] defines the baseline 879 encoding. 881 Configuration will also define what values of the DSCP and ECN fields 882 indicate a competing-non-PCN-packet in a particular PCN-domain. 884 B.4. Dropping 886 The objective of the dropping function is to minimise the queueing 887 delay suffered by metered-traffic at a PCN-node, since PCN-traffic 888 (and perhaps competing-non-PCN-traffic) is expected to be inelastic 889 traffic generated by real time applications. In practice it would be 890 defined as exceeding a specific traffic profile, typically based on a 891 token bucket. 893 If there is no competing-non-PCN-traffic, then it is not expected 894 that the dropping function is needed, since PCN's flow admission and 895 termination mechanisms limit the amount of PCN-traffic. Even so, it 896 still might be implemented as a back stop against misconfiguration of 897 the PCN-domain, for instance. 899 If there is competing-non-PCN-traffic, then the details of the 900 dropping function will depend on how the router's implementation 901 handles the two sorts of traffic (the discussion here is based on 902 that in [I-D.ietf-tsvwg-admitted-realtime-dscp]): 904 o a common queue for PCN-traffic and competing-non-PCN-traffic, and 905 a traffic conditioner for the competing-non-PCN-traffic; or 907 o separate queues. In this case the amount of competing-non-PCN- 908 traffic can be limited by limiting the rate at which the scheduler 909 (for the competing-non-PCN-traffic) forwards packets. 911 Note that only dropping of packets is allowed. Downgrading of 912 packets to a lower priority BA is not allowed (see B.7), since it 913 would lead to packet mis-ordering. Shaping ("the process of delaying 914 packets" [RFC2475]) is not suitable if the traffic comes from real 915 time applications. 917 Preferential dropping of competing-non-PCN-traffic: In general it is 918 reasonable for competing-non-PCN-traffic to get harsher treatment 919 than PCN-traffic (that is, competing-non-PCN-packets are 920 preferentially dropped), because PCN's flow admission and termination 921 mechanisms are stronger than the mechanisms that are likely to be 922 applied to the competing-non-PCN-traffic. The PCN mechanisms also 923 mean that a dropper should not be needed for the PCN-traffic. 925 Preferential dropping of excess-traffic-marked packets: Section 2.3 926 specifies: "If the PCN-node drops PCN-packets then ... PCN-packets 927 that arrive at the PCN-node already excess-traffic-marked SHOULD be 928 preferentially dropped". In brief, the reason is that, with the 929 "controlled load" edge behaviour [I-D.taylor-pcn-cl-edge-behaviour] 930 this avoids over-termination in the event of multiple bottlenecks in 931 the PCN-domain [I-D.charny-pcn-comparison]. A fuller explanation is 932 as follows. The optimal dropping behaviour depends on the particular 933 edge behaviour [Menth09]. A single dropping behaviour is defined, as 934 it is simpler to standardise, implement and operate. The 935 standardised dropping behaviour is at least adequate for all edge 936 behaviours (and good for some), whereas others are not (for example 937 with tail dropping far too much traffic may be terminated with the 938 "controlled load" edge behaviour, in the event of multiple 939 bottlenecks in the PCN-domain [I-D.charny-pcn-comparison]). The 940 dropping behaviour is defined as a 'SHOULD', rather than a 'MUST', in 941 recognition that other dropping behaviour may be preferred in 942 particular circumstances, for example: (1) with the "marked flow" 943 termination edge behaviour, preferential dropping of unmarked packets 944 may be better [Menth09]; (2) tail dropping may make PCN-marking 945 behaviour easier to implement on current routers. 947 Exactly what "preferentially dropped" means is left to the 948 implementation. It is also left to the implementation what to do if 949 there are no excess-traffic-marked PCN-packets available at a 950 particular instant. 952 Section 2.2 also specifies: "the PCN-node's excess-traffic-meter 953 SHOULD NOT meter the PCN-packets that it drops." This avoids over- 954 termination [Menth09]. Effectively it means that the dropping 955 function (if present) should be done before the meter functions - 956 which is natural. 958 B.5. Threshold-metering 960 The description is in terms of a 'token bucket with threshold' (which 961 [I-D.briscoe-tsvwg-cl-architecture] views as a virtual queue). 962 However the description is not intended to standardise 963 implementation. 965 The reference rate of the threshold-meter (PCN-threshold-rate) is 966 configured at less than the rate allocated to the PCN-traffic class. 967 Also, the PCN-threshold-rate is less than, or possibly equal to, the 968 PCN-excess-rate. 970 Section 2.3 defines: "If F_tm < threshold, then the meter indicates 971 to the marking function that the packet is to be threshold-marked; 972 otherwise it does not." Note that a PCN-packet is marked without 973 explicit additional bias for the packet's size. 975 The behaviour must be functionally equivalent to the description in 976 Section 2.3. "Functionally equivalent" means the observable 'black 977 box' behaviour is the same or very similar, for example if either 978 precisely the same set of packets is marked, or if the set is shifted 979 by one packet. It is intended to allow implementation freedom over 980 matters such as: 982 o whether tokens are added to the token bucket at regular time 983 intervals or only when a packet is processed. 985 o whether the new token bucket depth is calculated before or after 986 it is decided whether to PCN-mark the packet. The effect of this 987 is simply to shift the sequence of marks by one packet. 989 o when the token bucket is very nearly empty and a packet arrives 990 larger than F_tm, then the precise change in F_tm is up to the 991 implementation. For instance: 993 * set F_tm = 0 and indicate threshold-mark to the Marking 994 function. 996 * check whether F_tm < threshold and if it is then indicate 997 threshold-mark to the Marking function; then set F_tm = 0. 999 * leave F_tm unaltered and indicate threshold-mark to the Marking 1000 function. 1002 o similarly, when the token bucket is very nearly full and a packet 1003 arrives larger than (BStm - F_tm), then the precise change in F_tm 1004 is up to the implementation. 1006 o Note that all PCN-packets, even if already marked, are metered by 1007 the threshold-meter function (unlike the excess-traffic-meter 1008 function), because all packets should contribute to the decision 1009 whether there is room for a new flow. 1011 B.6. Excess-traffic-metering 1013 The description is in terms of a token bucket, however the 1014 implementation is not standardised. 1016 The reference rate of the excess-traffic-meter (PCN-excess-rate) is 1017 configured at less than (or possibly equal to) the rate allocated to 1018 the PCN-traffic class. Also, the PCN-excess-rate is greater than, or 1019 possibly equal to, the PCN-threshold-rate. 1021 As in Section B.3, "functionally equivalent" allows some 1022 implementation flexibility, for example the exact algorithm when the 1023 token bucket is very nearly empty or very nearly full. 1025 Section 2.4 specifies: "A packet SHOULD NOT be metered (by this 1026 excess traffic meter function) ... If the packet is already excess- 1027 traffic-marked on arrival at the PCN-node". This avoids over- 1028 termination (with some edge behaviours) in the event that the PCN- 1029 traffic passes through multiple bottlenecks in the PCN-domain 1030 [I-D.charny-pcn-comparison]. Note that an implementation could 1031 determine whether the packet is already excess-traffic-marked as an 1032 integral part of its BA classification function. The behaviour is 1033 defined as a 'SHOULD NOT', rather than a 'MUST NOT', because it may 1034 be slightly harder to implement than a metering function that is 1035 blind to previous packet markings. 1037 Section 2.4 specifies: "A packet SHOULD NOT be metered (by this 1038 excess traffic meter function) ... If this PCN-node drops the 1039 packet." This avoids over-termination [Menth09]. (A similar 1040 statement could also be made for the threshold meter function but is 1041 irrelevant, as a link that is overloaded will already be 1042 substantially pre-congested and hence threshold-marking all packets.) 1043 It seems natural to perform the dropping function before the metering 1044 functions, although for some equipment it may be harder to implement; 1045 hence the behaviour is defined as a 'SHOULD NOT', rather than a 'MUST 1046 NOT'. 1048 "Packet size independent marking" - excess-traffic-marking that is 1049 independent of packet size - is specified as a SHOULD rather than a 1050 'MUST' in Section 2.4, because it may be slightly harder for some 1051 equipment to implement, and the impact of not doing it is undesirable 1052 but moderate (sufficient traffic is terminated, but flows with large 1053 packets are more likely to be terminated). With the "classic" 1054 excess-traffic-meter behaviour, large packets are more likely to be 1055 excess-traffic-marked than small packets (because packets are marked 1056 if the number of tokens in the packet is smaller than the packet 1057 size). This means that, with some edge behaviours, flows with large 1058 packets are more likely to be terminated than flows with small 1059 packets [I-D.briscoe-tsvwg-byte-pkt-mark] [Menth09]. "Packet size 1060 independent marking" can be achieved by a small modification of the 1061 "classic" excess-traffic-meter: the number of tokens in the bucket 1062 can become negative; if this number is negative at a packet's 1063 arrival, the packet is marked; otherwise, the amount of tokens equal 1064 to the packet size is removed from the bucket. Note that with 1065 "packet size independent marking", either the packet is marked or 1066 tokens are removed -- never both. Hence the token bucket cannot 1067 become more negative than the maximum packet size on the link. The 1068 algorithm described in Appendix A implements this behaviour. 1070 Note that BS_etm is independent of BStm; F_etm is independent of F_tm 1071 (except in that a packet can change both); and the two configured 1072 rates (PCN-excess-rate and PCN-threshold-rate) are independent 1073 (except that PCN-excess-rate >= PCN-threshold-rate). 1075 B.7. Marking 1077 Section 2.5 defines: "A PCN-node MUST NOT ...change a PCN-packet into 1078 a non PCN-packet". This means that a PCN-node is not allowed to 1079 downgrade a PCN-packet into a lower priority Diffserv BA (hence 1080 downgrading is not allowed as an alternative to dropping). 1082 Section 2.5 defines: "A PCN-node MUST NOT ...PCN-mark a packet that 1083 is not a PCN-packet". This means that in the scenario where 1084 competing-non-PCN-packets are treated as metered-packets, a meter may 1085 indicate a packet is to be PCN-marked, but the marking function knows 1086 it cannot be marked. It is left open to the implementation exactly 1087 what to do in this case; one simple possibility is to mark the next 1088 PCN-packet. Note that unless the PCN-packets are a large fraction of 1089 all the metered-packets then the PCN mechanisms may not work well. 1091 Although the metering functions are described separately from the 1092 marking function, they can be implemented in an integrated fashion. 1094 Author's Address 1096 Philip Eardley 1097 BT 1098 Adastral Park, Martlesham Heath 1099 Ipswich. IP5 3RE 1100 UK 1102 Email: philip.eardley@bt.com