RFC 5559
Pre-Congestion Notification (PCN) Architecture
Pre-Congestion Notification (PCN) Architecture ✨
Okay bestie, first the paperwork 💅 This is RFC 5559, published in June 2009 by the Network Working Group. The lead author is P. Eardley, listed as editor ("Ed."), from BT 🎀 It's marked as Informational, and the title block doesn't list anything it obsoletes or updates.
Status of This Memo 📜
Okay so this memo is just giving information to the Internet community 🦋 It does NOT specify an Internet standard of any kind, so no pressure to implement it as a rule. Distribution is unlimited, so share it with everyone 💜
Copyright Notice ⚖️
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved 🌸
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as they stood on the publication date. You can read them at http://trustee.ietf.org/license-info. Read them carefully, bestie, because they explain your rights and restrictions for this document 🧐
This document may contain material from IETF Documents or IETF Contributions 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 a proper license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be made outside that process either. The one exceptions are formatting it for publication as an RFC and translating it into languages other than English 🌈
Abstract 🔮
This document describes a general architecture for flow admission and termination based on pre-congestion information. The goal is to protect the quality of service of established, inelastic flows within a single Diffserv domain 💖
Table of Contents 🗂️
1. Introduction ....................................................3
1.1. Overview of PCN ............................................3
1.2. Example Use Case for PCN ...................................4
1.3. Applicability of PCN .......................................7
1.4. Documents about PCN ........................................8
2. Terminology .....................................................9
3. High-Level Functional Architecture .............................11
3.1. Flow Admission ............................................13
3.2. Flow Termination ..........................................14
3.3. Flow Admission and/or Flow Termination When There Are Only
Two PCN Encoding States ...................................15
3.4. Information Transport .....................................16
3.5. PCN-Traffic ...............................................16
3.6. Backwards Compatibility ...................................17
4. Detailed Functional Architecture ...............................18
4.1. PCN-Interior-Node Functions ...............................19
4.2. PCN-Ingress-Node Functions ................................19
4.3. PCN-Egress-Node Functions .................................20
4.4. Admission Control Functions ...............................21
4.5. Flow Termination Functions ................................22
4.6. Addressing ................................................22
4.7. Tunnelling ................................................23
4.8. Fault Handling ............................................25
5. Operations and Management ......................................25
5.1. Fault Operations and Management ...........................25
5.2. Configuration Operations and Management ...................26
5.2.1. System Options .....................................27
5.2.2. Parameters .........................................28
5.3. Accounting Operations and Management ......................30
5.4. Performance and Provisioning Operations and Management ....30
5.5. Security Operations and Management ........................31
6. Applicability of PCN ...........................................32
6.1. Benefits ..................................................32
6.2. Deployment Scenarios ......................................33
6.3. Assumptions and Constraints on Scope ......................35
6.3.1. Assumption 1: Trust and Support of PCN -
Controlled Environment .............................36
6.3.2. Assumption 2: Real-Time Applications ...............36
6.3.3. Assumption 3: Many Flows and Additional Load .......37
6.3.4. Assumption 4: Emergency Use Out of Scope ...........37
6.4. Challenges ................................................37
7. Security Considerations ........................................40
8. Conclusions ....................................................41
9. Acknowledgements ...............................................41
10. References ....................................................42
10.1. Normative References .....................................42
10.2. Informative References ...................................42
Appendix A. Possible Future Work Items ...........................48
A.1. Probing .................................................50
A.1.1. Introduction ....................................50
A.1.2. Probing Functions ...............................50
A.1.3. Discussion of Rationale for Probing, Its
Downsides and Open Issues .......................511. Introduction 🚀
1.1. Overview of PCN 💫
Okay so the whole point of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows inside a Diffserv domain, and it does this in a simple, scalable, and robust way 🫶 There are two mechanisms. Admission control decides whether to admit or block a brand-new flow request. In abnormal circumstances, flow termination decides whether to kick out some of the flows that already exist 👑
Here's how it works. 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 link's own rate, so boundary nodes get warned about overloads before any congestion actually happens. That's where the name "Pre-Congestion Notification" comes from ✨ The level of marking tells the boundary nodes whether to admit or terminate.
Within a PCN-domain, PCN-traffic is forwarded in a prioritised Diffserv traffic class 💅 Every link in the PCN-domain is configured with two rates, the PCN-threshold-rate and the PCN-excess-rate. If the overall rate of PCN-traffic on a link goes over a configured rate, a PCN-interior-node marks PCN-packets appropriately. The PCN-egress-nodes use that information to make their admission control and flow termination decisions 🧠
Flow admission control figures out whether a new flow can get in without any impact on the QoS of existing PCN-flows, in normal circumstances. But in abnormal circumstances (say a disaster takes out several nodes and traffic gets re-routed), the QoS of existing PCN-flows can still degrade, even if everyone was careful when those flows were admitted 😭 That's where flow termination comes in. It removes enough traffic to protect the QoS of the flows that are left 🦋
All PCN-boundary-nodes and PCN-interior-nodes are PCN-enabled, and they are trusted for correct PCN operation 🔐 PCN-ingress-nodes police arriving packets to check that each one is part of an admitted PCN-flow that stays within its agreed flowspec. That means they maintain per-flow state. PCN-interior-nodes meter all PCN-traffic, so they don't need to keep any per-flow state at all 🧚
Decisions about flow admission and termination are made for a particular pair of PCN-boundary-nodes. So PCN-egress-nodes must be able to identify which PCN-ingress-node sent each PCN-packet 💖
1.2. Example Use Case for PCN 🎀
Okay this section walks through an end-to-end QoS scenario that uses the PCN mechanisms inside one domain. The parts outside the PCN-domain are out of scope for PCN, but they're in here so you can see how PCN could be used 🌸 Just know this is only an example. There are other possibilities (see Section 3) for how the PCN-boundary-nodes can do admission control and flow termination, so don't treat this as the only way 💅
Every link in the PCN-domain runs the following as a fundamental building block. Check out [Eardley09] and Figure 1 for the visual 🦋
- A threshold meter and marker. It marks all PCN-packets if the rate of PCN-traffic is greater than a first configured rate, the PCN-threshold-rate. The admission control mechanism limits the PCN-traffic on each link to roughly its PCN-threshold-rate.
- An excess-traffic meter and marker. It marks a proportion of PCN-packets, and the amount it marks equals the traffic rate in excess of a second configured rate, the PCN-excess-rate. The flow termination mechanism limits the PCN-traffic on each link to roughly its PCN-excess-rate.
Overall, the aim is to give an "early warning" of potential congestion before there's any significant build-up of PCN-packets in the queue on the link 🚨 We call this "Pre-Congestion Notification" by analogy with ECN (Explicit Congestion Notification, [RFC3168]). Also, the link only meters the bulk PCN-traffic. It doesn't meter per flow 🍓
== Metering & ==
==Marking behaviour== ==PCN mechanisms==
^
Rate of ^
PCN-traffic on |
bottleneck link |
|
| Some pkts Terminate some
| excess-traffic-marked admitted flows
| & &
| Rest of pkts Block new flows
| threshold-marked
|
PCN-excess-rate -|------------------------------------------------The first part of this example stays clear: the PCN-marked and threshold-marked traffic on the graph decides whether new flows get in or get blocked. 💖
(=PCN-supportable-rate)|
| All pkts Block new flows
| threshold-marked
|
PCN-threshold-rate -|------------------------------------------------
(=PCN-admissible-rate)|
| No pkts Admit new flows
| PCN-marked
|Figure 1: Example of how the PCN admission control and flow termination mechanisms operate as the rate of PCN-traffic increases. 📈
The two forms of PCN-marking are shown by setting the ECN and DSCP (Differentiated Services Codepoint [RFC2474]) fields to known values that are configured for the domain. 🎀 That means the PCN-egress-nodes can watch the PCN-markings and measure how bad the pre-congestion is. ✨ Also, the PCN-ingress-nodes need to set the ECN and DSCP fields to whatever is configured for an unmarked PCN-packet, and the PCN-egress-nodes need to switch those values back to the ones that make sense outside the PCN-domain. 🔄
For admission control, this example assumes end-to-end RSVP (Resource Reservation Protocol) [RFC2205]) signalling. 💅 The PCN-domain counts as a single RSVP hop. The PCN-domain runs Diffserv, and we assume PCN-traffic is scheduled with the expedited forwarding (EF) per-hop behaviour [RFC3246]. 🦋 So the whole solution fits the "IntServ over Diffserv" framework defined in [RFC2998], as shown in Figure 2. 👑
___ ___ _______________________________________ ____ ___
| | | | | PCN- PCN- PCN- | | | | |
| | | | |ingress interior egress| | | | |
| | | | | -node -nodes -node | | | | |
| | | | |-------+ +-------+ +-------+ +------| | | | |
| | | | | | | PCN | | PCN | | | | | | |
| |..| |..|Ingress|..|meter &|..|meter &|..|Egress|..| |..| |
| |..| |..|Policer|..|marker |..|marker |..|Meter |..| |..| |
| | | | |-------+ +-------+ +-------+ +------| | | | |
| | | | | \ / | | | | |
| | | | | \ / | | | | |
| | | | | \ PCN-feedback-information / | | | | |
| | | | | \ (for admission control) / | | | | |
| | | | | --<-----<----<----<-----<-- | | | | |
| | | | | PCN-feedback-information | | | | |
| | | | | (for flow termination) | | | | |
|___| |___| |_______________________________________| |____| |___|
Sx Access PCN-domain Access Rx
End Network Network End
Host Host
<---- signalling across PCN-domain--->
(for admission control & flow termination)
<-------------------end-to-end QoS signalling protocol--------------->Figure 2: Example of possible overall QoS architecture. 🗺️
Here's the vibe: a source that wants a brand-new QoS flow sends an RSVP PATH message. 🚀 Normal hop-by-hop IntServ [RFC1633] handles the bit outside the PCN-domain (we assume that goes successfully 🙏). The PATH message travels across the PCN-domain, and the PCN-egress-node reads the PHOP (previous RSVP hop) object to figure out which specific PCN-ingress-node this flow came from. 🕵️♀️ Then the RESV message travels back from the receiver and prompts the PCN-egress-node to check what fraction of the PCN-traffic from that PCN-ingress-node is currently being threshold-marked. 📊 It adds an object with that info onto the RESV message, so the PCN-ingress-node finds out how pre-congested the path is. 🫶 If that level is below some threshold, the PCN-ingress-node admits the new flow into the PCN-domain. 🎉
The RSVP message also tells the PCN-ingress-node to install two normal IntServ items: five-tuple information, so it can spot data packets that belong to a previously admitted PCN-flow, and a traffic profile, so it can police the flow to stay within its reservation. 💅 Similarly, the RSVP message triggers the PCN-egress-node to install five-tuple and PHOP information, so it can identify packets as part of a flow from a specific PCN-ingress-node. 🧚
Now the flow termination mechanism. 😬 It may kick in when some abnormal circumstance makes a link so pre-congested that it excess-traffic-marks (and maybe drops) PCN-packets. In this example, when a PCN-egress-node sees such a packet, it then, with some probability, terminates this PCN-flow. 💀 That probability is set low enough to avoid over termination, and high enough to make sure enough flows get terminated quickly. ⏱️ The PCN-egress-node also informs the relevant PCN-ingress-node, so it can block any further traffic on the terminated flow. 🚫
1.3. Applicability of PCN ✨
Compared with other QoS mechanisms, PCN has some real pros and cons, which make it a great fit for certain scenarios. 🌈 For example, compared with hop-by-hop IntServ [RFC1633], PCN only needs per-flow state at the PCN-ingress-nodes. 🙌 Compared with the Diffserv architecture [RFC2475], an operator needs to be less accurate and/or conservative in predicting the traffic matrix. 🧮 Diffserv's traffic-conditioning agreements are static and coarse, defined at subscription time, and used (for instance) to limit the total traffic at each ingress of the domain, no matter which egress the traffic goes to. 😴 PCN, on the other hand, first uses admission control based on measurements of current conditions between the specific pair of PCN-boundary-nodes, and second, in case of a disaster, it protects the QoS of most flows by terminating a few selected ones. 🛟
PCN's admission control is a measurement-based mechanism, so it assumes the present is a reasonable prediction of the future. 🔮 The network conditions get measured at the time of a new flow request, but the actual network performance must be acceptable during the call some time later. Because of that, PCN is unsuitable in several circumstances: 🙃
- If the source adapts its bit rate depending on the level of pre-congestion, then the aggregate traffic might become unstable. 🎢 The assumption in this document is that PCN-packets come from real-time applications generating inelastic traffic, such as the Controlled Load Service [RFC2211].
- If a potential bottleneck link only has capacity for a few flows, then a new flow can move a link directly from no pre-congestion to being so overloaded that it has to drop packets. 💥 The assumption in this document is that this isn't a problem.
- If there's a danger of a "flash crowd", in which many admission requests arrive within the reaction time of PCN's admission mechanism, then they all might get admitted and overload the network. 🏃♀️💨 The assumption in this document is that, if it's necessary, flash crowds are limited in some fashion beyond the scope of this document, for instance by rate-limiting QoS requests.
The applicability of PCN is discussed further in Section 6. 📚
1.4. Documents about PCN 📝
The purpose of this document is to describe a general architecture for flow admission and termination based on (pre-)congestion information, so that the quality of service of flows within a Diffserv domain stays protected. 🛡️ This document describes the PCN architecture at a high level (Section 3) and in more detail (Section 4). It also defines some terminology and provides considerations about operations, management, and security. 🔐 Section 6 looks at the applicability of PCN in more detail, covering its benefits, deployment scenarios, assumptions, and potential challenges. The Appendix covers some potential future work items. 🔭
Aspects of PCN are also documented elsewhere: 👀
- Metering and marking: [Eardley09] standardises threshold metering and marking and excess-traffic metering and marking. A PCN-packet may be marked, depending on the metering results. 🏷️
- Encoding: the "baseline" encoding is described in [Moncaster09-1], which standardises two PCN encoding states (PCN-marked and not PCN-marked). Meanwhile, (experimental) extensions to the baseline encoding can provide three encoding states (threshold-marked, excess-traffic-marked, or not PCN-marked), for instance, see [Moncaster09-2]. (There may be further encoding states as suggested in [Westberg08].) Section 3.6 considers the backwards compatibility of PCN encoding with ECN. 🧩
- PCN-boundary-node behaviour: how the PCN-boundary-nodes convert the PCN-markings into decisions about flow admission and flow termination, as described in Informational documents such as [Taylor09] and [Charny07-2]. The idea is that the standardised metering and marking by PCN-nodes allows several possible PCN-boundary-node behaviours. A number of possibilities are outlined in this document, and detailed descriptions and comparisons are in [Charny07-1] and [Menth09-2]. 🤓
- Signalling between PCN-boundary-nodes: signalling is needed to transport PCN-feedback-information between the PCN-boundary-nodes (in the example above, this is the fraction of traffic, between the pair of PCN-boundary-nodes, that is PCN-marked). The exact details vary for different PCN-boundary-node behaviours, so they should be described in those documents. It may require an extension to the signalling protocol, but standardisation is out of scope of the PCN WG. 📮
- The interface by which the PCN-boundary-nodes learn identification information about the admitted flows: the exact requirements vary for different PCN-boundary-node behaviours and for different signalling protocols, so they should be described in those documents. They will be similar to those described in the example above. A PCN-ingress-node needs to be able to identify that a packet is part of a previously admitted flow (typically from its five-tuple), and each PCN-boundary-node needs to be able to identify the other PCN-boundary-node for the flow. 🪪
2. Terminology 💅
okay so bestie, this section is basically the glossary for the whole PCN universe 🦋 every term here has a super specific meaning, so read it like it's a playlist you need to memorise 🎀
- PCN-domain 🏰: a PCN-capable domain, which is a contiguous set of PCN-enabled nodes that perform Diffserv scheduling [RFC2474]. It's the complete set of PCN-nodes that can, in principle, use PCN-marking packets to influence decisions about flow admission and termination for the PCN-domain. It includes the PCN-egress-nodes (they measure these PCN-marks) and the PCN-ingress-nodes 🌸
- PCN-boundary-node 🚧: a PCN-node that connects one PCN-domain to a node either in another PCN-domain or in a non-PCN-domain. the edge girlies of the network 💖
- PCN-interior-node 🧚: a node in a PCN-domain that is not a PCN-boundary-node. the cozy inside crew ✨
- PCN-node 🌈: either a PCN-boundary-node or a PCN-interior-node. basically all of the above 💅
- PCN-egress-node 👋: a PCN-boundary-node in its role in handling traffic as it leaves a PCN-domain. the exit bestie 🍓
- PCN-ingress-node 🫶: a PCN-boundary-node in its role in handling traffic as it enters a PCN-domain. the entrance bestie 🎀
- PCN-traffic, PCN-packets, PCN-BA 🦋: a PCN-domain carries traffic from different Diffserv behaviour aggregates (BAs) [RFC2474]. The PCN-BA is the one that uses the PCN mechanisms to carry PCN-traffic, and the packets in it are PCN-packets. the same network can also carry traffic from other Diffserv BAs, so it's not a one-trick pony 🌈 The PCN-BA is told apart by a combination of the Diffserv codepoint (DSCP) and ECN fields 🔥
- PCN-flow 💜: the unit of PCN-traffic that the PCN-boundary-node admits (or terminates). the unit could be a single microflow (as defined in [RFC2474]) or some identifiable collection of microflows 🧁
- Pre-congestion ⚠️: a condition of a link within a PCN-domain where the PCN-node does PCN-marking, to give an "early warning" of potential congestion before there's any significant build-up of PCN-packets in the real queue. (so yes, by analogy with ECN, we call our mechanism Pre-Congestion Notification. iconic naming, no notes 🙈)
- PCN-marking 🏷️: the process of setting the header in a PCN-packet based on defined rules, in reaction to pre-congestion. it's either threshold-marking or excess-traffic-marking. a packet like that is then called PCN-marked 💅
- Threshold-metering 📏: a metering behaviour that, if the PCN-traffic exceeds the PCN-threshold-rate, indicates that all PCN-traffic is to be threshold-marked 🔥
- PCN-threshold-rate 🎯: the reference rate of a threshold-meter. it's configured for each link in the PCN-domain, and it's lower than the PCN-excess-rate 💜
- Threshold-marking 🖍️: setting the header in a PCN-packet to a specific encoding, based on indications from the threshold-meter. that packet is then called threshold-marked 🌸
- Excess-traffic-metering 📐: a metering behaviour that, if the PCN-traffic exceeds the PCN-excess-rate, indicates that the amount of PCN-traffic to be excess-traffic-marked is equal to the amount in excess of the PCN-excess-rate 👑
- PCN-excess-rate 🚀: the reference rate of an excess-traffic-meter. it's configured for each link in the PCN-domain, and it's higher than the PCN-threshold-rate 💖
- Excess-traffic-marking 🖊️: setting the header in a PCN-packet to a specific encoding, based on indications from the excess-traffic-meter. that packet is then called excess-traffic-marked 🧚
- PCN-colouring 🎨: the process of setting the header in a PCN-packet by a PCN-boundary-node. the PCN-ingress-node does it so that PCN-nodes can easily identify PCN-packets. the PCN-egress-node does it so that the header is appropriate for nodes beyond the PCN-domain 🫶
- Ingress-egress-aggregate 🛣️: the collection of PCN-packets from all PCN-flows that travel in one direction between a specific pair of PCN-boundary-nodes 🌈
- PCN-feedback-information 📬: information signalled by a PCN-egress-node to a PCN-ingress-node (or a central control node), which is needed for the flow admission and flow termination mechanisms 💌
- PCN-admissible-rate 🚪: the rate of PCN-traffic on a link up to which PCN admission control should accept new PCN-flows 🎀
- PCN-supportable-rate 🛑: the rate of PCN-traffic on a link down to which PCN flow termination should, if necessary, terminate already admitted PCN-flows 🥀
3. High-Level Functional Architecture 🏗️
the big picture is that functionality gets split up between two groups 👯♀️
- PCN-interior-nodes 🏠 "inside" the PCN-domain. they monitor their own state of pre-congestion and mark PCN-packets as appropriate. they're not flow-aware, and they're not aware of ingress-egress-aggregates. the PCN-ingress-nodes also do this job for their outgoing interfaces (ie, those "inside" the PCN-domain) 🧚
- PCN-boundary-nodes 🚪 at the edge of the PCN-domain. they control admission of new PCN-flows and termination of existing PCN-flows, based on information from PCN-interior-nodes. this info comes in the form of the PCN-marked data packets (which get intercepted by the PCN-egress-nodes), and it is not in signalling messages. generally, PCN-ingress-nodes are flow-aware 💅
the whole point of this split is to keep the bulk of the network simple, scalable, and robust 💪, while confining policy, application-level, and security interactions to the edge of the PCN-domain 🛡️ For example, because the PCN-interior-nodes aren't flow-aware, they don't care about the flow information associated with PCN-packets. and the PCN-boundary-nodes don't care about which PCN-interior-nodes their ingress-egress-aggregates traverse 🙌
so to generate info about the current state of the PCN-domain, each PCN-node PCN-marks packets if it is "pre-congested". 💖 Exactly when a PCN-node decides it is "pre-congested" (the algorithm), and exactly how packets are "PCN-marked" (the encoding), will be defined in separate Standards Track documents. but at a high level, it goes like this 📋
- the algorithms 🧮: a PCN-node meters the amount of PCN-traffic on each one of its outgoing (or incoming) links. the measurement is made as an aggregate of all PCN-packets, not per flow. there are two algorithms: one for threshold-metering and one for excess-traffic-metering. the meters trigger PCN-marking as necessary ✨
- the encoding(s) 🎨: a PCN-node PCN-marks a PCN-packet by modifying a combination of the DSCP and ECN fields. in the "baseline" encoding [Moncaster09-1], the ECN field is set to
11and the DSCP is not altered. extension encodings may be defined that, at most, use a second DSCP (eg, as in [Moncaster09-2]) and/or set the ECN field to values other than11(eg, as in [Menth08-2]) 🌈
in a PCN-domain, the operator may have two or three encoding states available. the baseline encoding gives two encoding states (not PCN-marked and PCN-marked), whilst extended encodings can give three encoding states (not PCN-marked, threshold-marked, and excess-traffic-marked) 🔢
an operator can choose to deploy admission control, flow termination, or both 🎛️ even though they're designed to work together, they're independent mechanisms. using one doesn't require or prevent using the other 🫶 Three encoding states naturally allow both flow admission and flow termination 💜 If there are only two encoding states, there are several options -- see Section 3.3 👀
the PCN-boundary-nodes monitor the PCN-marked packets to extract info about the current state of the PCN-domain 🔍 Based on this monitoring, a distributed decision gets made about whether to admit a prospective new flow or terminate existing flow(s). Sections 4.4 and 4.5 mention various possibilities for how that functionality could be distributed 🌸
PCN-metering and PCN-marking need to be configured on all (potentially pre-congested) links in the PCN-domain, so the PCN mechanisms protect all links 🛡️ The actual functionality can be configured on the outgoing or incoming interfaces of PCN-nodes. or one algorithm could be configured on the outgoing interface and the other on the incoming interface 🔄 The important bit is that a consistent choice is made across the PCN-domain, so the PCN mechanisms protect all links ⭐ See [Eardley09] for further discussion 📚
the objective of threshold-marking, as triggered by the threshold-metering algorithm, is to threshold-mark all PCN-packets whenever the bit rate of PCN-packets is greater than some configured rate, the PCN-threshold-rate 📈 The objective of excess-traffic-metering, as triggered by the excess-traffic-marking algorithm, is to excess-traffic-mark PCN-packets at a rate equal to the difference between the bit rate of PCN-packets and some configured rate, the PCN-excess-rate 📉 Note that this describes the overall intent of the algorithms rather than their instantaneous behaviour. the rate measured at a particular moment depends on the detailed algorithm, its implementation, and the traffic's variance as well as its rate. for example, marking may well continue after a recent overload, even after the instantaneous rate has dropped 🕰️ The algorithms are specified in [Eardley09] 📝
admission and termination approaches are detailed and compared in [Charny07-1] and [Menth09-2]. the discussion below is just a brief summary 💁♀️ Sections 3.1 and 3.2 assume there are three encoding states available, whilst Section 3.3 assumes there are two encoding states available 🫧
from the perspective of the outside world, a PCN-domain basically looks like a Diffserv domain, just without the Diffserv architecture's traffic-conditioning agreements 🌍 PCN-traffic is either carried across it transparently or policed at the PCN-ingress-node (ie, dropped or carried at a lower QoS) 🚦 One difference is that PCN-traffic has better QoS guarantees than normal Diffserv traffic, because the PCN mechanisms better protect the QoS of admitted flows 👑 Another difference may happen in the rare circumstance of a failure: on the one hand, some PCN-flows may get terminated, but on the other hand, other flows will get their QoS restored 🥲 Non-PCN-traffic is treated transparently, ie, the PCN-domain is a normal Diffserv domain 🧸
3.1. Flow Admission ✨
okay so the whole point of PCN's flow admission control is to keep the PCN-traffic on each link around its roughly PCN-admissible-rate 💅 It does this by admitting or blocking new flows, so existing PCN-flows keep their QoS looking fresh 🫶 With three encoding states available, the operator sets the PCN-threshold-rate equal to the PCN-admissible-rate on each link. It sits lower than the rate where the link gets congested and the node starts dropping packets, so we stay on the safe side 🦋
How the admission decision actually gets made will be defined separately in Informational documents 📚 This document describes two approaches (others might be possible):
- The PCN-egress-node measures (possibly as a moving average) the fraction of PCN-traffic that is threshold-marked, for a specific ingress-egress-aggregate. If the fraction is below a threshold value, the new flow is admitted. If it's above the threshold value, the flow is blocked. That fraction can be measured as an EWMA (exponentially weighted moving average), which has sometimes been called the "congestion level estimate" 📊
- The PCN-egress-node monitors PCN-traffic. If it receives one (or several) threshold-marked packets, the new flow is blocked. Otherwise, it's admitted. One option is to react to the marking state of an initial flow-setup packet (eg, RSVP PATH) 🧚 Another is that after one (or several) threshold-marks, all flows get blocked until there's a specific period of no congestion 🙈
Note that the admission control decision is made for a particular pair of PCN-boundary-nodes. So it's totally possible for a new flow to get admitted between one pair of PCN-boundary-nodes while another admission request is blocked between a different pair 🌈
3.2. Flow Termination 🌸
the goal of flow termination is to keep the PCN-traffic on each link around its roughly PCN-supportable-rate by terminating some existing PCN-flows 💔 That protects the QoS of the flows that remain 🫶 With three encoding states available, the operator sets the PCN-excess-rate equal to the PCN-supportable-rate on each link. It may be set lower than the rate where the link gets congested and the node drops packets 🌷
How the termination decision gets made will be defined separately in Informational documents 📚 This document describes several approaches (others might be possible):
- In one approach, the PCN-egress-node measures the rate of PCN-traffic that is not excess-traffic-marked. That's the amount of PCN-traffic that can actually be supported, and it tells the PCN-ingress-node about it 📣 The PCN-ingress-node also measures the rate of PCN-traffic destined for this specific PCN-egress-node. The difference is the excess amount that should be terminated 🧮
- Another approach measures the rate of excess-traffic-marked traffic and terminates that amount. This terminates less traffic than the previous approach if some nodes are dropping PCN-traffic 🍓
- Another approach monitors PCN-packets and terminates some of the PCN-flows that have an excess-traffic-marked packet. (If all such flows were terminated, way too much traffic would go, so a random selection needs to be made from those with an excess-traffic-marked packet [Menth08-1].) 🎲
Since flow termination is designed for "abnormal" circumstances, it's pretty likely that some PCN-nodes are congested. That means packets are being dropped and/or significantly queued 😭 The flow termination mechanism must accommodate this.
Also, the termination control decision is made for a particular pair of PCN-boundary-nodes. So PCN-flows can get terminated between one pair of PCN-boundary-nodes while none are terminated between a different pair 🦋
3.3. Flow Admission and/or Flow Termination When There Are Only Two PCN Encoding States 💜
If a PCN-domain only has two encoding states available (PCN-marked and not PCN-marked), ie, it's using the baseline encoding [Moncaster09-1], then the operator has three options (others might be possible) 🎀
- admission control only: PCN-marking means threshold-marking, ie, only the threshold-metering algorithm triggers PCN-marking. Only PCN admission control is available.
- flow termination only: PCN-marking means excess-traffic-marking, ie, only the excess-traffic-metering algorithm triggers PCN-marking. Only PCN termination control is available.
- both admission control and flow termination: only the excess-traffic-metering algorithm triggers PCN-marking. However, the configured rate (PCN-excess-rate) is set equal to the PCN-admissible-rate, as shown in Figure 3. [Charny07-2] describes how both admission control and flow termination can be triggered in this case, and it also gives some pros and cons of this approach. The main downside is that admission control is less accurate 🧐
== Metering & ==
==Marking behaviour== ==PCN mechanisms==
^
Rate of ^
PCN-traffic on |
bottleneck link | Terminate some
| admitted flows
| &
| Block new flows
|
| Some pkts
U*PCN-excess-rate -| excess-traffic-marked -----------------
(=PCN-supportable-rate)|
| Block new flows
|
|
PCN-excess-rate -|------------------------------------------------
(=PCN-admissible-rate)|
| No pkts Admit new flows
| PCN-marked
|Figure 3: Schematic of how the PCN admission control and flow termination mechanisms operate as the rate of PCN-traffic increases, for a PCN-domain with two encoding states and using the approach of [Charny07-2]. Note: U is a global parameter for all links in the PCN-domain.
3.4. Information Transport 📡
Pre-congestion information gets carried from a PCN-node to a PCN-egress-node through PCN-markings in data packet headers, ie, "in-band". No signalling protocol messaging is needed for that 🙌 Signalling is needed to carry PCN-feedback-information -- for example, to convey the fraction of PCN-marked traffic from a PCN-egress-node to the relevant PCN-ingress-node. Exactly what information needs transporting will be described in future documents about possible boundary mechanisms 🔮 The signalling could be done by an extension of RSVP or NSIS (Next Steps in Signalling), for instance. [Lefaucheur06] describes the extensions needed for RSVP ✨
3.5. PCN-Traffic 🌈
Here are some high-level points about how PCN works 💅
- There needs to be a way for a PCN-node to tell PCN-traffic apart from other traffic. This is done through a combination of the DSCP field and/or ECN field 🏷️
- It is not advised to have competing-non-PCN-traffic. But if there is some, there needs to be a mechanism to limit it. "Competing-non-PCN-traffic" means traffic that shares a link with PCN-traffic and competes for its forwarding bandwidth. So more competing-non-PCN-traffic means poorer QoS for PCN 📉 Also, that unpredictable amount makes the PCN mechanisms less accurate, which reduces PCN's ability to protect the QoS of admitted PCN-flows 😬
- Two examples of competing-non-PCN-traffic are:
- traffic that is priority scheduled over PCN (perhaps a particular application or an operator's control messages);
- traffic that is scheduled at the same priority as PCN (for example, if the Voice-Admit codepoint is used for PCN-traffic [Moncaster09-1] and there is non-PCN, voice-admit traffic in the PCN-domain).
- If there is such competing-non-PCN-traffic, PCN's mechanisms should take account of it, so the decision about whether to admit (or terminate) a PCN-flow is more accurate 🎯 For example, one mechanism is that such competing-non-PCN-traffic contributes to the PCN-meters (ie, is metered by the threshold-marking and excess-traffic-marking algorithms).
- There will be other non-PCN-traffic that doesn't compete for the same forwarding bandwidth as PCN-traffic, because it's forwarded at lower priority. So it shouldn't contribute to the PCN-meters. Examples are best-effort and assured-forwarding traffic. However, a PCN-node should dedicate some capacity to lower-priority traffic so that it isn't starved 🍼
- This document assumes that the PCN mechanisms are applied to a single behaviour aggregate in the PCN-domain. It would also be possible to apply them independently to more than one behaviour aggregate, which are distinguished by DSCP 🦋
3.6. Backwards Compatibility 🫶
PCN specifies semantics for the ECN field that differ from the default semantics of [RFC3168]. A particular PCN encoding scheme needs to describe how it meets the guidelines of BCP 124 [RFC4774] for specifying alternative semantics for the ECN field. In summary, the approach is to:
- use a DSCP to allow PCN-nodes to distinguish PCN-traffic that uses the alternative ECN semantics;
- define these semantics for use within a controlled region, the PCN-domain;
- take appropriate action if ECN-capable, non-PCN-traffic arrives at a PCN-ingress-node with the DSCP used by PCN.
For the baseline encoding [Moncaster09-1], the "appropriate action" is to block ECN-capable traffic that uses the same DSCP as PCN from entering the PCN-domain directly. "Blocking" means the traffic is dropped or downgraded to a lower-priority behaviour aggregate. Alternatively, such traffic may be tunnelled through the PCN-domain. The reason "appropriate action" is needed is that the PCN-egress-node clears the ECN field to 00 💀
Extended encoding schemes may need to take different "appropriate action" 🌸
4. Detailed Functional Architecture ✨
okay so this section is basically the big-picture tour of the new functional architecture in the PCN-domain 💅 First up, it covers the stuff needed at the three types of PCN-node. These are data plane functions, and they're in addition to the normal router functions every PCN-node already does 🎀 Then it digs into the extra functionality needed for both flow admission control and flow termination. Those are signalling and decision-making functions, and there are a bunch of options for where they can physically live 🧚 The section is split into:
- functions needed at PCN-interior-nodes
- functions needed at PCN-ingress-nodes
- functions needed at PCN-egress-nodes
- other functions needed for flow admission control
- other functions needed for flow termination control
Note: Probing is covered in the Appendix.
After that, it talks about a few other detailed topics:
- addressing
- tunnelling
- fault handling
4.1. PCN-Interior-Node Functions
Every link in the PCN-domain gets set up with this functionality 🦋
- Behaviour aggregate classification - figure out whether or not an incoming packet is a PCN-packet 🔍
- PCN-meter - measure the "amount of PCN-traffic" 📏 The measurement is made on the overall PCN-traffic, not per flow. Algorithms decide whether to tell the PCN-marking functionality that packets should be PCN-marked.
- PCN-mark - when the PCN-meter functionality triggers it, PCN-mark packets with the right encoding (if needed) 🏷️
- Drop - if the queue overflows, packets get dropped, no surprises there 💀 On top of that, the link can be configured with a maximum rate for PCN-traffic (set below the physical link rate). Any PCN-packets above that rate get dropped.
The functions are defined in [Eardley09], and the baseline encoding is in [Moncaster09-1] (extended encodings are to be defined in other documents).
+---------+ Result
+->|Threshold|-------+
| | Meter | |
| +---------+ V
+----------+ +- - - - -+ | +------+
| BA | | | | | | Marked
Packet =>|Classifier|==>| Dropper |==?===============>|Marker|==> Packet
Stream | | | | | | | Stream
+----------+ +- - - - -+ | +------+
| +---------+ ^
| | Excess | |
+->| Traffic |-------+
| Meter | Result
+---------+Figure 4: Schematic of PCN-interior-node functionality.
4.2. PCN-Ingress-Node Functions
Each ingress link of the PCN-domain gets this functionality 🚪
- Packet classification - figure out whether an incoming packet is part of a previously admitted flow, using a filter spec (eg, DSCP, source and destination addresses, port numbers, and protocol) 🕵️♀️
- Police - drop any packets that arrive with a DSCP indicating PCN transport but don't belong to an admitted flow 🚫 (A prospective PCN-flow that is rejected could be blocked or admitted into a lower-priority behaviour aggregate.) Same deal for packets that are part of a previously admitted flow: police them to check the flow keeps to the agreed rate or flowspec (eg, see [RFC1633] for a microflow and its NSIS equivalent) 👀
- PCN-colour - set the DSCP and ECN fields appropriately for the PCN-domain, for example, as in [Moncaster09-1] 🎨
- Meter - some approaches to flow termination require the PCN-ingress-node to measure the (aggregate) rate of PCN-traffic heading towards a particular PCN-egress-node 📊
The first two are policing functions. They're needed to make sure that PCN-packets admitted into the PCN-domain belong to a flow that has been admitted, and to make sure the flow keeps to the flowspec agreed (eg, doesn't exceed an agreed maximum rate and is inelastic traffic) 🙅♀️ Installing the filter spec will typically be done by the signalling protocol, and so will re-installing the filter, for example, after a re-route that changes the PCN-ingress-node (see [Briscoe06] for an example using RSVP) 🔁 PCN-colouring lets the rest of the PCN-domain recognise PCN-packets 💖
4.3. PCN-Egress-Node Functions
Each egress link of the PCN-domain gets configured with this 🌅
- Packet classify - figure out which PCN-ingress-node a PCN-packet has come from 🧭
- Meter - "measure PCN-traffic" or "monitor PCN-marks" 🔬
- PCN-colour - for PCN-packets, set the DSCP and ECN fields to the appropriate values for use outside the PCN-domain 🌈
The metering functionality, of course, depends on whether it's aimed at admission control or flow termination 🤷♀️ The alternatives are for the PCN-egress-node to "measure", as an aggregate (ie, not per flow), all PCN-packets from a particular PCN-ingress-node, or to "monitor" the PCN-traffic and react to one (or several) PCN-marked packets. For PCN-colouring, [Moncaster09-1] specifies that the PCN-egress-node resets the ECN field to 00. Other encodings may define different behaviour 🫶
4.4. Admission Control Functions
As well as the functions covered above, other specific admission control functions need to be performed (others might be possible) 👑
- Make decision about admission - this is based on the output of the PCN-egress-node's meter function. If it "measures PCN-traffic", the measured traffic on the ingress-egress-aggregate is compared with some reference level. If it "monitors PCN-marks", the decision is based on whether or not one (or several) packets are PCN-marked (eg, the RSVP PATH message). Either way, the admission decision also takes account of policy and application-layer requirements [RFC2753] ⚖️
- Communicate decision about admission - signal the decision to the node making the admission control request (which may be outside the PCN-domain), and to the policer (PCN-ingress-node function) so it can be enforced 📣
There are various possibilities for how this functionality could be distributed (we assume the operator will configure which one is used) 🛠️
- The decision is made at the PCN-egress-node, and the decision (admit or block) is signalled to the PCN-ingress-node.
- The decision is recommended by the PCN-egress-node (admit or block), but it's definitively made by the PCN-ingress-node. The rationale is that the PCN-egress-node naturally has the necessary information about the amount of PCN-marks on the ingress-egress-aggregate, whereas the PCN-ingress-node is the policy enforcement point [RFC2753] that polices incoming traffic to make sure it's part of an admitted PCN-flow 🧠
- The decision is made at the PCN-ingress-node, which requires that the PCN-egress-node signals PCN-feedback-information to the PCN-ingress-node. For example, it could signal the current fraction of PCN-traffic that is PCN-marked 📈
- The decision is made at a centralised node (see Appendix) 🏰
Note: Admission control functionality is not performed by normal PCN-interior-nodes. 🙈
4.5. Flow Termination Functions
As well as the functions covered above, other specific termination control functions need to be performed (others might be possible) 🚦
- PCN-meter at PCN-egress-node - similarly to flow admission, there are two types of possibilities: to "measure PCN-traffic" on the ingress-egress-aggregate, or to "monitor PCN-marks" and react to one (or several) PCN-marks 🔎
- (if required) PCN-meter at PCN-ingress-node - make "measurements of PCN-traffic" being sent towards a particular PCN-egress-node. Again, this is done for the ingress-egress-aggregate and not per flow 📐
- (if required) Communicate PCN-feedback-information to the node that makes the flow termination decision - for example, as in [Briscoe06], communicate the PCN-egress-node's measurements to the PCN-ingress-node 📨
- Make decision about flow termination - use the information from the PCN-meter(s) to decide which PCN-flow or PCN-flows to terminate. The decision takes account of policy and application-layer requirements [RFC2753] 🪓
- Communicate decision about flow termination - signal the decision to the node that is able to terminate the flow (which may be outside the PCN-domain), and to the policer (PCN-ingress-node function) so it can be enforced 🔔
There are various possibilities for how this functionality could be distributed, similar to those discussed above in Section 4.4 🧩
Note: Flow termination functionality is not performed by normal PCN-interior-nodes. 🙅♀️
4.6. Addressing
PCN-nodes may need to know the address of other PCN-nodes 📬 Note that PCN-interior-nodes don't need to know the address of other PCN-nodes (except their next-hop neighbours for routing purposes) 🧱
At a minimum, the PCN-egress-node needs to know the address of the PCN-ingress-node associated with a flow, so that the PCN-ingress-node can be informed of the admission decision (and any flow termination decision) and enforce it through policing 🫡 There are various possibilities for how the PCN-egress-node can do this, ie, associate the received packet with the correct ingress-egress-aggregate. It is not the intention of this document to mandate a particular mechanism 🙌
- The addressing information can be gathered from signalling, for example through the regular processing of an RSVP PATH message, since the PCN-ingress-node is the previous RSVP hop (PHOP) ([Lefaucheur06]). Another option is that the PCN-ingress-node could signal its address to the PCN-egress-node 💌
- Always tunnel PCN-traffic across the PCN-domain. Then the PCN-ingress-node's address is simply the source address of the outer packet header. The PCN-ingress-node needs to learn the address of the PCN-egress-node, either by manual configuration or by one of the automated tunnel endpoint discovery mechanisms (such as signalling or probing over the data route, interrogating routing, or using a centralised broker) 🚇
4.7. Tunnelling ✨
Okay bestie, tunnels can start and/or end inside a PCN-domain 🚇, like IP over IP or IP over MPLS. Here's the key part: the PCN-marking on any packet can totally influence PCN's flow admission control and termination 👀. So it shouldn't matter whether the packet gets tunnelled at the PCN-node that marks it, or whether a later PCN-node decapsulates or encapsulates it 💅. That's why the "uniform conceptual model" from [RFC2983] should get re-applied in the PCN context 🎀. Lining up with that, [RFC4303], and [Briscoe09], this rule applies when encapsulation is done inside the PCN-domain:
- Any PCN-marking is copied into the outer header.
Note: A tunnel won't give you this behaviour if it complies with [RFC3168] tunnelling in either mode 🙈. It will if it complies with [RFC4301] IPsec tunnelling 🔐.
Similarly, following the "uniform conceptual model" of [RFC2983], the "full-functionality option" of [RFC3168], and [RFC4301] 🌸, this rule applies when decapsulation is done inside the PCN-domain:
- If the outer header's marking state is more severe, then it is copied onto the inner header.
Just know the order of increasing severity: not PCN-marked, then threshold-marked, then excess-traffic-marked 📈.
An operator might want to tunnel PCN-traffic from PCN-ingress-nodes to PCN-egress-nodes 🦋. The PCN-marks shouldn't be visible outside the PCN-domain, and you can make that happen by having the PCN-egress-node do the PCN-colouring function (Section 4.3) after all the other (PCN and tunnelling) functions 🫶. The reasons people do this are: the PCN-egress-node then automatically knows the address of the relevant PCN-ingress-node for a flow, and even if ECMP (Equal Cost Multi-Path) is running, all PCN-packets on a particular ingress-egress-aggregate follow the same path (for more on ECMP, see Section 6.4) 🧚. But tunnelling has drawbacks too 😭. There's the extra overhead in bandwidth and processing, plus the cost of setting up a mesh of tunnels between PCN-boundary-nodes (there's an N^2 scaling issue) 💀.
Things get messy with a "partially PCN-capable tunnel", ie, one where only one tunnel endpoint is inside the PCN-domain 🌈:
- The tunnel starts outside a PCN-domain and ends inside it. If the packet arrives at the tunnel ingress with the same encoding used inside the PCN-domain to show PCN-marking, then the PCN-egress-node could falsely measure pre-congestion 😱.
- The tunnel starts inside a PCN-domain and ends outside it. If the packet arrives at the tunnel ingress already PCN-marked, it'll still have the same encoding when it's decapsulated, which could confuse nodes beyond the tunnel egress 🥴.
To fix these, following the solution for partially capable Diffserv tunnels in [RFC2983], these rules apply:
- For case (1), the tunnel egress node clears any PCN-marking on the inner header. This rule is applied before the "copy on decapsulation" rule above.
- For case (2), the tunnel ingress node clears any PCN-marking on the inner header. This rule is applied after the "copy on encapsulation" rule above.
Note that all of this means you have to know, or figure out, the characteristics of the other end of the tunnel as part of setting it up 🔍.
Tunnelling constraints were a major factor in choosing the baseline encoding 🍓. As explained in [Moncaster09-1], with current tunnelling endpoints, only the 11 codepoint of the ECN field survives decapsulation. So the baseline encoding only uses the 11 codepoint to indicate PCN-marking 🎯. Extended encoding schemes need to explain their interactions with (or assumptions about) tunnelling 📝. A long discussion of all the issues with layered encapsulation of congestion notification (for ECN as well as PCN) is in [Briscoe09] 📚.
4.8. Fault Handling 🛠️
If a PCN-interior-node (or one of its links) fails, then lower-layer protection mechanisms or the regular IP routing protocol will eventually re-route around it 🔁. If the new route can carry all the admitted traffic, flows will gracefully continue ✨. If instead this causes early warning of pre-congestion on the new route, then admission control based on Pre-Congestion Notification will make sure new flows aren't admitted until enough existing flows have departed 🚦. Re-routing might cause heavy (pre-)congestion, which will make the flow termination mechanism kick in 💥.
If a PCN-boundary-node fails, we'd like the regular QoS signalling protocol to be responsible for taking the right action 🙏. As an example, [Briscoe09] looks at what happens if RSVP is the QoS signalling protocol 🧐.
5. Operations and Management 📋
This section is all about operations and management issues, under the FCAPS headings: Faults, Configuration, Accounting, Performance, and Security 🗂️. Provisioning gets discussed with performance 📊.
5.1. Fault Operations and Management 🧯
Fault Operations and Management is about preventing faults 🛡️, telling the management system (or the manual operator) whether the system has recovered from a failure or not 🔔, and maintaining information to help with fault diagnosis 🔎.
Admission blocking and, especially, flow termination mechanisms should rarely be needed in practice 🤞. It would be really unfortunate if they didn't work after an option had been accidentally disabled 😬. So it'll be necessary to regularly test that the live system works as intended (devising a meaningful test is left as an exercise for the operator) 🧪.
Section 4 describes how the PCN architecture is designed to make sure admitted flows continue gracefully after recovering automatically from link or node failures 💪. Recording and monitoring re-routing events that affect signalling is unchanged by adding PCN to a Diffserv domain 📼. Similarly, re-routing events inside the PCN-domain will be recorded and monitored just like they would be without PCN 👀.
PCN-marking does make it possible to record "near-misses" 🎯. For instance, at the PCN-egress-node, a "reporting threshold" could be set to monitor how often, and for how long, the system comes close to triggering flow blocking without actually doing it 🫣. Similarly, bursts of flow termination marking could be recorded even if they aren't sustained enough to trigger flow termination 📉. These stats could be correlated with per-queue counts of marking volume (Section 5.2) to upgrade resources in danger of causing service degradation, or to trigger manual tracing of intermittent incipient errors that would otherwise have gone unnoticed 🕵️♀️✨.
Finally, of course, lots of faults are caused by failings in the management process ("human error") 🙃: a wrongly configured address in a node, a wrong address given in a signalling protocol, a wrongly configured parameter in a queueing algorithm, a node set into a different mode from the other nodes, and so on 🤦♀️. Generally, a clean design with few configurable options makes this class of faults easier to trace and prevent 🧼. Sound management practice at run-time helps too 💅. For instance, a management system should be used that constrains configuration changes within system rules (eg, preventing an option setting that's inconsistent with other nodes) 🚫. Configuration options should be recorded in an offline database, and regular automatic consistency checks between the live systems and the database should be performed 🗄️. PCN adds nothing specific to this class of problems 🫶.
5.2. Configuration Operations and Management ⚙️
Threshold-metering and -marking, and excess-traffic-metering and -marking, are standardised in [Eardley09] 📏. However, more diversity in PCN-boundary-node behaviours is expected, so they can interface with diverse industry architectures 🌍. It may be possible to have different PCN-boundary-node behaviours for different ingress-egress-aggregates within the same PCN-domain 🎨.
PCN-metering behaviour is enabled on either the egress or the ingress interfaces of PCN-nodes 🔌. A consistent choice must be made across the PCN-domain so the PCN mechanisms protect all links 🔗.
PCN configuration control variables fall into these categories 🗂️:
- system options (enabling or disabling behaviours)
- parameters (setting levels, addresses, etc.)
One possibility is that all configurable variables sit within an SNMP (Simple Network Management Protocol) management framework [RFC3411] 🧁. They'd be structured within a defined management information base (MIB) on each node, and be remotely readable and settable via a suitably secure management protocol (such as SNMPv3) 🔐.
Some configuration options and parameters have to be set once to "globally" control the whole PCN-domain 🌐. Where possible, these are identified below 👇. This may affect operational complexity and the chances of interoperability problems between equipment from different vendors ⚠️.
It may be possible for an operator to configure some PCN-interior-nodes so that they don't run the PCN mechanisms, if it knows those links will never become (pre-)congested 🥰.
5.2.1. System Options 💖
okay so PCN-interior-nodes don't have a ton of system options, bestie 🥺 it's giving low-maintenance:
- Whether two PCN-markings (threshold-marked and excess-traffic-marked) are enabled or only one. Typically, every node throughout a PCN-domain gets configured the same in this respect. Exceptions can happen though 👀 For example, if most PCN-nodes used both markings but some legacy hardware couldn't run two algorithms, an operator might choose to configure those legacy nodes only for excess-traffic-marking so flow termination still works as a back-stop 🛟. It would be sensible to place those nodes where they can be provisioned with a greater leeway over expected traffic levels ✨
- In the case where only one PCN-marking is enabled, all nodes must be configured to generate PCN-marks from the same meter (ie, either the threshold meter or the excess-traffic meter). no mix-and-match, periodt 💅
PCN-boundary-nodes (ingress and egress) get way more system options, so buckle up 🎢
- Which of admission and flow termination are enabled. If any PCN-interior-node is configured to generate a marking, all PCN-boundary-nodes must be able to interpret that marking. This includes understanding, in a PCN-domain that uses only one type of PCN-marking, whether the marks came from the PCN-interior-nodes' threshold meters or their excess-traffic meters 🧠 Therefore, all PCN-boundary-nodes must be configured the same in this respect, because they have to be on the same page 🫶
- Where flow admission and termination decisions are made: at PCN-ingress-nodes or at PCN-egress-nodes (or at a centralised node, see Appendix). Theoretically this could be negotiated for each pair of PCN-boundary-nodes, but we can't imagine why that much complexity would be needed, except maybe in future inter-domain scenarios 🤷♀️
- How PCN-markings get translated into admission control and flow termination decisions (see Sections 3.1 and 3.2) 🦋
PCN-egress-nodes get a few extra options on top:
- How the mapping should be established between each packet and its aggregate (eg, by MPLS label and by IP packet filter spec), and how to take account of ECMP 🗺️
- If an equipment vendor provides a choice, there may be options for selecting which smoothing algorithm to use for measurements 🌸
5.2.2. Parameters 🎀
okay so like any Diffserv domain, every node within a PCN-domain needs to be configured with the DSCP(s) used to identify PCN-packets 🏷️ On each interior link, the main configuration parameters are the PCN-threshold-rate and PCN-excess-rate. A larger PCN-threshold-rate lets more PCN-traffic be admitted on a link, which means better capacity utilisation ✨ A PCN-excess-rate set further above the PCN-threshold-rate allows greater increases in traffic (whether from natural fluctuations or some unexpected event) before any flows get terminated. In other words, it minimises the chances of unnecessarily triggering the termination mechanism 🙈 For instance, an operator may want to design their network so it can cope with a failure of any single PCN-node without terminating any flows 💜
Setting these rates on the first deployment of PCN is going to feel very similar to the traditional process for sizing an admission-controlled network 📊 It depends on: the operator's requirements for minimising flow blocking (grade of service), the expected PCN-traffic load on each link and its statistical characteristics (the traffic matrix), contingency for re-routing the PCN-traffic matrix when there are single or multiple failures, and the expected load from other classes relative to link capacities [Menth09-1]. But once a domain is up and running, a PCN design goal is to determine growth in these configured rates much more simply, by monitoring PCN-marking rates from actual rather than expected traffic (see Section 5.4 on Performance and Provisioning) 📈 main character energy for real 🌟
Operators may also wish to configure a rate greater than the PCN-excess-rate. That's the absolute maximum rate a link allows for PCN-traffic 🚧 This may simply be the physical link rate, but some operators may want a logical limit to prevent starvation of other traffic classes during the brief period after PCN-traffic exceeds the PCN-excess-rate but before flow termination brings it back below this rate 😭
Threshold-metering requires a threshold token bucket depth to be configured. Excess-traffic-metering requires a value for the MTU (maximum size of a PCN-packet on the link). Both require setting a maximum size for their token buckets 🪣 It is preferable to have rules that set defaults for these parameters but then let operators change them, for instance if average traffic characteristics change over time ✨
The PCN-egress-node may allow configuration of:
- how it smooths metering of PCN-markings (eg, EWMA parameters) 🫧
Whichever node makes admission and flow termination decisions will contain algorithms for converting PCN-marking levels into those decisions. These algorithms will also need configurable parameters, for instance:
- An admission control algorithm that is based on the fraction of marked packets will at least require a marking threshold setting above which it denies admission to new flows 🚫
- Flow termination algorithms will probably require a parameter to delay termination of any flows until it's more certain that an anomalous event isn't transient ⏳
- A parameter to control the trade-off between how quickly excess flows are terminated and over-termination 🎢
One particular approach [Charny07-2] would require a global parameter to be defined on all PCN-nodes, but would only need one PCN-marking rate to be configured on each link 🧚 The global parameter is a scaling factor between admission and termination. That's the rate of PCN-traffic on a link up to which flows are admitted, versus the rate above which flows are terminated. [Charny07-2] discusses the impact of this particular approach on the operation of PCN in full 📚
5.3. Accounting Operations and Management 🧾
Accounting only happens at trust boundaries, so it's out of scope for this document, which is confined to intra-domain issues 🙅♀️ Using PCN inside a domain makes no difference to the flow signalling events crossing trust boundaries outside the PCN-domain. Those events are typically what gets used for accounting 💅
5.4. Performance and Provisioning Operations and Management 📊
Monitoring performance factors that can be measured from outside the PCN-domain will be no different with PCN than with any other packet-based, flow admission control system 🌐 That's true at the flow level (blocking probability, etc.) and at the packet level (jitter [RFC3393], [Y.1541], loss rate [RFC4656], mean opinion score [P.800], etc.). The difference is that PCN is intentionally designed to indicate internally which exact resource(s) are causing performance problems, and by how much 🔍
Even better, PCN indicates which resources will probably cause problems if they aren't upgraded soon 🔮 This can be achieved by the management system monitoring the total amount (in bytes) of PCN-marking generated by each queue over a period. Given possible long provisioning lead times, pre-congestion volume is the best metric for revealing whether enough persistent demand has built up to warrant an upgrade. That's because, even before utilisation becomes problematic, the statistical variability of traffic will cause occasional bursts of pre-congestion 💥 This "early warning system" decouples the process of adding customers from the provisioning process 🦋 It should cut the time to add a customer compared with admission control provided over native Diffserv [RFC2998], because it saves having to verify the capacity-planning process before adding each customer 🏃♀️
Alternatively, before triggering an upgrade, the long-term pre-congestion volume on each link can be used to balance traffic load across the PCN-domain by adjusting the link weights of the routing system 🗺️ When an upgrade to a link's configured PCN-rates is required, it may also be necessary to upgrade the physical capacity available to other classes. However, there will usually be enough physical capacity for the upgrade to go ahead as a simple configuration change ✨ Alternatively, [Songhurst06] describes an adaptive rather than preconfigured system. There, the configured PCN-threshold-rate is replaced with a high and low water mark, and the marking algorithm automatically optimises how physical capacity is shared, using the relative loads from PCN and other traffic classes 🌊
All the above processes need just three extra counters associated with each PCN queue: threshold-markings, excess-traffic-markings, and drops 🔢 Every time a PCN-packet is marked or dropped, its size in bytes should be added to the appropriate counter. Then the management system can read the counters at any time and subtract a previous reading to work out the incremental volume of each type of (pre-)congestion. Readings should be taken frequently so that anomalous events (eg, re-routes) can be told apart from regular fluctuating demand, if that's required 🙌
5.5. Security Operations and Management 🔐
Security Operations and Management is about using secure operational practices, as well as being able to track security breaches or near-misses at run-time 👀 PCN adds few specifics to the general good practice required in this field [RFC4778], so you're mostly good 🫶 The correct functions of the system should be monitored (Section 5.4) in multiple independent ways and correlated to detect possible security breaches 🕵️♀️ Persistent (pre-)congestion marking should raise an alarm, both on the node doing the marking and on the PCN-egress-node metering it 🚨 Similarly, persistently poor external QoS metrics (such as jitter or mean opinion score) should raise an alarm 📉
The following are examples of symptoms that may be the result of innocent faults rather than attacks. Still, until they're diagnosed, they should be logged and should trigger a security alarm 😳
- Anomalous patterns of non-conforming incoming signals and packets rejected at the PCN-ingress-nodes (eg, packets already marked PCN-capable, or traffic persistently starving token bucket policers) 🚩
- PCN-capable packets arriving at a PCN-egress-node with no associated state for mapping them to a valid ingress-egress-aggregate 🫥
- A PCN-ingress-node receiving feedback signals that are about the pre-congestion level on a non-existent aggregate, or that are inconsistent with other signals (eg, unexpected sequence numbers, inconsistent addressing, conflicting reports of the pre-congestion level, etc.) 🤯
- Pre-congestion marking arriving at a PCN-egress-node with (pre-)congestion markings focused on particular flows, rather than randomly distributed throughout the aggregate 🎯
6. Applicability of PCN ✨
6.1. Benefits ✨
okay so the big selling points of PCN are that it's simple, scalable, and robust 🫶 and honestly it's giving all three, because:
- 💖 Per-flow state only lives at the PCN-ingress-nodes ("stateless core") 🧚. That's required for policing (to stop non-admitted PCN-traffic from sneaking into the PCN-domain) and so on. Other network entities usually don't need to know about individual flows, although they might in certain deployment scenarios.
- 🦋 Admission control is resilient bestie. With PCN, QoS is decoupled from the routing system, so admitted flows can survive capacity, routing, or topology changes without any extra signalling. The PCN-admissible-rate on each link can be set low enough that admitted traffic can still get carried after a re-route in most failure cases [Menth09-1]. This matters a lot, because QoS violations in core networks from link failures are more likely than QoS violations from increased traffic volume [Iyer03] 😭
- 🌸 The PCN-metering behaviours only look at the overall PCN-traffic on the link, not per flow. Very efficient, very chill.
- 🎀 The measurements get signalled to the PCN-egress-nodes by the PCN-marks in the packet headers, which is "in-band" 🙈 No extra signalling protocol is needed to carry the PCN-marks, so no secure binding is required between data packets and separate congestion messages. Zero drama.
- 🌈 The PCN-egress-nodes make their own measurements on the aggregate PCN-traffic from each PCN-ingress-node, not per flow. The feedback they signal (used for flow admission and termination decisions) is also at the granularity of the ingress-egress-aggregate. There's an alternative where the PCN-egress-nodes monitor the PCN-traffic and signal that feedback at the granularity of one (or a few) PCN-marks, which is a whole different vibe 💅
- ⭐ The admitted PCN-load is controlled dynamically, so it adapts when the traffic matrix changes. It also adapts when the network topology changes (eg, after a link failure). That means an operator can be less conservative when deploying network capacity, and less accurate in predicting the PCN-traffic matrix. Main character energy 👑
- 🔥 The termination mechanism complements admission control. It lets the network recover from sudden, unexpected surges of PCN-traffic on some links, which restores QoS for the remaining flows. These scenarios are expected to be rare, but not impossible 💀 They can be caused by large network failures that redirect lots of admitted PCN-traffic onto other links, or by measurement-based admission control malfunctioning when admitted flows send for a while at an atypically low rate and then increase their rates in a correlated way.
- 🍓 Flow termination can also let an operator be less conservative when deploying capacity. It's an alternative to running links at low utilisation just to protect against link or node failures. This is especially true with SRLGs (shared risk link groups), which are links that share a resource, such as a fibre, whose failure takes out every link in that group [RFC4216]). Fully protecting traffic against a single SRLG failure requires low utilisation (~10%) of the link bandwidth on some links before failure [Charny08] 🤯
- 🧚♀️ The PCN-supportable-rate can be set below the maximum rate PCN-traffic can be transmitted on a link. That triggers termination of some PCN-flows before loss (or excessive delay) of PCN-packets happens, or keeps the maximum PCN-load on a link below a level the operator configured.
- 💜 Provisioning of the network is decoupled from adding new customers. With the Diffserv architecture [RFC2475], operators rely on subscription-time Service Level Agreements, which statically define the parameters of the traffic accepted from a customer. So the operator has to verify that provision is sufficient every time a new customer joins, to check the Service Level Agreement can still be fulfilled. A PCN-domain doesn't need that kind of traffic conditioning. Freedom 🕊️
6.2. Deployment Scenarios 🌸
operators are gonna want to use PCN in different arrangements, depending on things like how they're doing admission control outside the PCN-domain (users are, after all, concerned about QoS end-to-end), what their goals and assumptions are, how many PCN encoding states are available, and so on 🧠
a PCN-domain may have three encoding states (or pedantically, an operator may choose to use up three encoding states for PCN): not PCN-marked, threshold-marked, and excess-traffic-marked. This way, both PCN admission control and flow termination can be supported ✨ As illustrated in Figure 1, admission control accepts new flows until the PCN-traffic rate on the bottleneck link rises above the PCN-threshold-rate, whilst, if necessary, the flow termination mechanism terminates flows down to the PCN-excess-rate on the bottleneck link.
on the other hand, a PCN-domain may have two encoding states (as in [Moncaster09-1]) (or pedantically, an operator may choose to use up two encoding states for PCN): not PCN-marked and PCN-marked. This way, there are three possibilities, as discussed in the following paragraphs (see also Section 3.3) 🦋
first, an operator could just use PCN's admission control, and deal with heavy congestion (caused by re-routing) by "just waiting" 😌 As sessions end, PCN-traffic naturally reduces, and meanwhile the admission control mechanism stops new flows from using the affected links. So the PCN-domain will naturally return to normal operation, just with reduced capacity. The drawback is that, until enough sessions have ended to relieve the congestion, all PCN-flows as well as lower-priority services get adversely affected 🥲
second, an operator could just rely on statically provisioned capacity per PCN-ingress-node (regardless of the PCN-egress-node of a flow) for admission control, which is typical in the hose model of the Diffserv architecture [Kumar01]. Such traffic-conditioning agreements can lead to focused overload: many flows happen to focus on one particular link, and then all the flows through the congested link fail catastrophically 💀 PCN's flow termination mechanism could then be used to counteract that problem.
third, both admission control and flow termination can be triggered from the single type of PCN-marking. The main downside is that admission control is less accurate [Charny07-2]. This possibility is illustrated in Figure 3 🎀
within the PCN-domain, there's some flexibility about how the decision-making functionality gets distributed. These possibilities are outlined in Section 4.4 and are also discussed elsewhere, such as in [Menth09-2] 💅
the flow admission and termination decisions need to be enforced through per-flow policing by the PCN-ingress-nodes. If there are several PCN-domains on the end-to-end path, then each one needs to police at its PCN-ingress-nodes. One exception: if the operator runs both the access network (not a PCN-domain) and the core network (a PCN-domain), per-flow policing could be devolved to the access network and not be done at the PCN-ingress-node 🌈 Note that, to aid readability, the rest of this document assumes that policing is done by the PCN-ingress-nodes.
PCN admission control has to fit with the overall approach to admission control. For instance, [Briscoe06] describes the case where RSVP signalling runs end-to-end. The PCN-domain is a single RSVP hop, ie, only the PCN-boundary-nodes process RSVP messages, with RSVP messages processed on each hop outside the PCN-domain, as in IntServ over Diffserv [RFC2998]. It would also be possible for the RSVP signalling to be originated and/or terminated by proxies, with application-layer signalling between the end user and the proxy (eg, SIP signalling with a home hub). A similar example would use NSIS (Next Steps in Signalling) [RFC3726] instead of RSVP 🧚
it's possible that a user wants its inelastic traffic to use the PCN mechanisms but also react to ECN markings outside the PCN-domain [Sarker08] 🤔 Two possible ways to do this: either tunnel all PCN-packets across the PCN-domain, so the ECN marks are carried transparently across it, or use an encoding like [Moncaster09-2]. Tunnelling is discussed further in Section 4.7 🫶
some further possible deployment models are outlined in the Appendix 📚
6.3. Assumptions and Constraints on Scope 🔥
the scope of this document is restricted by the following assumptions:
- These components are deployed in a single Diffserv domain, within which all PCN-nodes are PCN-enabled and are trusted for truthful PCN-marking and transport.
- All flows handled by these mechanisms are inelastic and constrained to a known peak rate through policing or shaping.
- The number of PCN-flows across any potential bottleneck link is sufficiently large that stateless, statistical mechanisms can be effective. To put it another way, the aggregate bit rate of PCN-traffic across any potential bottleneck link needs to be sufficiently large, relative to the maximum additional bit rate added by one flow. This is the basic assumption of measurement-based admission control 📊
- PCN-flows may have different precedence, but the applicability of the PCN mechanisms for emergency use (911, GETS (Government Telecommunications Service), WPS (Wireless Priority Service), MLPP (Multilevel Precedence and Premption), etc.) is out of scope 🚫
6.3.1. Assumption 1: Trust and Support of PCN - Controlled Environment 🔐
it's assumed that the PCN-domain is a controlled environment, ie, all the nodes in a PCN-domain run PCN and are trusted. There are several reasons for this, bestie:
- The PCN-domain has to be encircled by a ring of PCN-boundary-nodes. Otherwise, traffic could enter a PCN-BA without being subject to admission control, which would potentially degrade the QoS of existing PCN-flows 😱
- Similarly, a PCN-boundary-node has to trust that all the PCN-nodes mark PCN-traffic consistently. A node not performing PCN-marking wouldn't be able to send an alert when it suffered pre-congestion, which could lead to too many PCN-flows being admitted (or too few being terminated). Worse, a rogue node could perform various attacks, as discussed in Section 7 🥀
One way of making sure the above two points are in effect is to have the entire PCN-domain run by a single operator. Another way is to have several operators that trust each other in their handling of PCN-traffic 🤝
Note: All PCN-nodes need to be trustworthy. However, if it is known that an interface cannot become pre-congested, then it is not strictly necessary for it to be capable of PCN-marking, but this must be known even in unusual circumstances, eg, after the failure of some links. 🫠
6.3.2. Assumption 2: Real-Time Applications 🎀
okay so assumption two is all about the apps 💅 we're assuming a source's bit rate can wiggle all it wants, and that wiggling has nothing to do with how pre-congested the network is 🫶. These PCN-packets come from real-time apps sending inelastic traffic, which just means they push packets out at whatever pace the codec produces them, no matter how much room is left on the link [RFC4594]. Think voice and video that need low delay, jitter, and packet loss, plus the Controlled Load Service [RFC2211] and the Telephony service class [RFC4594] 📞.
Why these? Because we want to focus on where PCN is most likely to be useful 🔍, meaning the apps where per-flow QoS is already a known requirement. So bestie, we're centring PCN's benefit on inelastic traffic (PCN might or might not help other kinds of traffic, and we're not claiming it does 🙈).
As a consequence, it is assumed that PCN-metering and PCN-marking is being applied to traffic scheduled with an expedited forwarding per-hop behaviour [RFC3246] or with a per-hop behaviour with similar characteristics ✨.
6.3.3. Assumption 3: Many Flows and Additional Load 🦋
Assume there are many PCN-flows on any bottleneck link in the PCN-domain 💜. Or to say it another way, the aggregate bit rate of PCN-traffic across any potential bottleneck link is big enough, compared to the maximum extra bit rate one PCN-flow adds. Measurement-based admission control is basically betting that the present predicts the future 🔮. Network conditions get measured when a new flow asks to join, but the actual performance has to stay acceptable during the call some time later, and that's the tricky bit.
Here's the issue 😬: if there are only a few variable rate flows, the aggregate traffic level can swing around a lot, maybe enough to make some packets get dropped. With lots of flows, the aggregate should be statistically smoothed out 🧁. How many flows is "enough" depends on a few things, like how much each flow's rate varies, the total rate of PCN-traffic, and the size of the "safety margin" between the traffic level where we start admission-marking and the level where packets get dropped or significantly delayed.
No explicit assumptions are made about how many PCN-flows are in each ingress-egress-aggregate. Performance-evaluation work may clarify whether it is necessary to make any additional assumptions on aggregation at the ingress-egress-aggregate level 📊.
6.3.4. Assumption 4: Emergency Use Out of Scope 🚫
PCN-flows may have different precedence, but the applicability of the PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc.) is out of scope for this document 🚨. We're not going there in this doc, periodt.
6.4. Challenges 🧗
Prior work on PCN and similar mechanisms has led to a bunch of considerations about PCN's design goals (the things PCN should be good at) and some issues that have been really hard to solve in a fully satisfying way 😭. Honestly, PCN is a list of trade-offs (it's unlikely they can all be 100% achieved) and maybe a list of evaluation criteria to help an operator (or the IETF) pick between options 💅.
The following are open issues 👀. They're mainly taken from [Briscoe06], which also describes some possible solutions. Just know that some may be considered unimportant in general, or in specific deployment scenarios, or by some operators 🤷♀️.
Note: Potential solutions are out of scope for this document.
- ECMP (Equal Cost Multi-Path) Routing: The level of pre-congestion is measured on a specific ingress-egress-aggregate. However, if the PCN-domain runs ECMP, then traffic on this ingress-egress-aggregate may follow several different paths. Some of those paths could be pre-congested whilst others are not. There are three potential problems 🌀:
- over-admission: a new flow is admitted (because the pre-congestion level measured by the PCN-egress-node is sufficiently diluted by unmarked packets from non-congested paths that a new flow is admitted), but its packets travel through a pre-congested PCN-node.
- under-admission: a new flow is blocked (because the pre-congestion level measured by the PCN-egress-node is sufficiently increased by PCN-marked packets from pre-congested paths that a new flow is blocked), but its packets travel along an uncongested path.
- ineffective termination: a flow is terminated but its path doesn't travel through the (pre-)congested router(s). Since flow termination is a "last resort", which protects the network should over-admission occur, this problem is probably more important to solve than the other two.
- ECMP and Signalling: It is possible that, in a PCN-domain running ECMP, the signalling packets (eg, RSVP, NSIS) follow a different path than the data packets. That could matter if the signalling packets are used as probes. Whether this is an issue depends on which fields the ECMP algorithm uses. If the ECMP algorithm is restricted to the source and destination IP addresses, then it will not be an issue 🙌. ECMP and signalling interactions are a specific instance of a general issue for non-traditional routing combined with resource management along a path [Hancock02].
- Tunnelling: There are scenarios where tunnelling makes it difficult to determine the path in the PCN-domain. The problem, its impact, and the potential solutions are similar to those for ECMP 🕳️.
- Scenarios with only one tunnel endpoint in the PCN-domain: Such scenarios may make it harder for the PCN-egress-node to gather from the signalling messages (eg, RSVP, NSIS) the identity of the PCN-ingress-node 🥺.
- Bi-Directional Sessions: Many applications have bi-directional sessions, which means there are two microflows that should be admitted (or terminated) as a pair. For instance, a bi-directional voice call only makes sense if microflows in both directions are admitted 📞📞. However, the PCN mechanisms concern admission and termination of a single flow, so coordinating the decision for both flows is a matter for the signalling protocol and out of scope for PCN. One possible example would use SIP pre-conditions. However, there are others.
- Global Coordination: PCN makes its admission decision based on PCN-markings on a particular ingress-egress-aggregate. Decisions about flows through a different ingress-egress-aggregate are made independently. However, one can imagine network topologies and traffic matrices where, from a global perspective, it would be better to make a coordinated decision across all the ingress-egress-aggregates for the whole PCN-domain 🌍. For example, you might block (or even terminate) flows on one ingress-egress-aggregate so that more important flows through a different ingress-egress-aggregate could be admitted. The problem may well be relatively insignificant, so no panic 💆♀️.
- Aggregate Traffic Characteristics: Even when the number of flows is stable, the traffic level through the PCN-domain will vary because the sources vary their traffic rates 📈. PCN works best when there is not too much variability in the total traffic level at a PCN-node's interface (ie, in the aggregate traffic from all sources). Too much variation means that a node may, at one moment, not be doing any PCN-marking and then, at another moment, drop packets because it is overloaded 💀. This makes it hard to tune the admission control scheme to stop admitting new flows at the right time. Therefore, the problem is more likely with fewer, burstier flows.
- Flash crowds and Speed of Reaction: PCN is a measurement-based mechanism, so there is an inherent delay between packet marking by PCN-interior-nodes and any admission control reaction at PCN-boundary-nodes ⏳. For example, if a big burst of admission requests potentially occurs in a very short space of time (eg, prompted by a televote), they could all get admitted before enough PCN-marks are seen to block new flows. In other words, any additional load offered within the reaction time of the mechanism must not move the PCN-domain directly from a no congestion state to overload. This "vulnerability period" may have an impact at the signalling level. For instance, QoS requests should be rate-limited to bound the number of requests able to arrive within the vulnerability period 🚦.
- Silent at Start: After a successful admission request, the source may wait some time before sending data (eg, waiting for the called party to answer). Then the risk is that, in some circumstances, PCN's measurements underestimate what the pre-congestion level will be when the source does start sending data 🤫.
7. Security Considerations 🔒
okay so the security stuff all comes from the Trust Assumption in Section 6.3.1 💅 basically, every PCN-node is PCN-enabled and trusted to do truthful PCN-metering and PCN-marking, and that's the whole foundation. ✨ PCN splits its jobs between PCN-interior-nodes and PCN-boundary-nodes, and the security concerns are kinda different for each one, mainly because PCN-boundary-nodes are flow-aware and PCN-interior-nodes are not. 🫶
- Because PCN-boundary-nodes are flow-aware, they are trusted to use that awareness correctly. 🧠 how much trust they need depends on what decisions they have to make and what info they need to make them. nothing specific to PCN here, fr.
- The PCN-ingress-nodes police packets so a PCN-flow stays inside its agreed limit, and so that only PCN-flows that were admitted put PCN-traffic into the PCN-domain. 🚫 the policer must drop any PCN-packets that are outside that remit (or maybe downgrade them to a different DSCP). this is basically like the existing IntServ behaviour, bestie 🎀 and between them, the PCN-boundary-nodes have to encircle the PCN-domain. if they don't, PCN-packets could sneak into the PCN-domain without admission control, and that could totally wreck the QoS of existing flows 😭
- PCN-interior-nodes are not flow-aware, and honestly that's a win 🦋 it stops some attacks where someone targets specific flows in the data plane, like for DoS or eavesdropping.
- The PCN-boundary-nodes rely on correct PCN-marking by the PCN-interior-nodes. 😈 a rogue PCN-interior-node could PCN-mark every packet so no flows get admitted. or it could never PCN-mark anything, even when it's pre-congested. and it gets sneakier: the rogue node could do this selectively to particular flows, or mark the right overall fraction but carefully pick which flows get marked. yikes 💀
- The PCN-boundary-nodes should be able to deal with DoS attacks and state exhaustion attacks based on fast changes in per-flow signalling. 🛡️ no excuses, they gotta be ready for that.
- The signalling between the PCN-boundary-nodes must be protected from attacks. 🔐 for example, the recipient needs to validate that the message really is from the node that says it sent it. possible measures include digest authentication and protection against replay and man-in-the-middle attacks. for the RSVP protocol specifically, hop-by-hop authentication is in [RFC2747], and [Behringer09] may also be useful. 💜
Operational security advice is given in Section 5.5. 🌸
8. Conclusions ✨
okay so this doc describes a general architecture for flow admission and termination based on pre-congestion information 🦋 the goal is protecting the quality of service of established, inelastic flows inside a single Diffserv domain. the main topic is the functional architecture, obviously 💅 but it also mentions other stuff like the assumptions and open issues tied to the PCN architecture. 🧚
9. Acknowledgements 🫶
this document is a revised version of an earlier individual working draft written by P. Eardley, J. Babiarz, K. Chan, A. Charny, R. Geib, G. Karagiannis, M. Menth, and T. Tsou. 🌈 that makes them contributors to this document, so they get their flowers 💐
thanks to everyone who left comments: Lachlan Andrew, Joe Babiarz, Fred Baker, David Black, Steven Blake, Ron Bonica, Scott Bradner, Bob Briscoe, Ross Callon, Jason Canon, Ken Carlberg, Anna Charny, Joachim Charzinski, Andras Csaszar, Francis Dupont, Lars Eggert, Pasi Eronen, Adrian Farrel, Ruediger Geib, Wei Gengyu, Robert Hancock, Fortune Huang, Christian Hublet, Cullen Jennings, Ingemar Johansson, Georgios Karagiannis, Hein Mekkes, Michael Menth, Toby Moncaster, Dimitri Papadimitriou, Dan Romascanu, Daisuke Satoh, Ben Strulo, Tom Taylor, Hannes Tschofenig, Tina Tsou, David Ward, Lars Westberg, Magnus Westerlund, and Delei Yu. 🎀 extra big hugs to Bob Briscoe, who extensively revised the Operations and Management section 👑
this document is the result of discussions in the PCN WG and a forerunner activity in the TSVWG. 🧁 a bunch of previous drafts got presented to TSVWG, and their authors were: B. Briscoe, P. Eardley, D. Songhurst, F. Le Faucheur, A. Charny, J. Babiarz, K. Chan, S. Dudley, G. Karagiannis, A. Bader, L. Westberg, J. Zhang, V. Liatsos, X-G. Liu, and A. Bhargava. 🌷
the admission control mechanism evolved from work led by Martin Karsten on the Guaranteed Stream Provider, developed in the M3I project [Karsten02] [M3I]. that work was based on the theoretical work of Gibbens and Kelly [Gibbens99]. 🧠✨
10. References 📚
10.1. Normative References 💖
[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.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le
Boudec, J., Courtney, W., Davari, S., Firoiu, V.,
and D. Stiliadis, "An Expedited Forwarding PHB (Per-
Hop Behavior)", RFC 3246, March 2002.10.2. Informative References ✨
okay bestie, this is the big shelf of informative references 📚💅 these are the extra reads that back up the whole doc, like receipts 🧾 they're not normative, so the main spec doesn't depend on them, but they're where all the good background lives 🦋 here's the full list, copied exactly so nothing gets lost:
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview",
RFC 1633, June 1994.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and
S. Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC2211] Wroclawski, J., "Specification of the Controlled-
Load Network Element Service", RFC 2211,
September 1997.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z., and W. Weiss, "An Architecture for
Differentiated Services", RFC 2475, December 1998.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747,
January 2000.
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A
Framework for Policy-based Admission Control",
RFC 2753, January 2000.
[RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, October 2000.
[RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F.,
Zhang, L., Speer, M., Braden, R., Davie, B.,
Wroclawski, J., and E. Felstaine, "A Framework for
Integrated Services Operation over Diffserv
Networks", RFC 2998, November 2000.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The
Addition of Explicit Congestion Notification (ECN)
to IP", RFC 3168, September 2001.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
Vaananen, P., Krishnan, R., Cheval, P., and J.
Heinanen, "Multi-Protocol Label Switching (MPLS)
Support of Differentiated Services", RFC 3270,
May 2002.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay
Variation Metric for IP Performance Metrics (IPPM)",
RFC 3393, November 2002.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network
Management Protocol (SNMP) Management Frameworks",
STD 62, RFC 3411, December 2002.
[RFC3726] Brunner, M., "Requirements for Signaling Protocols",
RFC 3726, April 2004.
[RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous
System (AS) Traffic Engineering (TE) Requirements",
RFC 4216, November 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594,
August 2006.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J.,
and M. Zekauskas, "A One-way Active Measurement
Protocol (OWAMP)", RFC 4656, September 2006.
[RFC4774] Floyd, S., "Specifying Alternate Semantics for the
Explicit Congestion Notification (ECN) Field",
BCP 124, RFC 4774, November 2006.
[RFC4778] Kaeo, M., "Operational Security Current Practices in
Internet Service Provider Environments", RFC 4778,
January 2007.
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit
Congestion Marking in MPLS", RFC 5129, January 2008.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label
Switching (MPLS) Label Stack Entry: "EXP" Field
Renamed to "Traffic Class" Field", RFC 5462,
February 2009.
[P.800] "Methods for subjective determination of
transmission quality", ITU-T Recommendation P.800,
August 1996.
[Y.1541] "Network Performance Objectives for IP-based
Services", ITU-T Recommendation Y.1541,
February 2006.
[Babiarz06] Babiarz, J., Chan, K., Karagiannis, G., and P.
Eardley, "SIP Controlled Admission and Preemption",
Work in Progress, October 2006.
[Behringer09] Behringer, M. and F. Le Faucheur, "Applicability of
Keying Methods for RSVP Security", Work in Progress,
March 2009.
[Briscoe06] 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.
[Briscoe08] Briscoe, B., "Emulating Border Flow Policing using
Re-PCN on Bulk Data", Work in Progress,
September 2008.
[Briscoe09] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", Work in Progress, March 2009.
[Bryant08] Bryant, S., Davie, B., Martini, L., and E. Rosen,
"Pseudowire Congestion Control Framework", Work
in Progress, May 2008.
[Charny07-1] Charny, A., Babiarz, J., Menth, M., and X. Zhang,
"Comparison of Proposed PCN Approaches", Work
in Progress, November 2007.
[Charny07-2] Charny, A., Zhang, X., Le Faucheur, F., and V.
Liatsos, "Pre-Congestion Notification Using Single
Marking for Admission and Termination", Work
in Progress, November 2007.
[Charny07-3] Charny, A., "Email to PCN WG mailing list",
November 2007, <http://www1.ietf.org/mail-archive/
web/pcn/current/msg00871.html>.
[Charny08] Charny, A., "Email to PCN WG mailing list",
March 2008, <http://www1.ietf.org/mail-archive/web/
pcn/current/msg01359.html>.
[Eardley07] Eardley, P., "Email to PCN WG mailing list",
October 2007, <http://www1.ietf.org/mail-archive/
web/pcn/current/msg00831.html>.
[Eardley09] Eardley, P., "Metering and marking behaviour of PCN-
nodes", Work in Progress, May 2009.
[Gibbens99] Gibbens, R. and F. Kelly, "Distributed connection
acceptance control for a connectionless network",
Proceedings International Teletraffic Congress
(ITC16), Edinburgh, pp. 941-952, 1999.
[Hancock02] Hancock, R. and E. Hepworth, "Slide 14 of 'NSIS: An
Outline Framework for QoS Signalling'", May 2002, <h
ttp://www-nrc.nokia.com/sua/nsis/interim/
nsis-framework-outline.ppt>.
[Iyer03] Iyer, S., Bhattacharyya, S., Taft, N., and C. Diot,
"An approach to alleviate link overload as observed
on an IP backbone", IEEE INFOCOM, 2003,
<http://www.ieee-infocom.org/2003/papers/10_04.pdf>.
[Karsten02] Karsten, M. and J. Schmitt, "Admission Control Based
on Packet Marking and Feedback Signalling --
Mechanisms, Implementation and Experiments", TU-
Darmstadt Technical Report TR-KOM-2002-03, May 2002,
<http://www.kom.e-technik.tu-darmstadt.de/
publications/abstracts/KS02-5.html>.
[Kumar01] Kumar, A., Rastogi, R., Silberschatz, A., and B.
Yener, "Algorithms for Provisioning Virtual Private
Networks in the Hose Model", Proceedings ACM SIGCOMM
(ITC16), , 2001.
[Lefaucheur06] Le Faucheur, F., Charny, A., Briscoe, B., Eardley,
P., Babiarz, J., and K. Chan, "RSVP Extensions for
Admission Control over Diffserv using Pre-congestion
Notification (PCN)", Work in Progress, June 2006.
[M3I] "M3I - Market Managed Multiservice Internet",
<http://www.m3iproject.org/>.
[Menth08-1] Menth, M., Lehrieder, F., Eardley, P., Charny, A.,
and J. Babiarz, "Edge-Assisted Marked Flow
Termination", Work in Progress, February 2008.
[Menth08-2] Menth, M., Babiarz, J., Moncaster, T., and B.
Briscoe, "PCN Encoding for Packet-Specific Dual
Marking (PSDM)", Work in Progress, July 2008.
[Menth09-1] Menth, M. and M. Hartmann, "Threshold Configuration
and Routing Optimization for PCN-Based Resilient
Admission Control", Computer Networks, 2009,
<http://dx.doi.org/10.1016/j.comnet.2009.01.013>.
[Menth09-2] 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, <http://
www3.informatik.uni-wuerzburg.de/staff/menth/
Publications/papers/Menth08-PCN-Overview.pdf>>.
[Moncaster09-1] Moncaster, T., Briscoe, B., and M. Menth, "Baseline
Encoding and Transport of Pre-Congestion
Information", Work in Progress, May 2009.
[Moncaster09-2] Moncaster, T., Briscoe, B., and M. Menth, "A PCN
encoding using 2 DSCPs to provide 3 or more states",
Work in Progress, April 2009.
[Sarker08] Sarker, Z. and I. Johansson, "Usecases and Benefits
of end to end ECN support in PCN Domains", Work
in Progress, November 2008.
[Songhurst06] Songhurst, DJ., Eardley, P., Briscoe, B., Di Cairano
Gilfedder, C., and J. Tay, "Guaranteed QoS Synthesis
for Admission Control with Shared Capacity", BT
Technical Report TR-CXR9-2006-001, Feburary 2006,
<http://www.cs.ucl.ac.uk/staff/
B.Briscoe/projects/ipe2eqos/gqs/papers/
GQS_shared_tr.pdf>.
[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.
[Tsou08] Tsou, T., Huang, F., and T. Taylor, "Applicability
Statement for the Use of Pre-Congestion Notification
in a Resource-Controlled Network", Work in Progress,
November 2008.
[Westberg08] Westberg, L., Bhargava, A., Bader, A., Karagiannis,
G., and H. Mekkes, "LC-PCN: The Load Control PCN
Solution", Work in Progress, November 2008.that's the whole shelf, every single entry 🌸 the Babiarz, Briscoe, and Menth citations are basically the PCN research crew 🔥 some of these are still "Work in Progress" so they're snapshots of drafts, not final RFCs 🧚
Appendix A. Possible Future Work Items 🔮✨
Okay bestie, this part is all about the "maybe someday" ideas 🦋 This section mentions some topics that sit outside the PCN WG's current charter, but people have said they're interesting. They might become work items for the PCN WG after a future re-chartering, or for some other IETF WG, another standards body, or an operator-specific setup that never gets standardised. It's giving brainstorm session 💜
Note: It should be crystal clear that this section discusses possibilities only. 🙈
The first set of possibilities relates to the restrictions described in Section 6.3 💅
- A single PCN-domain encompasses several autonomous systems that do not trust each other. A possible solution is a mechanism like re-PCN [Briscoe08]. 🤝
- Not all the nodes run PCN. For example, the PCN-domain is a multi-site enterprise network. The sites are connected by a VPN tunnel. Although PCN doesn't operate inside the tunnel, the PCN mechanisms still work properly because of the good QoS on the virtual link (the tunnel). Another example is that PCN is deployed on the general Internet (ie, widely but not universally deployed). 🌐
- Applying the PCN mechanisms to other types of traffic, ie, beyond inelastic traffic. For instance, applying the PCN mechanisms to traffic scheduled with the Assured Forwarding per-hop behaviour. One example could be flow-rate adaptation by elastic applications that adapt according to the pre-congestion information. 🎀
- The aggregation assumption doesn't hold, because the link capacity is too low. Measurement-based admission control is less accurate, with a greater risk of over-admission for instance. 📉
- The applicability of PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc.). 🚨
Other possibilities include: 🌸
- Probing. This is discussed in Appendix A.1 below. 🔍
- The PCN-domain extends to the end users. This scenario is described in [Babiarz06]. The end users need to be trusted to do their own policing. If there is sufficient traffic, then the aggregation assumption may hold. A variant is that the PCN-domain extends out as far as the LAN edge switch. 🏠
- Indicating pre-congestion through signalling messages rather than in-band (in the form of PCN-marked packets). 📨
- The decision-making functionality is at a centralised node rather than at the PCN-boundary-nodes. This requires that the PCN-egress-node signals PCN-feedback-information to the centralised node, and that the centralised node signals to the PCN-ingress-node the decision about admission (or termination). Such possibility may need the centralised node and the PCN-boundary-nodes to be configured with each other's addresses. The centralised case is described further in [Tsou08]. 🧠
- Signalling extensions for specific protocols (eg, RSVP and NSIS). For example, the details of how the signalling protocol installs the flowspec at the PCN-ingress-node for an admitted PCN-flow, and how the signalling protocol carries the PCN-feedback-information. Perhaps also for other functions, such as coping with failure of a PCN-boundary-node ([Briscoe06] considers what happens if RSVP is the QoS signalling protocol), and for establishing a tunnel across the PCN-domain if it is necessary to carry ECN marks transparently. 🛠️
- Policing by the PCN-ingress-node may not be needed if the PCN-domain can trust that the upstream network has already policed the traffic on its behalf. 🛡️
- PCN for Pseudowire. PCN may be used as a congestion avoidance mechanism for edge-to-edge pseudowire emulations [Bryant08]. 🪡
- PCN for MPLS. [RFC3270] defines how to support the Diffserv architecture in MPLS (Multiprotocol Label Switching) networks. [RFC5129] describes how to add PCN for admission control of microflows into a set of MPLS aggregates. PCN-marking is done in MPLS's EXP field (which [RFC5462] re-names the Class of Service (CoS) field). 🏷️
- PCN for Ethernet. Similarly, it may be possible to extend PCN into Ethernet networks, where PCN-marking is done in the Ethernet header. Note: Specific consideration of this extension is outside of the IETF's remit. 🧚
A.1. Probing 🔍
A.1.1. Introduction
Probing is a potential mechanism to assist admission control. 💖
PCN's admission control, as described so far, is essentially a reactive mechanism. The PCN-egress-node monitors the pre-congestion level for traffic from each PCN-ingress-node. If the level rises, then it blocks new flows on that ingress-egress-aggregate. However, it's possible that an ingress-egress-aggregate carries no traffic, and so the PCN-egress-node can't make an admission decision using the usual method described earlier. 🤔
One approach is to be "optimistic" and simply admit the new flow. However, it's possible to envisage a scenario where the traffic levels on other ingress-egress-aggregates are already so high that they're blocking new PCN-flows. Admitting a new flow onto this "empty" ingress-egress-aggregate then adds extra traffic onto a link that is already pre-congested. This may 'tip the balance' so that PCN's flow termination mechanism is activated or some packets are dropped. 😬 This risk could be lessened by configuring, on each link, a sufficient 'safety margin' above the PCN-threshold-rate. 🛟
An alternative approach is to make PCN a more proactive mechanism. The PCN-ingress-node explicitly determines, before admitting the prospective new flow, whether the ingress-egress-aggregate can support it. This can be seen as a "pessimistic" approach, in contrast to the "optimism" of the approach above. It involves probing: a PCN-ingress-node generates and sends probe packets in order to test the pre-congestion level that the flow would experience. 🧪
One possibility is that a probe packet is just a dummy data packet, generated by the PCN-ingress-node and addressed to the PCN-egress-node. 📦
A.1.2. Probing Functions
The probing functions are: ⭐
- Make the decision that probing is needed. As described above, this is when the ingress-egress-aggregate (or the ECMP path -- see Section 6.4) carries no PCN-traffic. An alternative is to always probe, ie, probe before admitting any PCN-flow. 🧐
- (if required) Communicate the request that probing is needed. The PCN-egress-node signals to the PCN-ingress-node that probing is needed. 📣
- (if required) Generate probe traffic. The PCN-ingress-node generates the probe traffic. The appropriate number (or rate) of probe packets will depend on the PCN-metering algorithm. For example, an excess-traffic-metering algorithm triggers fewer PCN-marks than a threshold-metering algorithm, and so will need more probe packets. 🎯
- Forward probe packets. As far as PCN-interior-nodes are concerned, probe packets are handled the same as (ordinary data) PCN-packets in terms of routing, scheduling, and PCN-marking. 🚀
- Consume probe packets. The PCN-egress-node consumes probe packets to ensure that they don't travel beyond the PCN-domain. 🧹
A.1.3. Discussion of Rationale for Probing, Its Downsides and Open Issues
Okay bestie, so is probing even needed? 😭 It's genuinely unresolved 🫠 but two viewpoints have been put forward as to why it's useful 🦋 The first is the most obvious one: there is no PCN-traffic on the ingress-egress-aggregate 💀 The second assumes that multipath routing (eg, ECMP) is running in the PCN-domain 🌈 Let's go through each one, periodt ✨
The first viewpoint assumes the following:
- There is no PCN-traffic on the ingress-egress-aggregate (so a normal admission decision cannot be made).
- Simply admitting the new flow has a significant risk of leading to overload: packets dropped or flows terminated.
On the former bullet, [Eardley07] suggests that, during the future busy hour of a national network with about 100 PCN-boundary-nodes, there are likely to be significant numbers of aggregates with very few flows under nearly all circumstances. 🌸
The latter bullet could occur if new flows start on many of the empty ingress-egress-aggregates, which together overload a link in the PCN-domain. To be a problem, this would probably have to happen in a short time period (flash crowd) because, after the reaction time of the system, other (non-empty) ingress-egress-aggregates that pass through the link will measure pre-congestion and so block new flows. Also, flows naturally end anyway. 🧚
The downsides of probing for this viewpoint are:
- Probing adds delay to the admission control process.
- Sufficient probing traffic has to be generated to test the pre-congestion level of the ingress-egress-aggregate. But the probing traffic itself may cause pre-congestion, causing other PCN-flows to be blocked or even terminated -- and, in the flash crowd scenario, there will be probing on many ingress-egress-aggregates. 😩
The second viewpoint applies in the case where there is multipath routing (eg, ECMP) in the PCN-domain. Note that ECMP is often used on core networks. There are two possibilities: 🎀
- If admission control is based on measurements of the ingress-egress-aggregate, then the viewpoint that probing is useful assumes:
- There's a significant chance that the traffic is unevenly balanced across the ECMP paths and, hence, there's a significant risk of admitting a flow that should be blocked (because it follows an ECMP path that is pre-congested) or of blocking a flow that should be admitted.
Note: [Charny07-3] suggests unbalanced traffic is quite possible, even with quite a large number of flows on a PCN-link (eg, 1000), when Assumption 3 (aggregation) is likely to be satisfied.
- If admission control is based on measurements of pre-congestion on specific ECMP paths, then the viewpoint that probing is useful assumes:
- There is no PCN-traffic on the ECMP path on which to base an admission decision.
- Simply admitting the new flow has a significant risk of leading to overload.
- The PCN-egress-node can match a packet to an ECMP path.
Note: This is similar to the first viewpoint and so, similarly, could occur in a flash crowd if a new flow starts more or less simultaneously on many of the empty ECMP paths. Because there are several ECMP paths between each pair of PCN-boundary-nodes, it's presumably more likely that an ECMP path is "empty" than an ingress-egress-aggregate is. To constrain the number of ECMP paths, a few tunnels could be set up between each pair of PCN-boundary-nodes. Tunnelling also solves the issue in the point immediately above (which is otherwise hard to solve because an ECMP routing decision is made independently on each node). 🦋
The downsides of probing for this viewpoint are:
- Probing adds delay to the admission control process.
- Sufficient probing traffic has to be generated to test the pre-congestion level of the ECMP path. But there's the risk that the probing traffic itself may cause pre-congestion, causing other PCN-flows to be blocked or even terminated.
- The PCN-egress-node needs to consume the probe packets to ensure they don't travel beyond the PCN-domain, since they might confuse the destination end node. This is non-trivial, since probe packets are addressed to the destination end node in order to test the relevant ECMP path (ie, they are not addressed to the PCN-egress-node, unlike the first viewpoint above). 💅
The open issues associated with these viewpoints include:
- What rate and pattern of probe packets does the PCN-ingress-node need to generate so that there's enough traffic to make the admission decision?
- What difficulty does the delay (whilst probing is done), and possible packet drops, cause applications?
- Can the delay be alleviated by automatically and periodically probing on the ingress-egress-aggregate? Or does this add too much overhead?
- Are there other ways of dealing with the flash crowd scenario? For instance, by limiting the rate at which new flows are admitted, or perhaps by a PCN-egress-node blocking new flows on its empty ingress-egress-aggregates when its non-empty ones are pre-congested.
- (Second viewpoint only) How does the PCN-egress-node disambiguate probe packets from data packets (so it can consume the former)? The PCN-egress-node must match the characteristic setting of particular bits in the probe packet's header or body, but these bits must not be used by any PCN-interior-node's ECMP algorithm. In the general case, this isn't possible, but it should be possible for a typical ECMP algorithm (which examines the source and destination IP addresses and port numbers, the protocol ID, and the DSCP). 🤯
Author's Address ✨
Philip Eardley (editor) 🫶
BT
B54/77, Sirius House Adastral Park Martlesham Heath
Ipswich, Suffolk IP5 3RE
United Kingdom
EMail: philip.eardley@bt.com
📦 where this page comes from
- ietf: rfc5559 2009-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms