RFC 5670

Metering and Marking Behaviour of PCN-Nodes

📅 published November 2009, from ietf

Metering and Marking Behaviour of PCN-Nodes 🦋

okay bestie, this is RFC 5670, and it's giving Standards Track 💅 It's by P. Eardley (editor) from BT, dated November 2009. It doesn't obsolete or update anything, since no Obsoletes or Updates fields are listed. It's giving standalone main-character energy ✨

Abstract ✨

okay so the whole point of Pre-Congestion Notification (PCN) is to keep the quality of service (QoS) of inelastic flows safe inside a Diffserv domain 🛡️ and it does this in a simple, scalable, and robust way 💖 This doc defines the two metering and marking behaviours PCN-nodes can have. Threshold-metering and -marking marks all PCN-packets if the rate of PCN-traffic is higher than a configured rate (the "PCN-threshold-rate") 🚨 Excess-traffic-metering and -marking marks a proportion of PCN-packets, so the amount marked equals the PCN-traffic rate above a configured rate (the "PCN-excess-rate") 📊 That marking lets PCN-boundary-nodes decide whether to admit or terminate PCN-flows 🫶

Status of This Memo 📜

bestie, this document specifies an Internet standards track protocol for the Internet community 🌐 It also asks for discussion and suggestions for improvements 💬 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📖 Distribution of this memo is unlimited 🦋

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved ✨

So this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which are in effect on the date it was published. The link is http://trustee.ietf.org/license-info 🔗 Please read these carefully, because they describe your rights and restrictions for this document 🙈 Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the BSD License describes 💀

This document may also contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008 📚 The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 😭 So unless you get an adequate licence from whoever controls the copyright in those materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The one exceptions are formatting it for publication as an RFC, or translating it into languages other than English 🌈

Table of Contents 🗂️

   1. Introduction ....................................................2
      1.1. Terminology ................................................4
           1.1.1. Requirements Language ...............................5
   2. Specified PCN-Metering and -Marking Behaviours ..................5
      2.1. Behaviour Aggregate Classification Function ................5
      2.2. Dropping Function ..........................................5
      2.3. Threshold-Meter Function ...................................6
      2.4. Excess-Traffic-Meter Function ..............................6
      2.5. Marking Function ...........................................7
   3. Security Considerations .........................................7
   4. Acknowledgements ................................................8
   5. References ......................................................8
      5.1. Normative Reference ........................................8
      5.2. Informative References .....................................8
   Appendix A.  Example Algorithms ...................................11
     A.1.  Threshold-Metering and -Marking ...........................11
     A.2.  Excess-Traffic-Metering and -Marking ......................12
   Appendix B.  Implementation Notes .................................13
     B.1.  Competing-Non-PCN-Traffic .................................13
     B.2.  Scope .....................................................14
     B.3.  Behaviour Aggregate Classification ........................15
     B.4.  Dropping ..................................................15
     B.5.  Threshold-Metering ........................................17
     B.6.  Excess-Traffic-Metering ...................................18
     B.7.  Marking ...................................................19

1. Introduction ✨

okay so the objective is the same: keep the QoS of inelastic flows safe inside a Diffserv domain, in a simple, scalable, and robust way 🛡️ Two mechanisms do the work. The first is admission control, which decides whether to admit or block a new flow request 🚪 The second is flow termination, which happens in abnormal circumstances and decides whether to terminate some existing flows 💥 To make this work, the overall rate of PCN-traffic is metered on every link in the domain, and PCN-packets get marked when certain configured rates are exceeded 📏 Those configured rates sit below the rate of the link, so boundary nodes get notified about overloads before any congestion happens. That's why it's called "Pre-Congestion Notification" 🦋 The level of marking tells boundary nodes whether to admit or terminate. Inside the domain, PCN-traffic is forwarded in a prioritised Diffserv traffic class [RFC2475] 👑

This document defines the two metering and marking behaviours of PCN-nodes 🎀 Their whole aim is to give an "early warning" of potential congestion, before any significant build-up of PCN-packets shows up in their queues 🚨 Here are the objectives, in summary:

  • Threshold-metering and -marking: mark all PCN-packets (with a "threshold-mark") when the bit rate of PCN-traffic is greater than its configured reference rate (the "PCN-threshold-rate") 🔥
  • Excess-traffic-metering and -marking: when the bit rate of PCN-packets is greater than its configured reference rate (the "PCN-excess-rate"), mark PCN-packets (with an "excess-traffic-mark") at a rate equal to the difference between the rate of PCN-traffic and the PCN-excess-rate 🧚

