idnits 2.17.1 draft-eardley-pcn-marking-behaviour-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 861. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 872. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 879. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 885. 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 Copyright Line does not match the current year -- 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 (June 25, 2008) is 5776 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) ** Downref: Normative reference to an Informational RFC: RFC 1633 ** Downref: Normative reference to an Informational RFC: RFC 2475 ** Downref: Normative reference to an Informational RFC: RFC 3086 == Outdated reference: A later version (-01) exists of draft-moncaster-pcn-3-state-encoding-00 == Outdated reference: A later version (-11) exists of draft-ietf-pcn-architecture-03 == Outdated reference: A later version (-02) exists of draft-moncaster-pcn-baseline-encoding-01 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCN Working Group P. Eardley (Editor) 3 Internet-Draft BT 4 Intended status: Standards Track June 25, 2008 5 Expires: December 27, 2008 7 Marking behaviour of PCN-nodes 8 draft-eardley-pcn-marking-behaviour-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 27, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document standardises the two marking behaviours of PCN-nodes: 42 threshold marking and excess traffic marking. Threshold marking 43 marks all PCN-packets if the PCN traffic rate is greater than a first 44 configured rate. Excess traffic marking marks a proportion of PCN- 45 packets, such that the amount marked equals the traffic rate in 46 excess of a second configured rate. 48 Requirements Language 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC 2119 [RFC2119]. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 58 2. Specified PCN-marking behaviour . . . . . . . . . . . . . . . 6 59 2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.2. Classify function . . . . . . . . . . . . . . . . . . . . 7 61 2.3. Traffic conditioning function . . . . . . . . . . . . . . 7 62 2.4. Threshold meter function . . . . . . . . . . . . . . . . . 8 63 2.5. Excess traffic meter function . . . . . . . . . . . . . . 8 64 2.6. Marking function . . . . . . . . . . . . . . . . . . . . . 9 65 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 68 6. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 6.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 11 70 7. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 73 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 74 Appendix A. Example algorithms . . . . . . . . . . . . . . . . . 12 75 A.1. Threshold metering and marking . . . . . . . . . . . . . . 13 76 A.2. Excess traffic metering and marking . . . . . . . . . . . 13 77 Appendix B. Implementation notes . . . . . . . . . . . . . . . . 14 78 B.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 B.2. Classify . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 B.3. Traffic conditioning . . . . . . . . . . . . . . . . . . . 15 81 B.4. Threshold metering . . . . . . . . . . . . . . . . . . . . 16 82 B.5. Excess traffic metering . . . . . . . . . . . . . . . . . 17 83 B.6. Marking . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 Intellectual Property and Copyright Statements . . . . . . . . . . 20 87 1. Introduction 89 [I-D.ietf-pcn-architecture] describes a general architecture for flow 90 admission and termination based on pre-congestion information in 91 order to protect the quality of service of established inelastic 92 flows within a single DiffServ domain. The pre-congestion 93 information consists of specific markings of PCN-packets. The edge 94 nodes of the DiffServ domain read these markings and convert them 95 into flow admission and termination decisions. Overall the aim is to 96 enable PCN-nodes to give an "early warning" of potential congestion 97 before there is any significant build-up of PCN-packets in their 98 queues. 100 This document standardises the two marking behaviours of PCN-nodes. 101 In summary, their objectives are: 103 o threshold marking: its objective is to mark all PCN-packets (with 104 a "threshold-mark") whenever the rate of PCN-packets is greater 105 than some configured rate ("PCN-threshold-rate"); 107 o excess traffic marking: whenever the rate of PCN-packets is 108 greater than some configured rate ("PCN-excess-rate"), its 109 objective is to mark PCN-packets (with an "excess-traffic-mark") 110 at a rate equal to the difference between the bit rate of PCN- 111 packets and the PCN-excess-rate. 113 [I-D.ietf-pcn-architecture] describes how the admission control 114 mechanism limits the PCN-traffic on each link to *roughly* its PCN- 115 threshold-rate and how the flow termination mechanism limits the PCN- 116 traffic on each link to *roughly* its PCN-excess-rate. 118 Section 2 specifies the functions involved, which in outline (see 119 Figure 1) are: 121 o Packet classify and condition - decide whether an incoming packet 122 belongs to a PCN-flow or not; 124 o Condition: drop or downgrade packets if the link is overloaded; 126 o Threshold meter - determine whether the rate of PCN-packets is 127 greater than the configured PCN-threshold-rate; 129 o Excess traffic meter - measure by how much the rate of PCN-packets 130 is greater than the configured PCN-excess-rate; 132 o Mark - actually mark the PCN-packets, if the meter functions 133 indicate to do so; 135 PCN encoding uses a combination of the DSCP field and ECN field in 136 the IP header to indicate that a packet is a PCN-packet and whether 137 it is PCN-marked. [I-D.moncaster-pcn-baseline-encoding] defines two 138 encoding states (PCN-marked and not PCN-marked), whilst 139 [I-D.draft-moncaster-pcn-3-state-encoding] defines an extended scheme 140 with three encoding states. So in a particular deployment the 141 operator may have three encoding states available (so allowing both 142 threshold marking and excess traffic marking) or may have only two 143 encoding states (so allowing either threshold marking and excess 144 traffic marking). As described in [I-D.ietf-pcn-architecture], flow 145 termination is based on excess traffic marked packets, whilst 146 admission control can be based on either threshold marked or excess 147 traffic marked packets (the former is more accurate, 148 [I-D.draft-charny-pcn-comparison]). This leads to the following four 149 use cases: 151 1. an operator requires both admission control and flow termination, 152 and has three encoding states available. Then admission control 153 is triggered from PCN-packets that are threshold-marked, and flow 154 termination from PCN-packets that are excess-traffic-marked. 156 2. an operator requires both admission control and flow termination, 157 and has only two encoding states available. Then both admission 158 control and flow termination are triggered from PCN-packets that 159 are excess-traffic-marked. 161 3. an operator requires only admission control. Then admission 162 control is triggered from PCN-packets that are threshold-marked 163 and only two encoding states are needed. (Flow termination may 164 be provided by a non PCN mechanism; this is out of scope.) 166 4. an operator requires only flow termination. Then flow 167 termination is triggered from PCN-packets that are excess- 168 traffic-marked and only two encoding states are needed. 169 (Admission control may be provided by a non PCN mechanism; this 170 is out of scope.) 171 +---------+ Result 172 +->|Threshold|-------+ 173 | | Meter | | 174 | +---------+ V 175 +---------+ +---------+ | +------+ 176 | | | | | | | Marked 177 Packet =>|Classify |==>|Condition|==?================>|Marker|==> Packet 178 Stream | | | | | | | Stream 179 +---------+ +---------+ | +------+ 180 | +---------+ ^ 181 | | Excess | | 182 +->| Traffic |-------+ 183 | Meter | Result 184 +---------+ 186 Figure 1: Schematic of functions for PCN-marking 188 1.1. Terminology 190 In addition to the terminology defined in [I-D.ietf-pcn-architecture] 191 and RFC 2474 [RFC2474], the following terms are defined: 193 o PCN-traffic: (defined in [draft-pcn-architecture] but need to 194 clarify that PCN-BA is idenitfied by combination of DSCP & ECN 195 fields) 197 o Other-traffic: traffic that uses the same DS codepoint as PCN- 198 traffic, but a different value in the ECN field; has the same 199 priority as PCN-traffic (in terms of scheduling at PCN-nodes); but 200 is not subject to PCN-marking, nor PCN's admissin control and flow 201 termination mechanisms. Thus PCN-traffic and other-traffic have 202 different per-domain behaviours RFC 3086 [RFC3086]. Note: there 203 may be no other-traffic in a PCN-domain. Note: the term PCN-BA 204 does not include other-traffic (this is a clarification, as the 205 definition of behaviour aggregate in RFC 2474 [RFC2474], RFC 2475 206 [RFC2475] is somewhat ambiguous in the context of PCN. 208 o Priority-traffic: traffic that is more important than PCN that 209 shares the same capacity as PCN and is priority scheduled over PCN 210 (perhaps an operator's control messages). Note: there may be no 211 priority-traffic in a PCN-domain. 213 o Metered-traffic: the collective term for PCN-traffic and (if any) 214 priority-traffic and other-traffic. 216 o Downgrade: Re-marking a packet, ie changing its DS codepoint, into 217 a lower priority behaviour aggregate, such as best effort or 218 assured forwarding; as a consequence perhaps dropping lower 219 priority packets. 221 o 308 If PCN-packets are dropped (or downgraded) then: 310 o excess-traffic-marked PCN-packets SHOULD be preferentially dropped 311 (downgraded); 313 o PCN-packets that are dropped (downgraded) SHOULD NOT be metered by 314 the Excess traffic Meter. 316 In addition, PCN-ingress-nodes MUST police PCN-traffic by: 318 o metering PCN-packets that are part of a previously admitted PCN- 319 flow, to check that it keeps to the agreed rate or flowspec (eg 320 RFC 1633 [RFC1633] for a microflow, and its NSIS equivalent). 322 o checking that any packets received that demand PCN treatment do 323 indeed belong to a previously admitted flow. 325 o dropping or downgrading packets that fail the above checks. 327 In addition, PCN-ingress-nodes MUST police other-traffic by: 329 o metering other-traffic to check that it meeds its traffic 330 conditioning agreement, which is the parameters of the traffic 331 that will be accepted from a customer. Typically it is statically 332 defined as part of the subscription-time service level agreement, 333 as in the DiffServ architecture RFC 2475 [RFC2475] 335 o dropping or downgrading packets that fail the above check. 337 In addition, an operator MAY measure the amount of traffic entering 338 (or leaving) its network for accounting reasons. Consideration is 339 out of scope of this document. 341 2.4. Threshold meter function 343 The Threshold Meter MUST have behaviour that is functionally 344 equivalent to the following. 346 The meter acts like a token bucket, which is sized in bits and has a 347 configured bit rate, termed PCN-threshold-rate. The amount of tokens 348 in the token bucket is termed TB1.fill. Tokens are added at the PCN- 349 threshold-rate, to a maximum value TB1.max. Tokens are removed equal 350 to the size in bits of the metered-packet, to a minimum TB1.fill=0. 352 The token bucket has a configured token bucket depth (between 0 and 353 TB1.max), termed TB1.threshold. If TB1.fill < TB1.threshold, then 354 the meter indicates to the Marking function that the packet is to be 355 threshold-marked; otherwise it does not. 357 2.5. Excess traffic meter function 359 A packet SHOULD NOT be metered (by this excess traffic meter 360 function) in the following two cases: 362 o If the packet is already excess-traffic-marked; 364 o If this PCN-node drops (downgrades) the packet because the link is 365 overloaded. 367 Otherwise it is metered by the Excess traffic Meter. 369 The Excess traffic Meter MUST have behaviour that is functionally 370 equivalent to the following. 372 The meter acts like a token bucket, which is sized in bits and has a 373 configured bit rate, termed PCN-excess-rate. The amount of tokens in 374 the token bucket is termed TB2.fill. Tokens are added at the PCN- 375 excess-rate, to a maximum value TB2.max. Tokens are removed equal to 376 the size in bits of the metered-packet, to a minimum TB2-fill=0. The 377 PCN-excess-rate is greater than (or equal to) the PCN-threshold-rate. 379 If the token bucket is empty (TB2.fill = 0), then the meter indicates 380 to the Marking function that the packet is to be excess-traffic- 381 marked. If the token bucket is within an MTU of being empty, then 382 the meter SHOULD indicate to the Marking function that the packet is 383 to be excess-traffic-marked; MTU means the maximum size of PCN- 384 packets on the link. Otherwise the meter does not indicate marking. 386 2.6. Marking function 388 If the packet is not a PCN-packet, then it MUST NOT be marked. A 389 PCN-packet MUST be marked to reflect the metering results by setting 390 its encoding state appropriately, as specified below. The encoding 391 states are defined values of the DSCP and ECN fields, as specified in 392 the appropriate encoding document, 393 [I-D.moncaster-pcn-baseline-encoding] or 394 [I-D.draft-moncaster-pcn-3-state-encoding]. 396 There are three possibilities, depending on how many encoding states 397 are available: 399 o if three encoding states are available (one for threshold-marked, 400 one for excess-traffic-marked and one for "not PCN-marked") then: 402 * the encoding state of a packet that has already been excess- 403 traffic-marked is not altered, whatever the meters indicate; 405 * Otherwise: 407 + if both meters indicate marking, then the packet is excess- 408 traffic-marked; 410 + if the threshold meter indicates marking and the excess 411 traffic meter doesn't, then threshold-marking is applied; 413 + if the excess traffic meter indicates marking and the 414 threshold traffic meter doesn't, then excess-traffic-marking 415 is applied; 417 + if neither meter indicates marking, then the packet's 418 encoding state is not altered. 420 o if two encoding states are available (one for threshold-marked and 421 one for "not PCN-marked") then: 423 * if the Threshold Meter indicates marking, then the packet is 424 threshold-marked; 426 * otherwise the packet's encoding state is not altered. 428 o if two encoding states are available (one for excess-traffic- 429 marked and one for "not PCN-marked") then: 431 * if the Excess traffic Meter indicates marking, then the packet 432 is excess-traffic-marked; 434 * otherwise the packet's encoding state is not altered. 436 3. IANA Considerations 438 This document makes no request of IANA. 440 Note to RFC Editor: this section may be removed on publication as an 441 RFC. 443 4. Security Considerations 445 See [I-D.ietf-pcn-architecture] 447 5. Acknowledgements 449 Michael Menth, Joe Babiarz, Anna Charny reviewed a preliminary 450 version of the -00 draft. 452 Thanks to those who've made comments on this draft: Michael Menth, 453 Joe Babiarz, Anna Charny, Ruediger Geib, Wei Gengyu, Fortune Huang. 455 All the work by many people in the PCN WG. 457 6. Changes 459 6.1. Changes from -00 to -01 461 o Traffic conditioning extensively re-written. 463 o New terms defined 465 o Changes resulting from split of encoding into two drafts, baseline 466 [I-D.moncaster-pcn-baseline-encoding] and extension 467 [I-D.draft-moncaster-pcn-3-state-encoding]. 469 o Minor changes to improve clarity. 471 7. Authors 473 Many people need to be added. 475 8. References 477 8.1. Normative References 479 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 480 Services in the Internet Architecture: an Overview", 481 RFC 1633, June 1994. 483 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 484 Requirement Levels", BCP 14, RFC 2119, March 1997. 486 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 487 "Definition of the Differentiated Services Field (DS 488 Field) in the IPv4 and IPv6 Headers", RFC 2474, 489 December 1998. 491 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 492 and W. Weiss, "An Architecture for Differentiated 493 Services", RFC 2475, December 1998. 495 [RFC3086] Nichols, K. and B. Carpenter, "Definition of 496 Differentiated Services Per Domain Behaviors and Rules for 497 their Specification", RFC 3086, April 2001. 499 8.2. Informative References 501 [I-D.draft-briscoe-tsvwg-byte-pkt-mark] 502 "Baseline Encoding and Transport of Pre-Congestion 503 Information", February 2008, . 506 [I-D.draft-charny-pcn-comparison] 507 "Pre-Congestion Notification Using Single Marking for 508 Admission and Termination", November 2007, . 512 [I-D.draft-moncaster-pcn-3-state-encoding] 513 "Baseline Encoding and Transport of Pre-Congestion 514 Information", June 2008, . 518 [I-D.ietf-pcn-architecture] 519 "Pre-Congestion Notification Architecture", February 2008, 520 . 523 [I-D.moncaster-pcn-baseline-encoding] 524 "Baseline Encoding and Transport of Pre-Congestion 525 Information", June 2008, . 529 [Menth] "Menth", 2008, . 532 Appendix A. Example algorithms 534 Note: This Appendix is informative, not normative. It is an example 535 of algorithms that implement Section 2 and is based on 536 [I-D.draft-charny-pcn-comparison] and [Menth]. 538 There is no attempt to optimise the algorithms. It implements the 539 metering and marking functions together. It is assumed that three 540 encoding states are available (one for threshold-marked, one for 541 excess-traffic-marked and one for "not PCN-marked"). It is assumed 542 that all metered-packets are PCN-packets and that the link is never 543 overloaded. 545 A.1. Threshold metering and marking 547 A token bucket with the following parameters: 549 o TB1.PCN-threshold-rate: token rate of token bucket (bits/second) 551 o TB1.max: depth of token bucket (bits) 553 o TB1.threshold: marking threshold of token bucket (bits) 555 o TB1.lastUpdate: time the token bucket was last updated (seconds) 557 o TB1.fill: amount of tokens in token bucket (bits) 559 A PCN-packet has the following parameters: 561 o packet.size: the size of the PCN-packet (bits) 563 o packet.mark: the PCN encoding state of the packet 565 In addition there are the parameters: 567 o now: the current time (seconds) 569 The following steps are performed when a PCN-packet arrives on a 570 link: 572 o TB1.fill = min(TB1.max, TB1.fill + (now - TB1.lastUpdate) * 573 TB1.PCN-threshold-rate); // add tokens to token bucket 575 o TB1.fill = max(0, TB1.fill - packet.size); // remove tokens from 576 token bucket 578 o if ((TB1.fill < TB1.threshold) AND (packet.mark != excess-traffic- 579 marked)) then packet.mark = threshold-marked; // do threshold 580 marking, but don't re-mark packets that are already excess- 581 traffic-marked 583 o TB1.lastUpdate = now 585 A.2. Excess traffic metering and marking 587 A token bucket with the following parameters: 589 o TB2.PCN-excess-rate: token rate of token bucket (bits/second) 591 o TB2.max: depth of TB in token bucket (bits) 592 o TB2.lastUpdate: time the token bucket was last updated (seconds) 594 o TB2.fill: amount of tokens in token bucket (bits) 596 A PCN-packet has the following parameters: 598 o packet.size: the size of the PCN-packet (bits) 600 o packet.mark: the PCN encoding state of the packet 602 In addition there are the parameters: 604 o now: the current time (seconds) 606 o MTU: the maximum transfer unit of the link (or the known maximum 607 size of PCN-packets on the link) (bits) 609 The following steps are performed when a PCN-packet arrives on a 610 link: 612 o TB2.fill = min(TB2.max, TB2.fill + (now - TB2.lastUpdate) * 613 TB2.PCN-excess-rate); // add tokens to token bucket 615 o if (packet.mark != excess-traffic-marked) then TB2.fill = max(0, 616 TB2.fill - packet.size); // remove tokens from token bucket, but 617 do not meter packets that are already excess-traffic-marked 619 o if (TB2.fill < MTU) then packet.mark = excess-traffic-marked; // 620 do (packet size independent) excess traffic marking 622 o TB1.lastUpdate = now 624 Appendix B. Implementation notes 626 Note: This Appendix is informative, not normative. It comments on 627 Section 2. 629 B.1. Scope 631 It may be known, eg by the design of the network topology, that some 632 links can never be pre-congested (even in unusual circumstances, eg 633 after the failure of some links). There is then no need to implement 634 PCN behaviour on those links. 636 The meter and marker can be implemented on the ingoing or outgoing 637 interface of a PCN-node. It may be that existing hardware can 638 support only one meter and marker per ingoing interface and one per 639 outgoing interface. Then for instance threshold metering and marking 640 could be run on all the ingoing interfaces and excess traffic 641 metering and marking on all the outgoing interfaces; note that the 642 same choice must be made for all the links in a PCN-domain to ensure 643 that the two metering behaviours are applied exactly once for all the 644 links. 646 Note that even if there are only two encoding states both the meters 647 are still implemented, in order to ease compatibility between 648 equipment and remove a configuration option and associated 649 complexity. Although this means that the Marking function ignores 650 indications from one of the meters, they might be logged or acted 651 upon in some other way, for example by the management system or an 652 explicit signalling protocol; such considerations are out of scope of 653 PCN. 655 B.2. Classify 657 Traffic that has a higher DiffServ priority than PCN, but shares the 658 same capacity, is metered as though it were PCN-traffic but cannot be 659 PCN-marked. This means that a meter may indicate a packet is to be 660 PCN-marked, but the Marking function knows it cannot be marked. It 661 is left open to the implementation exactly what to do in this case; 662 one simple possibility is to mark the next PCN-packet. Note that 663 unless the PCN-packets are a large fraction of all the metered- 664 packets then the PCN mechanisms may not work well. 666 Similar remarks can be made with respect to other-traffic. 668 B.3. Traffic conditioning 670 The objective of traffic conditioning is to minimise the queueing 671 delay suffered by metered-traffic at a PCN-node, since PCN-traffic 672 (and other-traffic) is expected to be inelastic traffic generated by 673 real time applications. "Overload" therefore means breaking this 674 objective. In practice it would be defined as exceeding a specific 675 traffic profile, typically based on a token bucket. If both PCN- 676 traffic and other-traffic is present then the details will depend on 677 how the router's implementation handles the two sorts of traffic, for 678 example it could have: 680 o a common traffic conditioner and a common queue for PCN-traffic 681 and other-traffic; 683 o separate traffic conditioners but a common queue; 685 o separate traffic conditioners and separate queues. 687 By conditioning traffic to a lower rate than the queue(s) can 688 schedule traffic, the number of packets in the queue(s) can be 689 minimised. 691 The choice of whether to drop or downgrade packets is left to the 692 operator. For example, if the traffic is expected to be voice then 693 dropping is simple and a small amount of dropping doesn't have much 694 audible effect. But the dropping of a video I-frame will lead to a 695 significant impact. Downgrading needs to be done carefully to avoid 696 re-ordering traffic. 698 In [RFC2475] shaping is given as another possible action ("the 699 process of delaying packets"). However, this is not suitable here as 700 the traffic is expected to come from real time applications. 702 Preferential dropping of excess-traffic-marked packets: Section 2.2 703 specifies: "If the level of metered-traffic is sufficiently high, 704 then ... if PCN-packets are dropped (or downgraded) then: excess- 705 traffic-marked PCN-packets SHOULD be preferentially dropped 706 (downgraded)". This avoids over-termination, with the CL/SM edge 707 behaviour, in the event of multiple bottlenecks in the PCN-domain 708 [I-D.draft-charny-pcn-comparison]. 710 Exactly what "preferentially dropped" means is left to the 711 implementation. It is also left to the implementation what to do if 712 there are no excess-traffic-marked PCN-packets available at a 713 particular instant. 715 721 Section 2.2 also specifies: "PCN-packets that are dropped 722 (downgraded) SHOULD NOT be metered by the Excess traffic Meter." 723 This avoids over-termination, with the CL/SM edge behaviour, in the 724 event of multiple bottlenecks [I-D.draft-charny-pcn-comparison]. 725 Effectively it means that traffic conditioning should be done before 726 the meter functions - which is natural. 728 B.4. Threshold metering 730 The description is in terms of a 'token bucket with threshold', 731 however the implementation is not standardised. For example, it 732 could equally well be implemented as a virtual queue 733 [I-D.ietf-pcn-architecture]. 735 The behaviour must be functionally equivalent to the description 736 above. "Functionally equivalent" is intended to allow implementation 737 freedom over matters such as: 739 742 o whether tokens are added to the token bucket at regular time 743 intervals or only when a packet is processed 745 o whether the new token bucket depth is calculated before or after 746 it is decided whether to mark the packet. The effect of this is 747 simply to shift the sequence of marks by one packet. 749 o when the token bucket is very nearly empty and a packet arrives 750 larger than TB1.fill, then the precise change in TB1.fill is up to 751 the implementation. A behaviour is functionally equivalent if 752 either precisely the same set of packets is marked, or if the set 753 is shifted by one packet. For instance, the following should all 754 be considered as "functionally equivalent": 756 * set TB1.fill = 0 and indicate threshold-mark to the Marking 757 function. 759 * check whether TB1.fill < TB1.threshold and if it is then 760 indicate threshold-mark to the Marking function; then set 761 TB1.fill = 0. 763 * leave TB1.fill unaltered and indicate threshold-mark to the 764 Marking function. 766 o similarly, when the token bucket is very nearly full and a packet 767 arrives large than (TB1.max - TB1.fill), then the precise change 768 in TB1.fill is up to the implementation. 770 o Note that all packets, even if already marked, are metered by the 771 threshold meter function (unlike the excess traffic meter function 772 - see below) - because all packets should contribute to the 773 decision whether there is room for a new flow. The threshold 774 meter 776 B.5. Excess traffic metering 778 The description is in terms of a token bucket, however the 779 implementation is not standardised. 781 As in Section B.3, "functionally equivalent" allows some 782 implementation flexibility when the token bucket is very nearly empty 783 or very nearly full. 785 Packet size independent marking is specified as a SHOULD in Section 786 2.4 ( "If the token bucket is within an MTU of being empty, then the 787 meter SHOULD indicate to the Marking function that the packet is to 788 be excess-traffic-marked; MTU means the maximum size of PCN-packets 789 on the link.") Without it, large packets are more likely to be 790 excess-traffic-marked than small packets and this means that, with 791 some edge behaviours, flows with large packets are more likely to be 792 terminated than flows with small packets 793 [I-D.draft-briscoe-tsvwg-byte-pkt-mark] [Menth]. 795 Section 2.4 specifies: "A packet SHOULD NOT be metered (by this 796 excess traffic meter function) ... If the packet is already excess- 797 traffic-marked". This avoids over-termination (with some edge 798 behaviours) in the event that the PCN-traffic passes through multiple 799 bottlenecks in the PCN-domain [I-D.draft-charny-pcn-comparison]. 800 Note that an implementation could determine whether the packet is 801 already excess-traffic-marked as an integral part of its 802 Classification function. 804 Section 2.4 specifies: "A packet SHOULD NOT be metered (by this 805 excess traffic meter function) ... If this PCN-node drops 806 (downgrades) the packet because the link is overloaded." This avoids 807 over-termination [Menth]. (A similar statement could also be made 808 for the threshold meter function, but is irrelevant, as a link that 809 is overloaded will already be substantially pre-congested and hence 810 PCN-marking all packets.) 812 Note that TB2.max is independent of TB1.max; TB2.fill is independent 813 of TB1.fill (except in that a packet changes both); and the two 814 configured rates, PCN-excess-rate and PCN-threshold-rate are 815 independent (except that PCN-excess-rate >= PCN-threshold-rate). 817 B.6. Marking 819 Although the metering functions are described separately from the 820 Marking function, they can be implemented in an integrated fashion. 822 [I-D.moncaster-pcn-baseline-encoding] specifies two encoding states 823 and [I-D.draft-moncaster-pcn-3-state-encoding] specifies three 824 encoding states. In some environments encoding states may be scarce, 825 for example MPLS, and then only two encoding states may be 826 preferable. 828 Section 2.6 states: "if three encoding states are available ... if 829 the threshold meter indicates marking and the excess traffic meter 830 doesn't, then threshold-marking is applied; if the excess traffic 831 meter indicates marking and the threshold traffic meter doesn't, then 832 excess-traffic-marking is applied". Normally this means that the 833 Threshold Meter indicates marking and the Excess traffic Meter 834 doesn't. However, the reverse is possible for a short time - because 835 the meters react at different speeds when the traffic rate changes. 837 Author's Address 839 Philip Eardley +++ 840 BT 841 Adastral Park, Martlesham Heath 842 Ipswich IP5 3RE 843 UK 845 Email: philip.eardley@bt.com 847 Full Copyright Statement 849 Copyright (C) The IETF Trust (2008). 851 This document is subject to the rights, licenses and restrictions 852 contained in BCP 78, and except as set forth therein, the authors 853 retain all their rights. 855 This document and the information contained herein are provided on an 856 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 857 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 858 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 859 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 860 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 861 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 863 Intellectual Property 865 The IETF takes no position regarding the validity or scope of any 866 Intellectual Property Rights or other rights that might be claimed to 867 pertain to the implementation or use of the technology described in 868 this document or the extent to which any license under such rights 869 might or might not be available; nor does it represent that it has 870 made any independent effort to identify any such rights. Information 871 on the procedures with respect to rights in RFC documents can be 872 found in BCP 78 and BCP 79. 874 Copies of IPR disclosures made to the IETF Secretariat and any 875 assurances of licenses to be made available, or the result of an 876 attempt made to obtain a general license or permission for the use of 877 such proprietary rights by implementers or users of this 878 specification can be obtained from the IETF on-line IPR repository at 879 http://www.ietf.org/ipr. 881 The IETF invites any interested party to bring to its attention any 882 copyrights, patents or patent applications, or other proprietary 883 rights that may cover technology that may be required to implement 884 this standard. Please address the information to the IETF at 885 ietf-ipr@ietf.org. 887 Acknowledgment 889 Funding for the RFC Editor function is provided by the IETF 890 Administrative Support Activity (IASA).