Note that [RFC3168] defines a broadly RED-like (Random Early Detection) default congestion marking behaviour. It allows alternatives to be defined, and this document defines one such alternative 🌸

Section 2 below covers the functions involved. In outline (see Figure 1) they are:

  • Behaviour aggregate (BA) classification: decide whether or not an incoming packet is a PCN-packet 🔍
  • Dropping (optional): drop packets if the link is overloaded 🗑️
  • Threshold-meter: determine whether the bit rate of PCN-traffic exceeds its configured reference rate (PCN-threshold-rate). The meter operates on all PCN-packets on the link, and not on individual flows 📊
  • Excess-traffic-meter: measure by how much the bit rate of PCN-traffic exceeds its configured reference rate (PCN-excess-rate). The meter operates on all PCN-packets on the link, and not on individual flows 📈
  • PCN-mark: actually mark the PCN-packets, if the meter functions indicate to do so 🏷️
                                        +---------+    Result
                                     +->|Threshold|-------+
                                     |  |  Meter  |       |
                                     |  +---------+       V
         +----------+   +- - - - -+  |                +------+
         |   BA     |   |         |  |                |      |    Marked
Packet =>|Classifier|==>| Dropper |==?===============>|Marker|==> Packet
Stream   |          |   |         |  |                |      |    Stream
         +----------+   +- - - - -+  |                +------+
                                     |  +---------+       ^
                                     |  | Excess  |       |
                                     +->| Traffic |-------+
                                        |  Meter  |    Result
                                        +---------+

Figure 1: Schematic of PCN-interior-node functionality 🖼️

Appendix A gives an example of algorithms that fulfil the specification in Section 2, and Appendix B has explanations and comments on Section 2. Both Appendices are informative 💜 The general architecture for PCN is described in [RFC5559], and [Menth10] is an overview of PCN 📚

1.1. Terminology 📖

Besides the terminology defined in [RFC5559] and [RFC2474], the following terms are defined:

  • Competing-non-PCN-packet: a non-PCN-packet that shares a link with PCN-packets and competes with them for its forwarding bandwidth. Competing-non-PCN-packets MUST NOT be PCN-marked, since only PCN-packets can be PCN-marked 🚫

Note: In general, it is not advised to have any competing-non-PCN-traffic 🙅

Note: There is likely to be traffic (such as best effort) that is forwarded at lower priority than PCN-traffic. Although it shares the link with PCN-traffic, it doesn't compete for forwarding bandwidth, so it is not competing-non-PCN-traffic. See Appendix B.1 for further discussion about competing-non-PCN-traffic 🧃

  • Metered-packet: a packet that is metered by the metering functions specified in Sections 2.3 and 2.4. A PCN-packet MUST be treated as a metered-packet (with the minor exception noted below in Section 2.4). A competing-non-PCN-packet MAY be treated as a metered-packet 📏

1.1.1. Requirements Language 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 💅

2. Specified PCN-Metering and -Marking Behaviours 🧁

This section defines the two PCN-metering and -marking behaviours. The descriptions are functional, and they are not meant to restrict the implementation. The informative Appendices supplement this section ✨

2.1. Behaviour Aggregate Classification Function 🔍

A PCN-node MUST classify a packet as a PCN-packet if the value of its Differentiated Services Code Point (DSCP) and Explicit Congestion Notification (ECN) fields correspond to a PCN-enabled codepoint, as defined in the encoding scheme that applies to the PCN-domain. For example, [RFC5696] defines the baseline encoding 🫶 Otherwise, the packet MUST NOT be classified as a PCN-packet 🚫

A PCN-node MUST classify a packet as a competing-non-PCN-packet if it is not a PCN-packet and it competes with PCN-packets for its forwarding bandwidth on a link 🥊

2.2. Dropping Function 🗑️

Note: If the PCN-node's queue overflows, then packets are naturally dropped. This section describes additional action 💀

On all links in the PCN-domain, dropping MAY be done by first metering all metered-packets to find out whether the rate of metered-traffic on the link is greater than the rate allowed for such traffic. If the rate of metered-traffic is too high, then drop metered-packets 🌊

If the PCN-node drops PCN-packets, then:

  • PCN-packets that arrive at the PCN-node already excess-traffic-marked SHOULD be preferentially dropped 🫠
  • the PCN-node's excess-traffic-meter SHOULD NOT meter the PCN-packets that it drops 🙈

2.3. Threshold-Meter Function

okay bestie, every PCN-node MUST implement a threshold-meter 💅 and it has to behave functionally equivalent to the following 🎀

the meter is basically a token bucket ✨ sized in bits, with a configured reference rate in bits per second. the tokens sitting in the bucket are called F_tm. tokens get added at the reference rate (PCN-threshold-rate) up to a max of BS_tm. when a packet comes through, tokens get removed equal to its size in bits, but F_tm never goes below 0 🧚 (quick decoder ring: F is Fill, BS is bucket size, tm is threshold-meter)

the bucket also has a configured intermediate depth called threshold. if F_tm < threshold, the meter tells the marking function that the packet is to be threshold-marked. otherwise it doesn't 🫶

2.4. Excess-Traffic-Meter Function

a packet SHOULD NOT be metered by this excess-traffic-meter in these two cases:

  • if the PCN-packet is already excess-traffic-marked on arrival at the PCN-node.
  • if this PCN-node drops the packet.

otherwise the PCN-packet MUST be treated as a metered-packet, which means the excess-traffic-meter meters it 🦋

every PCN-node MUST implement an excess-traffic-meter. the excess-traffic-meter SHOULD indicate packets to be excess-traffic-marked no matter their size ("packet size independent marking") 📏. if "packet size independent marking" isn't implemented, then the excess-traffic-meter MUST use the "classic" metering behaviour 🌸

for the "classic" metering behaviour, the excess-traffic-meter has behaviour functionally equivalent to the following 💖

the meter acts like a token bucket, sized in bits, with a configured reference rate in bits per second. the tokens in the bucket are called F_etm. tokens are added at the reference rate (PCN-excess-rate) up to a max of BS_etm. tokens get removed equal to the size in bits of the metered-packet, but F_etm never goes below 0. if the bucket is empty (F_etm = 0), the meter tells the marking function that the packet is to be excess-traffic-marked 🔥 (abbreviations: F is Fill, BS is bucket size, etm is excess-traffic-meter)

for "packet size independent marking", the excess-traffic-meter has behaviour functionally equivalent to the following ✨

the meter acts like a token bucket, sized in bits, with a configured reference rate in bits per second. the tokens in the bucket are called F_etm. tokens are added at the reference rate (PCN-excess-rate) up to a max of BS_etm. if the token bucket is not negative, tokens get removed equal to the size in bits of the metered-packet, and the meter does not tell the marking function to excess-traffic-mark the packet. if the token bucket is negative (F_etm < 0), the meter tells the marking function to excess-traffic-mark the packet, and no tokens get removed 🙈 (abbreviations: F is Fill, BS is bucket size, etm is excess-traffic-meter)

otherwise, the meter MUST NOT indicate marking 🚫

2.5. Marking Function

a PCN-packet MUST be marked to reflect the metering results by setting its encoding state appropriately, as specified by the specific encoding scheme that applies in the PCN-domain 🎯 a consistent choice of encoding scheme MUST be made throughout a PCN-domain, no exceptions 👑

a PCN-node MUST NOT:

  • PCN-mark a packet that is not a PCN-packet;
  • change a non-PCN-packet into a PCN-packet;
  • change a PCN-packet into a non-PCN-packet.

note: although competing-non-PCN-packets MAY be metered, they MUST NOT be PCN-marked 🙅‍♀️

3. Security Considerations

ok this section is SERIOUS 😭 it is assumed that all PCN-nodes are PCN-enabled and are trusted for truthful PCN-metering and PCN-marking. if that isn't the case, then there are numerous potential attacks 💀 for instance, a rogue PCN-interior-node could PCN-mark all packets so that no flows were admitted. another possibility is that it doesn't PCN-mark any packets, even when it is pre-congested.

note that PCN-interior-nodes are not flow-aware. this prevents some security attacks where an attacker targets specific flows in the data plane, like Denial-of-Service (DoS) or eavesdropping 🛡️

as regards Security Operations and Management, PCN adds few specifics to the general good practice required in this field [RFC4778]. for example, it may be sensible for a PCN-node to raise an alarm if it is persistently PCN-marking 🚨

security considerations are further discussed in [RFC5559] 📚

4. Acknowledgements

this document is the result of extensive collaboration within the PCN WG 🫶 amongst the most active other contributors to the ideas specified in this document have been Jozef Babiarz, Bob Briscoe, Kwok-Ho Chan, Anna Charny, Georgios Karagiannis, Michael Menth, Toby Moncaster, Daisuke Satoh, and Joy Zhang. Appendix A is based on text from Michael Menth 💜

this document is a development of [Briscoe06-2]. its authors are therefore also contributors to this document: Jozef Babiarz, Attila Bader, Bob Briscoe, Kwok-Ho Chan, Anna Charny, Stephen Dudley, Philip Eardley, Georgios Karagiannis, Francois Le Faucheur, Vassilis Liatsos, Dave Songhurst, and Lars Westberg 🌈

thanks to those who've made comments on the document: Joe Babiarz, Fred Baker, David Black, Bob Briscoe, Ken Carlberg, Anna Charny, Ralph Droms, Mehmet Ersue, Adrian Farrel, Ruediger Geib, Wei Gengyu, Fortune Huang, Christian Hublet, Ingemar Johansson, Georgios Karagiannis, Alexey Melnikov, Michael Menth, Toby Moncaster, Dimitri Papadimitriou, Tim Polk, Daisuke Satoh, and Magnus Westerlund 🍓

5. References

5.1. Normative Reference

[RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

5.2. Informative References

[Baker08]      Baker, F., Polk, J., and M. Dolly, "DSCP for Capacity-
               Admitted Traffic", Work in Progress, November 2008.

[Briscoe06-1]  Briscoe, B., Eardley, P., Songhurst, D., Le Faucheur,
               F., Charny, A., Babiarz, J., Chan, K., Dudley, S.,
               Karagiannis, G., Bader, A., and L. Westberg, "An edge-
               to-edge Deployment Model for Pre-Congestion
               Notification: Admission Control over a DiffServ
               Region", Work in Progress, October 2006.

[Briscoe06-2]  Briscoe, B., Eardley, P., Songhurst, D., Le Faucheur,
               F., Charny, A., Liatsos, V., Babiarz, J., Chan, K.,
               Dudley, S., Karagiannis, G., Bader, A., and L.
               Westberg, "Pre-Congestion Notification marking", Work
               in Progress, October 2006.

[Briscoe08]    Briscoe, B., "Byte and Packet Congestion
               Notification", Work in Progress, August 2008.

[Charny07]     Charny, A., Babiarz, J., Menth, M., and X. Zhang,
               "Comparison of Proposed PCN Approaches", Work
               in Progress, November 2007.

[Menth10]      Menth, M., Lehrieder, F., Briscoe, B., Eardley, P.,
               Moncaster, T., Babiarz, J., Chan, K., Charny, A.,
               Karagiannis, G., Zhang, X., Taylor, T., Satoh, D., and
               R. Geib, "A Survey of PCN-Based Admission Control and
               Flow Termination", IEEE Communications Surveys and
               Tutorials, 2010 (third issue), <http://
               www3.informatik.uni-wuerzburg.de/staff/menth/
               Publications/papers/Menth08-PCN-Overview.pdf>.

[RFC2474]      Nichols, K., Blake, S., Baker, F., and D. Black,
               "Definition of the Differentiated Services Field (DS
               Field) in the IPv4 and IPv6 Headers", RFC 2474,
               December 1998.

[RFC2475]      Blake, S., Black, D., Carlson, M., Davies, E., Wang,
               Z., and W. Weiss, "An Architecture for Differentiated
               Services", RFC 2475, December 1998.

[RFC3168]      Ramakrishnan, K., Floyd, S., and D. Black, "The
               Addition of Explicit Congestion Notification (ECN) to
               IP", RFC 3168, September 2001.

[RFC4778]      Kaeo, M., "Operational Security Current Practices in
               Internet Service Provider Environments", RFC 4778,
               January 2007.

[RFC5127]      Chan, K., Babiarz, J., and F. Baker, "Aggregation of
               DiffServ Service Classes", RFC 5127, February 2008.

[RFC5559]      Eardley, P., "Pre-Congestion Notification (PCN)
               Architecture", RFC 5559, June 2009.

[RFC5696]      Moncaster, T., Briscoe, B., and M. Menth, "Baseline
               Encoding and Transport of Pre-Congestion Information",
               RFC 5696, November 2009.

[Taylor09]     Charny, A., Huang, F., Menth, M., and T. Taylor, "PCN
               Boundary Node Behaviour for the Controlled Load (CL)
               Mode of Operation", Work in Progress, March 2009.

Appendix A. Example Algorithms

note: this Appendix is informative, not normative 📝 it's an example of algorithms that implement Section 2 and is based on [Charny07] and [Menth10].

there is no attempt to optimise the algorithms 🧠 the metering and marking functions are implemented together. it is assumed that three encoding states are available (one for threshold-marked, one for excess-traffic-marked, and one for not-marked). it is also assumed that all metered-packets are PCN-packets and that the link is never overloaded. for excess-traffic-marking, "packet size independent marking" applies 🦋

A.1. Threshold-Metering and -Marking

a token bucket with the following parameters:

  • PCN-threshold-rate: token rate of token bucket (bits/second)
  • BS_tm: depth of token bucket (bits)
  • threshold: marking threshold of token bucket (bits)
  • lastUpdate: time the token bucket was last updated (seconds)
  • F_tm: amount of tokens in token bucket (bits)

a PCN-packet has the following parameters:

  • packet_size: the size of the PCN-packet (bits)
  • packet_mark: the PCN encoding state of the packet

in addition there is the parameter:

  • now: the current time (seconds)

the following steps are performed when a PCN-packet arrives on a link 🎀

*  F_tm = min(BS_tm, F_tm + (now - lastUpdate) * PCN-threshold-
   rate); // add tokens to token bucket

*  F_tm = max(0, F_tm - packet_size); // remove tokens from token
   bucket

*  if ((F_tm < threshold) AND (packet_mark != excess-traffic-
   marked)) then packet_mark = threshold-marked; // do threshold-
   marking, but don't re-mark packets that are already excess-
   traffic-marked

*  lastUpdate = now // Note: 'now' has the same value as in step 1

A.2. Excess-Traffic-Metering and -Marking 💖

okay so this is the excess-traffic meter, and it's basically a token bucket doing its thing 🪣✨ it keeps track of these parameters:

  • PCN-excess-rate: token rate of token bucket (bits/second)
  • BS_etm: depth of TB in token bucket (bits)
  • lastUpdate: time the token bucket was last updated (seconds)
  • F_etm: amount of tokens in token bucket (bits)

every PCN-packet brings its own parameters to the party 🎀

  • packet_size: the size of the PCN-packet (bits)
  • packet_mark: the PCN encoding state of the packet

and there's one more thing it looks at: 🕰️

  • now: the current time (seconds)

here's what happens when a PCN-packet arrives on a link, step by step 👀

F_etm = min(BS_etm, F_etm + (now - lastUpdate) * PCN-excess-
   rate); // add tokens to token bucket

if (packet_mark != excess-traffic-marked) then // do not meter
   packets that are already excess-traffic-marked

   +  if (F_etm < 0) then packet_mark = excess-traffic-marked; //
      do excess-traffic-marking.  The algorithm ensures this is
      independent of packet size

   +  else F_etm = F_etm - packet_size; // remove tokens from
      token bucket if don't mark packet

lastUpdate = now // Note: 'now' has the same value as in step 1

so the bucket gets topped up first (capped at BS_etm), then packets that aren't already excess-traffic-marked either get marked if the bucket has gone negative, or have their size taken out of the bucket if they don't get marked. then lastUpdate gets set to now 🫶

Appendix B. Implementation Notes 🧚

Note: This Appendix is informative, not normative. It comments on Section 2, including reasoning about whether MUSTs or SHOULDs are required. For guidance on Operations and Management considerations, please see [RFC5559].

this appendix is the cozy behind-the-scenes chat about why things are the way they are 🧸

B.1. Competing-Non-PCN-Traffic 🚧

it's generally not advised to have any competing-non-PCN-traffic, lowkey because the unpredictable amount of it makes the PCN mechanisms less accurate, which means PCN has less ability to protect the QoS of admitted PCN-flows [RFC5559]. but if there is competing-non-PCN-traffic, then:

  1. There should be a mechanism to limit it, for example:
    • limit the rate at which competing-non-PCN-traffic can be forwarded on each link in the PCN-domain. One method for achieving this is to queue competing-non-PCN-packets separately from PCN-packets and to limit the scheduling rate of the former. Another method is to drop competing-non-PCN-packets in excess of some rate.
    • police competing-non-PCN-traffic at the PCN-ingress-nodes, as in the Diffserv architecture, for example. However, Diffserv's static traffic conditioning agreements risk a focused overload of traffic from several PCN-ingress-nodes onto one link.
    • by design, it is known that the level of competing-non-PCN-traffic is always very small -- perhaps it consists of operator control messages only.
  2. In general, PCN's mechanisms should take account of competing-non-PCN-traffic, in order to improve the accuracy of the decision about whether to admit (or terminate) a PCN-flow. For example:
    • competing-non-PCN-traffic contributes to the PCN-meters; competing-non-PCN-packets are treated as metered-packets.
    • each PCN-node, on its links: (1) reduces the reference rates (PCN-threshold-rate and PCN-excess-rate), in order to allow 'headroom' for the competing-non-PCN-traffic; (2) limits the maximum forwarding rate of competing-non-PCN-traffic to be less than the 'headroom'. In this case, competing-non-PCN-packets are not treated as metered-packets.
  3. The operator should decide on appropriate action. Dropping is discussed further in Appendix B.4.

one specific example of competing-non-PCN-traffic is when the PCN-compatible Diffserv codepoint is one of those that [Baker08] defines as suitable for use with admission control, and there's that kind of non-PCN-traffic in the PCN-domain. a similar example could happen for Diffserv codepoints of the Real-Time Treatment Aggregate [RFC5127]. in those cases, PCN-traffic and competing-non-PCN-traffic are told apart by different values of the ECN field [RFC5696] 💅

another example: if there's more than one PCN-compatible Diffserv codepoint in a PCN-domain. say there are two PCN-BAs treated at different priorities. then, as far as the lower priority PCN-BA is concerned, the higher priority PCN-traffic needs to be treated as competing-non-PCN-traffic 👑

B.2. Scope 🗺️

it might be known, for instance from the design of the network topology, that some links can never be pre-congested (even in unusual circumstances, like after the failure of some links). then there's no need to deploy the PCN-metering and -marking behaviour on those links 🙅‍♀️

the meters can be implemented on the ingoing or outgoing interface of a PCN-node. existing hardware might only support one meter per ingoing interface and one per outgoing interface. then, for instance, threshold-metering could run on all the ingoing interfaces and excess-traffic-metering on all the outgoing interfaces. just note that the same choice must be made for all the links in a PCN-domain, so the two metering behaviours are applied exactly once for all the links 🔁

the baseline encoding [RFC5696] only specifies two encoding states (PCN-marked and not-marked). in this case, "excess-traffic-marked" means a packet that is PCN-marked as a result of the excess-traffic-meter function, and "threshold-marked" means a packet that is PCN-marked as a result of the threshold-meter function. as far as terminology goes, this interpretation is consistent with the one defined in [RFC5559]. also, a deployment needs to make a consistent choice throughout the PCN-domain on whether PCN-marked is interpreted as excess-traffic-marked or threshold-marked 🎯

even if there are only two encoding states, it's still required that both meters are implemented, so equipment stays compatible and there's no extra configuration option (and the complexity that comes with it) 💜 hardware with limited availability of token buckets could be configured to run only one of the meters, but it must be possible to enable either meter. and although, in the two-encoding-state scenario, indications from one of the meters are ignored by the marking function, they may be logged or acted upon in some other way, for example by the management system or an explicit signalling protocol. those considerations are out of scope for this document 🙈

B.3. Behaviour Aggregate Classification 🏷️

the configuration of PCN-nodes defines which values of the DSCP and ECN fields indicate a PCN-packet in a particular PCN-domain. for instance, [RFC5696] defines the baseline encoding 🩵

configuration also defines which values of the DSCP and ECN fields indicate a competing-non-PCN-packet in a particular PCN-domain 🌈

B.4. Dropping 🪂

the whole point of the dropping function is to minimise the queueing delay that metered-traffic suffers at a PCN-node, since PCN-traffic (and maybe competing-non-PCN-traffic) is expected to be inelastic traffic generated by real-time applications. in practice, it would be defined as exceeding a specific traffic profile, typically based on a token bucket 🪣

if there's no competing-non-PCN-traffic, it's not expected that the dropping function is needed, since PCN's flow admission and termination mechanisms already limit the amount of PCN-traffic. even so, it still might be implemented as a back stop against misconfiguration of the PCN-domain, for instance 🛟

if there is competing-non-PCN-traffic, then the details of the dropping function depend on how the router's implementation handles the two sorts of traffic:

  1. a common queue for PCN-traffic and competing-non-PCN-traffic, with a traffic conditioner for the competing-non-PCN-traffic; or
  2. separate queues, in which case the amount of competing-non-PCN-traffic can be limited by limiting the rate at which the scheduler (for the competing-non-PCN-traffic) forwards packets.

(The discussion here is based on that in [Baker08].) note that only dropping of packets is allowed. downgrading packets to a lower priority BA is not allowed (see Appendix B.7), since it would lead to packet mis-ordering. shaping ("the process of delaying packets" [RFC2475]) isn't suitable if the traffic comes from real-time applications 🚫

Preferential dropping of competing-non-PCN-traffic: in general, it's reasonable for competing-non-PCN-traffic to get harsher treatment than PCN-traffic (that is, competing-non-PCN-packets are preferentially dropped) because PCN's flow admission and termination mechanisms are stronger than the mechanisms likely to be applied to the competing-non-PCN-traffic. the PCN mechanisms also mean a dropper should not be needed for the PCN-traffic 💪

Preferential dropping of excess-traffic-marked packets: Section 2.2 specifies, "If the PCN-node drops PCN-packets, then ... PCN-packets that arrive at the PCN-node already excess-traffic-marked SHOULD be preferentially dropped". in brief, the reason is that, with the "controlled load" edge behaviour [Taylor09], this avoids over-termination when there are multiple bottlenecks in the PCN-domain [Charny07]. here's the fuller explanation 🧠 the optimal dropping behaviour depends on the particular edge behaviour [Menth10]. a single dropping behaviour is defined, because it's simpler to standardise, implement, and operate. the standardised dropping behaviour is at least adequate for all edge behaviours (and good for some), whereas others aren't. for example, with tail dropping, far too much traffic may be terminated with the "controlled load" edge behaviour when there are multiple bottlenecks in the PCN-domain [Charny07]. the dropping behaviour is defined as a 'SHOULD', rather than a 'MUST', in recognition that other dropping behaviour may be preferred in particular circumstances. for example: (1) with the "marked flow" termination edge behaviour, preferential dropping of unmarked packets may be better [Menth10]; (2) tail dropping may make PCN-marking behaviour easier to implement on current routers ✨

exactly what "preferentially dropped" means is left to the implementation. it's also left to the implementation what to do if there are no excess-traffic-marked PCN-packets available at a particular instant 🤷‍♀️

Section 2.2 also specifies, "the PCN-node's excess-traffic-meter SHOULD NOT meter the PCN-packets that it drops." this avoids over-termination [Menth10]. effectively, it means the dropping function (if present) should happen before the meter functions, which is honestly super natural 🥰

B.5. Threshold-Metering ✨

okay so the threshold-meter is described as a 'token bucket with threshold' 🪣, and [Briscoe06-1] views it as a virtual queue 🫶. the description is NOT trying to standardise how you build it though, so you get implementation freedom bestie 💅

The reference rate of the threshold-meter (PCN-threshold-rate) is configured at less than the rate allocated to the PCN-traffic class. Also, the PCN-threshold-rate is less than, or possibly equal to, the PCN-excess-rate. 🌸

Section 2.3 says, "If F_tm < threshold, then the meter indicates to the marking function that the packet is to be threshold-marked; otherwise, it does not." 💖 Note that a PCN-packet gets marked without any extra bias for its size, so big packets don't get special treatment here.

The behaviour MUST be functionally equivalent to the description in Section 2.3. "Functionally equivalent" means the observable 'black box' behaviour is the same or very similar. For example, it counts if precisely the same set of packets is marked, or if the set is shifted by one packet. This gives you room to play with stuff like:

  • whether tokens get added to the token bucket at regular time intervals or only when a packet is processed ⏰
  • whether the new token bucket depth is calculated before or after you decide whether to PCN-mark the packet. The effect is just that the sequence of marks shifts by one packet 🎀
  • when the token bucket is very nearly empty and a packet arrives larger than F_tm, the precise change in F_tm is up to you. For instance:
    • set F_tm = 0 and indicate threshold-mark to the marking function 🧚
    • check whether F_tm < threshold and if it is, indicate threshold-mark to the marking function; then set F_tm = 0 ✨
    • leave F_tm unaltered and indicate threshold-mark to the marking function 🦋
  • similarly, when the token bucket is very nearly full and a packet arrives larger than (BS_tm - F_tm), the precise change in F_tm is up to the implementation 🍓

Note that ALL PCN-packets, even if already marked, get metered by the threshold-meter function (unlike the excess-traffic-meter function), because every packet should count toward the decision on whether there's room for a new flow. main character energy 👑

B.6. Excess-Traffic-Metering 🔥

The description is in terms of a token bucket, but the implementation is not standardised. 🪣

The reference rate of the excess-traffic-meter (PCN-excess-rate) is configured at less than (or possibly equal to) the rate allocated to the PCN-traffic class. Also, the PCN-excess-rate is greater than, or possibly equal to, the PCN-threshold-rate. 🌈

Just like in Section B.5, "functionally equivalent" gives some implementation flexibility, for example around the exact algorithm when the token bucket is very nearly empty or very nearly full. 🫧

Section 2.4 says, "A packet SHOULD NOT be metered (by this excess-traffic-meter function) ... if the packet is already excess-traffic-marked on arrival at the PCN-node". This avoids over-termination (with some edge behaviours) if the PCN-traffic passes through multiple bottlenecks in the PCN-domain [Charny07]. 💅 An implementation could work out whether the packet is already excess-traffic-marked as an integral part of its BA classification function. This is a 'SHOULD NOT' and NOT a 'MUST NOT' because it may be slightly harder to implement than a metering function that's blind to previous packet markings. 🙈

Section 2.4 also says, "A packet SHOULD NOT be metered (by this excess-traffic-meter function) ... if this PCN-node drops the packet." This avoids over-termination [Menth10]. (A similar statement could be made for the threshold-meter function too, but it's irrelevant, because a link that's overloaded will already be substantially pre-congested and hence threshold-marking all packets.) It seems natural to do the dropping function before the metering functions, although for some equipment that may be harder to implement. So this is a 'SHOULD NOT' rather than a 'MUST NOT'. 🍓

"Packet size independent marking" (excess-traffic-marking that doesn't depend on packet size) is specified as a 'SHOULD' rather than a 'MUST' in Section 2.4, because it may be slightly harder for some equipment to implement. The impact of not doing it is undesirable but moderate: enough traffic still gets terminated, but flows with large packets are more likely to be terminated. 🥺

With the "classic" excess-traffic-meter behaviour, large packets are more likely to be excess-traffic-marked than small ones (because packets get marked if the number of tokens in the token bucket is smaller than the packet size). So with some edge behaviours, flows with large packets are more likely to get terminated than flows with small packets ([Briscoe08], [Menth10]). 😭

"Packet size independent marking" can be achieved with a small tweak to the "classic" excess-traffic-meter. The number of tokens in the bucket can go negative. If that number is negative when a packet arrives, the packet is marked. Otherwise, an amount of tokens equal to the packet size gets removed from the bucket. Note that with "packet size independent marking", either the packet is marked or tokens are removed, NEVER both. So the token bucket can't become more negative than the maximum packet size on the link. The algorithm described in Appendix A implements this behaviour. ✨

Note that BS_etm is independent of BS_tm, F_etm is independent of F_tm (except that a packet can change both), and the two configured rates (PCN-excess-rate and PCN-threshold-rate) are independent (except that PCN-excess-rate >= PCN-threshold-rate). 🎀

B.7. Marking 💜

Section 2.5 defines, "A PCN-node MUST NOT ...change a PCN-packet into a non-PCN-packet". This means a PCN-node isn't allowed to downgrade a PCN-packet into a lower priority Diffserv BA. So downgrading is NOT an alternative to dropping. 🙅‍♀️

Section 2.5 also defines, "A PCN-node MUST NOT ...PCN-mark a packet that is not a PCN-packet". This matters in the scenario where competing-non-PCN-packets are treated as metered-packets. A meter might indicate a packet should be PCN-marked, but the marking function knows it can't be marked. It's left open to the implementation exactly what to do here. One simple option is to mark the next PCN-packet. Note that unless the PCN-packets are a large fraction of all the metered-packets, the PCN mechanisms may not work well. 🌸

Although the metering functions are described separately from the marking function, they can be implemented in an integrated fashion. 🧚

Author's Address 🎀

Philip Eardley (editor) BT Adastral Park, Martlesham Heath Ipswich IP5 3RE UK

EMail: philip.eardley@bt.com

📦 where this page comes from