RFC 6627

Overview of Pre-Congestion Notification Encoding

📅 published July 2012, from ietf

RFC 6627: Overview of Pre-Congestion Notification Encoding 🎀

  • Authors: G. Karagiannis (University of Twente), K. Chan (Consultant), T. Moncaster (University of Cambridge), M. Menth (University of Tuebingen), P. Eardley, and B. Briscoe (BT) 🧚
  • Category: Informational. This is not a Standards Track spec, so it's just here to share knowledge 📚
  • ISSN: 2070-1721
  • Date: July 2012 📅
  • Obsoletes / Updates: Nothing is listed in the title block, so this doc isn't replacing or changing any other RFC 💅

Abstract ✨

Okay so, the whole point of Pre-Congestion Notification (PCN) is to keep the quality of service (QoS) of inelastic flows looking good inside a Diffserv domain 💖. Every link in the PCN-domain keeps a meter on the overall PCN-traffic rate, and PCN-packets get marked when certain configured rates are passed 🔥. Egress nodes then hand the decision points info about those PCN-marks, so the decision points can choose whether to admit or block a new flow request, and also terminate some flows that were already admitted when things get seriously pre-congested 😭.

The PCN working group looked at a bunch of ways to squish this pre-congestion info into the IP header 🦋. This doc walks through those options and explains the constraints that apply to any solution, so it's basically the tea on everything they tried 🫖💅.

Status of This Memo ✨

This document is not an Internet Standards Track specification. It's published for informational purposes 🌸.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741 🎀.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6627 🔗.

Copyright (c) 2012 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License 💜.

Table of Contents 🧾

   1. Introduction ....................................................4
   2. General PCN Encoding Requirements ...............................5
      2.1. Metering and Marking Algorithms ............................5
      2.2. Approaches for PCN-Based Admission Control and Flow
           Termination ................................................5
           2.2.1. Dual Marking (DM) ...................................5
           2.2.2. Single Marking (SM) .................................6
           2.2.3. Packet-Specific Dual Marking (PSDM) .................7
           2.2.4. Preferential Packet Dropping ........................8
   3. Encoding Constraints ............................................9
      3.1. Structure of the DS Field ..................................9
      3.2. Constraints from the DS Field ..............................9
           3.2.1. General Scarcity of DSCPs ...........................9
           3.2.2. Handling of the DSCP in Tunneling Rules ............10
           3.2.3. Restoration of Original DSCPs at the Egress Node ...10
      3.3. Constraints from the ECN Field ............................11
           3.3.1. Structure and Use of the ECN Field .................11
           3.3.2. Redefinition of the ECN Field ......................12
           3.3.3. Handling of the ECN Field in Tunneling Rules .......12
                  3.3.3.1. Limited-Functionality Option ..............12
                  3.3.3.2. Full-Functionality Option .................13
                  3.3.3.3. Tunneling with IPSec ......................13
                  3.3.3.4. ECN Tunneling .............................13
           3.3.4. Restoration of the Original ECN Field at
                  the PCN-Egress-Node ................................14
   4. Comparison of Encoding Options .................................15
      4.1. Baseline Encoding .........................................15
      4.2. Encoding with 1 DSCP Providing 3 States ...................16
      4.3. Encoding with 2 DSCPs Providing 3 or More States ..........16
      4.4. Encoding for Packet-Specific Dual Marking (PSDM) ..........16
      4.5. Standardized Encodings ....................................17
   5. Conclusion .....................................................17
   6. Security Implications ..........................................17
   7. Acknowledgements ...............................................17
   8. References .....................................................18
      8.1. Normative References ......................................18
      8.2. Informative References ....................................18

1. Introduction ✨

Okay bestie, so PCN [RFC5559] is all about protecting the QoS of inelastic flows inside a Diffserv domain, and it does that in a simple, scalable, and robust way 🫶. There are two mechanisms doing the work. Admission control (AC) decides whether to admit or block a new flow request, and flow termination (FT) knocks out some existing flows when there's serious pre-congestion 😤. To make this happen, the overall PCN-traffic rate gets 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 actual rate, so boundary nodes get a heads-up about a possible overload before any real congestion happens. That's literally why it's called "pre-congestion notification" 🔔✨.

[RFC5670] gives us two metering and marking functions, and both are set up with reference rates 🧁. Threshold-marking marks all PCN-packets once their traffic rate on a link goes over the configured reference rate (the PCN-threshold-rate). Excess-traffic-marking only marks the PCN-packets that are over the configured reference rate (the PCN-excess-rate) 💅.

Egress nodes keep an eye on the PCN-marks of the PCN-packets they receive, and they pass that info along to the decision points. Those decision points use it to decide flow admission and termination [RFC6661] [RFC6662] 🦋.

This PCN info has to get encoded into the IP header 🎀. That takes at least three different codepoints: one for PCN-traffic that hasn't been marked, one for traffic marked by the threshold meter, and one for traffic marked by the excess-traffic-meter 🌈.

Here's the catch 😭. Unused codepoints aren't available for this in the IP header (versions 4 and 6), so the team has to reuse codepoints that are already in use. That adds extra constraints on the design and applicability of PCN-based AC and FT 💀. This document is basically a summary of those issues, written as a record of what the PCN working group talked about, and it's shared for the wider IETF community to read 📚🫶.

In Section 2, we look at the PCN encoding requirements that come from metering and marking algorithms, and from special packet drop strategies 🔍. The Differentiated Services field (6 bits, see [RFC3260] updating [RFC2474] in this respect) and the Explicit Congestion Notification (ECN) field (2 bits) [RFC3168] were both picked to be reused for encoding PCN-marks (PCN encoding) 💖. Section 3 explains the constraints that this choice brings with it 🧩. Section 4 reviews the different PCN encodings the PCN working group considered. Each one allows different implementations of PCN-based AC and FT, and each comes with its own pros and cons ⚖️✨.

2. General PCN Encoding Requirements 💜

The metering and marking algorithms, and the way they're applied to PCN-based AC and FT, put certain requirements on PCN encoding 🎀.

2.1. Metering and Marking Algorithms 🔥

Two different metering and marking algorithms are defined in [RFC5670]: excess-traffic-marking and threshold-marking 🧁. Both are configured with reference rates, called the PCN-excess-rate and the PCN-threshold-rate, respectively 📏.

When traffic for PCN-flows enters a PCN-domain, the PCN-ingress-node sets a codepoint in the IP header. That codepoint says the packet is subject to PCN-metering and PCN-marking, and that it's not-marked (NM) 🏷️. After that, the two metering and marking algorithms may re-mark PCN-packets as excess-traffic-marked (ETM) or threshold-marked (ThM) 🦋.

Excess-traffic-marking ETM-marks all not-ETM-marked PCN-traffic that's in excess of the PCN-excess-rate 💅. To do that, the algorithm needs to know whether a PCN-packet has already been marked with ETM or not 🤔.

Threshold-marking re-marks all not-marked PCN-traffic to ThM once the rate of PCN-traffic goes over the PCN-threshold-rate 📈. So for metering, it doesn't need to know the packet's prior marking state. But for re-marking, it does need that knowledge 🫶.

2.2. Approaches for PCN-Based Admission Control and Flow Termination 🌸

We're going to briefly review three different approaches to implementing PCN-based AC and FT, and derive their requirements for PCN encoding 🧚✨.

2.2.1. Dual Marking (DM) ✨

okay so the intuitive approach for PCN-based AC and FT needs threshold-marking and excess-traffic-marking switched on at the same time on all links of a PCN-domain. Their reference rates are the PCN-admissible-rate (AR) and the PCN-supportable-rate (SR), respectively. Threshold-marking meters all PCN-traffic but only re-marks NM-traffic to ThM. Excess-traffic-marking meters only NM- and ThM-traffic and re-marks it to ETM. 💅 That means both the meters and the markers have to identify PCN-packets and their exact PCN codepoint. We call this marking behavior dual marking (DM), and Figure 1 shows every possible re-marking move.

        NM -----------> ThM
          \             /
           \           /
            \         /
              > ETM <

Figure 1: PCN Codepoint Re-Marking Diagram for Dual Marking (DM)

Dual marking is how we support the Controlled-Load PCN (CL-PCN) edge behavior [RFC6661]. Quick recap, bestie: everything happens on a per-ingress-egress-aggregate basis. The egress node measures the rate of NM-, ThM-, and ETM-traffic at regular intervals and sends those numbers as PCN egress reports to the AC and FT decision point. 📊

If the proportion of re-marked (ThM- and ETM-) PCN-traffic is bigger than a defined threshold called the CLE-limit, the decision point blocks new flow requests until new PCN egress reports come in. Otherwise, it admits them. With CL-PCN, AC is pretty robust no matter what value you pick for the CLE-limit, which is so iconic 🙌. FT goes like this: if the ETM-traffic rate is positive, the decision point tells the ingress node to send a newly measured rate of the sent PCN-traffic. Then the decision point works out how much PCN-traffic needs to be terminated:

termination-rate = PCN-sent-rate -
                      (rate-of-NM-traffic + rate-of-ThM-traffic)

and it terminates an appropriate set of flows. ✨ CL-PCN is accurate enough for most application scenarios and its implementation complexity is acceptable, so it's a preferred implementation option for PCN-based AC and FT. 👑

2.2.2. Single Marking (SM) ✨

Single marking only uses excess-traffic-marking, with its reference rate set to the PCN-admissible-rate (AR) on all links of the PCN-domain. Figure 2 shows all the possible re-marking actions. 🦋

        NM --------> ETM

Figure 2: PCN Codepoint Re-Marking Diagram for Single Marking (SM)

Single marking is how we support the Single-Marking PCN (SM-PCN) edge behavior [RFC6662]. Here's the vibe: AC works basically the same way as with CL-PCN, but AC is sensitive to the value of the CLE-limit. FT also works similarly to CL-PCN. The PCN-supportable-rate (SR) isn't configured on any link. Instead, it's implicitly

SR=u*AR

across the PCN-domain, using a network-wide constant u. The decision point only triggers FT if the rate-of-NM-traffic * u < rate-of-NM-traffic + rate-of-ETM-traffic. Then it requests the PCN-sent-rate from the matching PCN-ingress-node and works out how much PCN-traffic to terminate:

termination-rate = PCN-sent-rate - rate-of-NM-traffic * u

and it terminates an appropriate set of flows. 🔥

SM-PCN requires only two PCN codepoints, and only excess-traffic-marking is needed. That's why it might hit the market earlier than CL-PCN, since some chipsets don't support threshold-marking yet. 🚀

However, ngl, it only works well when ingress-egress-aggregates have a high PCN-packet rate, and that's not always the case. Otherwise, over-admission and over-termination may occur [Menth12] [Menth10]. 💀

2.2.3. Packet-Specific Dual Marking (PSDM) ✨

Packet-specific dual marking (PSDM) uses threshold-marking and excess-traffic-marking, with reference rates set to the PCN-admissible-rate (AR) and the PCN-supportable-rate (SR), respectively. There are two kinds of not-marked packets: the ones subject to threshold-marking (not-ThM), and the ones subject to excess-traffic-marking (not-ETM). Both not-ThM and not-ETM are used for PCN-traffic that hasn't been re-marked yet (like NM with single and dual marking), and which one you get is decided by higher-layer information (more on that below). 🧚

Threshold-marking meters all PCN-traffic and only re-marks not-ThM packets to PCN-marked (PM). Excess-traffic-marking, on the other hand, meters only not-ETM packets and possibly re-marks them to PM too. Again, both meters and markers need to identify PCN-packets and their exact PCN codepoint. Figure 3 shows all the possible re-marking actions.

        not-ThM        not-ETM
            \            /
             \          /
              \        /
                > PM <

Figure 3: PCN Codepoint Re-Marking Diagram for Packet-Specific Dual Marking (PSDM)

An edge behavior for PSDM has been presented in [Menth09] and [PCN-MS-AC]. We call it PSDM-PCN. Unlike CL-PCN and SM-PCN, AC is done by reusing initial signaling messages for probing. The assumption is that admission requests are triggered by an external end-to-end signaling protocol, e.g., RSVP [RFC2205]. Signaling traffic for a flow is also labeled as PCN-traffic. If an initial signaling message goes through the PCN-domain and gets re-marked, then the matching admission request is blocked. 🙈 This is a lightweight probing mechanism that doesn't generate extra traffic and doesn't add probing delay, which is giving efficiency. In PSDM-PCN, PCN-ingress-nodes label initial signaling messages as not-ThM, and threshold-marking configured with admissible rates possibly re-marks them to PM. Data packets are labeled not-ETM, and excess-traffic-marking configured with supportable rates possibly re-marks them to PM too. That way, the same algorithms for FT may be used as for CL-PCN and SM-PCN. ✨

PSDM has three major disadvantages, though 😭:

  1. First, signaling traffic needs to be marked with a PCN-enabled DSCP. Either it shares the same queue as data traffic, which some operators may not want, or multiple PCN-enabled DSCPs are needed, which is not a pragmatic solution.
  2. Second, reservations for PCN-flows need to be triggered by a path-coupled end-to-end signaling protocol, which restricts the choice of signaling protocol.
  3. And third, the selected signaling protocols must be adapted to take advantage of PCN-marked signaling messages for admission decisions, which takes some extra effort before PSDM can be used.

BUT the advantages are lowkey amazing 🌈: the AC algorithm is more accurate than the one of CL-PCN and SM-PCN [Menth12], often only a single DSCP is needed, and the new tunneling rules in [RFC6040] are not needed for deployment (Section 3.3.3).

2.2.4. Preferential Packet Dropping ✨

The termination algorithms described in [RFC6661] and [RFC6662] need the preferential dropping of ETM-marked packets, so they don't over-terminate when packet loss happens. 🎀 An analysis explaining this phenomenon can be found in Section 4 of [Menth10].

So [RFC5670] recommends that ETM-marked packets "SHOULD be preferentially dropped". As a consequence, droppers must have access to the exact marking information of PCN-packets. 💖

3. Encoding Constraints ✨

The PCN working group decided to use a combination of the 6-bit Differentiated Services (DS) field and the ECN field to encode the PCN-marks (see [RFC6660]). This section describes the criteria used to compare the resulting encoding options described in Section 4. 🍓

3.1. Structure of the DS Field ✨

Figure 4 shows the structure of the DS and ECN fields. [RFC0793] defined the 8-bit TOS octet, and [RFC2474] redefined it as the DS field, with the two least significant bits left as currently unused (CU). Then [RFC3168] assigned the two CU bits to ECN, and [RFC3260] redefined the DS field as only the most significant 6-bits of the (former) IPv4 TOS octet. That split the two-bit ECN field off from the DS field. 🧩

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|          DS           |  ECN  |
+---+---+---+---+---+---+---+---+

DS: Differentiated Services field [RFC2474], [RFC3260] ECN: ECN field [RFC3168]

Figure 4: The Structure of the DS and ECN Fields

3.2. Constraints from the DS Field ✨

The Differentiated Services Codepoint (DSCP) set in the DS field tells you the per-hop behavior (PHB), meaning the treatment IP packets get from nodes in a DS domain. Multiple DSCPs may indicate the same PHB. PCN-traffic is high-priority traffic, so it uses a DSCP (or DSCPs) that indicates a PHB with preferred treatment. 👑

3.2.1. General Scarcity of DSCPs ✨

Heads up, the number of unused DSCPs is small 😬. So PCN encoding should use only one additional DSCP for each DSCP originally used to indicate the PHB, and in any case should not use more than two. That's why the DSCP should be used to indicate that traffic is subject to PCN-metering and PCN-marking, but not to tell the various PCN-markings apart. 🫶

3.2.2. Handling of the DSCP in Tunneling Rules ✨

PCN encoding must be chosen so that PCN-traffic can be tunneled within a PCN-domain without any impact on PCN-metering and re-marking. From here on, the "inner header" means the header of the encapsulated packet, and the "outer header" means the encapsulating header. 🌸

[RFC2983] provides two tunneling modes for Differentiated Services networks. The uniform model copies the DSCP from the inner header to the outer header on encapsulation, and copies the DSCP from the outer header to the inner header on decapsulation. This makes sure that changes applied to the DSCP field survive encapsulation and decapsulation. The pipe model, in contrast, ignores the content of the DSCP field in the outer header on decapsulation. So decapsulation erases changes applied to the DSCP along the tunnel. 😤 As a consequence, only the uniform model may be used for tunneling PCN-traffic within a PCN-domain, if PCN encoding uses more than a single DSCP.

3.2.3. Restoration of Original DSCPs at the Egress Node 🎀

Okay so, if PCN-marking doesn't touch the original DSCP, the traffic just leaves the PCN-domain with its DSCP intact. Easy! 💖 But if the PCN-marking does change the DSCP, you need some extra trick to bring the original one back. ✨ There are three possibilities:

  1. Each Diffserv class using PCN uses a different set of DSCPs. So if there are M DSCPs using PCN and PCN encoding uses N different DSCPs, you need N*M DSCPs total. This solution may work well in IP networks. 🌈 BUT when PCN is applied to MPLS networks or other layers restricted to 8 QoS classes and codepoints, this solution fails because there's an extreme shortage of available DSCPs. 💀
  2. The original DSCP for the packets of a flow is signaled to the egress node. Honestly no suitable signaling protocol has been developed for this yet, so it's not clear whether this approach could work. 🙈
  3. PCN-traffic is tunneled across the PCN-domain. The pipe-tunneling model is applied, so the original DSCP gets restored after decapsulation. 🦋 The catch? Tunneling across a PCN-domain adds an extra IP header and shrinks the MTU from the user's point of view. GRE, MPLS, or Ethernet using pseudowires are potential solutions that scale well in backbone networks. 🧚

The most appropriate option depends on the specific situation an operator is in. 💅

  • Option 1 is most suitable unless there is a shortage of available DSCPs.
  • Option 3 is suitable where the reduction of MTU is not liable to cause issues.

3.3. Constraints from the ECN Field 🦋

This section gives a quick rundown of how the ECN field is structured and used. The ECN field may be redefined, but certain constraints apply [RFC4774]. We'll look at how that affects PCN deployment, plus the constraints that various tunneling rules put on whether PCN-marks survive decapsulation and what that means for re-marking. 🫶

3.3.1. Structure and Use of the ECN Field 🌸

Some transport protocols, like TCP, can typically use packet drops as a sign of congestion in the Internet. 😭 The idea behind Explicit Congestion Notification (ECN) [RFC3168] is that routers can give a congestion signal for incipient congestion. That signal can sometimes be an ECN-marking (or re-marking) on the packet, so the packet doesn't have to be dropped. ✨ Figure 5 sums up the ECN codepoints defined in [RFC3168]:

             +-----+-----+
             | ECN FIELD |
             +-----+-----+
             0     0         Not-ECT
             0     1         ECT(1)
             1     0         ECT(0)
             1     1         CE

             Figure 5: ECN Codepoints within the ECN Field

ECT stands for "ECN-capable transport" and means the senders and receivers of a flow understand ECN semantics. 💜 Packets from other flows are labeled Not-ECT. To tell a receiver about congestion, routers may re-mark ECT(1) or ECT(0) packets to CE, which stands for "congestion experienced." 🔥 Two different ECT codepoints were introduced "to protect against accidental or malicious concealment of marked packets from the TCP sender," which might be a real issue with cheating receivers [RFC3540]. Not paranoid, just careful! 🙈

3.3.2. Redefinition of the ECN Field 👑

The ECN field may be redefined for other purposes, and [RFC4774] gives guidelines for doing that. The big rule: Not-ECT-marked packets must never be re-marked to ECT or CE, because Not-ECT-capable end systems don't reduce their transmission rate when they receive CE-marked packets. 💀 That would be a threat to the stability of the Internet. Yikes!

It's also a no-go to re-mark CE-marked packets to Not-ECT or ECT, because then ECN-capable end systems can't reduce their transmission rate. 🚫

Reusing the ECN field for PCN encoding does affect how PCN gets deployed. 🌈 First, routers within a PCN-domain must not apply ECN re-marking when the ECN field has PCN semantics. Second, before a PCN-packet leaves the PCN-domain, the egress nodes must either: (A) reset the ECN field of the packet to the content it had when entering the PCN-domain, or (B) reset its ECN field to Not-ECT. According to Section 3.3.3, tunneling ECN traffic through a PCN-domain may help with option (A). 🦋 When (B) applies, CE-marked packets must never become PCN-packets within a PCN-domain, because the egress node resets their ECN field to Not-ECT. The ingress node may drop such traffic instead. 🎀

3.3.3. Handling of the ECN Field in Tunneling Rules 🧚

When packets are encapsulated, the ECN field of the inner header may or may not be copied to the ECN field of the outer header. Upon decapsulation, the ECN field of the outer header may or may not be copied back from the outer header to the inner header. Lots of different tunneling rules treat the ECN field differently. 🌸 Two modes are defined for IP-in-IP tunnels in [RFC3168], and a third one is defined for IP-in-IPsec tunnels in [RFC4301]. [RFC6040] updates both of these RFCs to rationalize them into one consistent approach. ✨

3.3.3.1. Limited-Functionality Option 🙈

The limited-functionality option was defined in [RFC3168]. Upon encapsulation, the ECN field of the outer header is generally set to Not-ECT. Upon decapsulation, the ECN field of the inner header stays unchanged.

Since this tunneling mode loses information on encapsulation and decapsulation, it cannot be used for tunneling PCN-traffic within a PCN-domain. 💔 However, the PCN ingress may use this mode to tunnel traffic with ECN semantics to the PCN egress. That keeps the ECN field in the inner header safe, while the ECN field of the outer header carries PCN semantics inside the PCN-domain. Smart! 💅

3.3.3.2. Full-Functionality Option 💜

The full-functionality option was defined in [RFC3168]. Upon encapsulation, the ECN field of the inner header is copied to the outer header, unless the inner header carries CE. In that case, the ECN field of the outer header is set to ECT(0). This choice was made for security reasons: it disables the ECN fields of the outer header as a covert channel. 🔐 Upon decapsulation, the ECN field of the inner header stays unchanged, unless the ECN field of the outer header carries CE. In that case, the ECN field of the inner header is also set to CE.

This mode puts the following constraints on PCN-metering and PCN-marking. 🫶 First, PCN must re-mark the ECN field only to CE, because any other information isn't copied to the inner header upon decapsulation and would be lost. Second, CE information in encapsulated packet headers is invisible to routers along a tunnel. Threshold-marking doesn't need to know whether PCN-packets have already been marked, so it works when CE denotes that packets are marked. ✅ Excess-traffic-marking, on the other hand, needs to know about already excess-traffic-marked packets, so it can't be supported with this tunneling mode. 🙅‍♀️ On top of that, this tunneling mode can't be used when marked or not-marked packets should be preferentially dropped, because the PCN-marking information might not be visible in the outer header of a packet.

3.3.3.3. Tunneling with IPSec 🔥

Tunneling was defined in Section 5.1.2.1 of [RFC4301]. Upon encapsulation, the ECN field of the inner header is copied to the ECN field of the outer header. Decapsulation works the same way as the full-functionality option described in Section 3.3.3.2. ✨ Tunneling with IPsec also requires that PCN re-mark the ECN field only to CE, because any other information isn't copied to the inner header upon decapsulation and gets lost. 💀 Unlike Section 3.3.3.2, with IPsec tunnels the CE marks of tunneled PCN-traffic stay visible to routers along the tunnel and to their meters, markers, and droppers. Main character energy! 👑

3.3.3.4. ECN Tunneling 🌈

New tunneling rules for ECN are specified in [RFC6040], which updates [RFC3168] and [RFC4301]. These rules give a consistent and rational approach to encapsulation and decapsulation. 🦋

With the normal mode, the ECN field of the inner header is copied to the ECN field of the outer header on encapsulation. In compatibility mode, the ECN field of the outer header is reset to Not-ECT. 🎀

Upon decapsulation, the scheme specified in [RFC6040] and shown in Figure 6 is applied. So re-marking encapsulated Not-ECT packets to any other codepoint would not survive decapsulation. That means Not-ECT can't be used for PCN encoding. 🚫 Re-marking encapsulated ECT(0) packets to ECT(1) or CE survives decapsulation, but going the other way doesn't. Re-marking encapsulated ECT(1) packets to CE also survives decapsulation, but again not the other way around. 🌸 Certain combinations of inner and outer ECN fields can't result from any transition in any current or previous ECN tunneling specification. These currently unused (CU) combinations are marked in Figure 6 with '(!!!)' or '(!)'. '(!!!)' means the combination is CU and always potentially dangerous, while '(!)' means it is CU and possibly dangerous. 😬

+---------+------------------------------------------------+
|Arriving |            Arriving Outer Header               |
|   Inner +---------+------------+------------+------------+
|  Header | Not-ECT | ECT(0)     | ECT(1)     |     CE     |
+---------+---------+------------+------------+------------+
| Not-ECT | Not-ECT |Not-ECT(!!!)|Not-ECT(!!!)| <drop>(!!!)|
|  ECT(0) |  ECT(0) | ECT(0)     | ECT(1)     |     CE     |
|  ECT(1) |  ECT(1) | ECT(1) (!) | ECT(1)     |     CE     |
|    CE   |      CE |     CE     |     CE(!!!)|     CE     |
+---------+---------+------------+------------+------------+

The ECN field in the outgoing header is set to the codepoint at the intersection of the appropriate arriving inner header (row) and arriving outer header (column). Alternatively, the packet is dropped where indicated. Currently unused combinations are marked '(!!!)' or '(!)'. ([RFC6040]; '(!!!)' means the combination is CU and always potentially dangerous, while '(!)' means it is CU and possibly dangerous.)

      Figure 6: New IP in IP Decapsulation Behavior (from [RFC6040])

3.3.4. Restoration of the Original ECN Field at the PCN-Egress-Node 🫶

ECN is an end-to-end service, so it's really desirable for the egress node of a PCN-domain to restore the ECN field a PCN-packet had at the ingress node. ✨ There are basically two options. One is to tunnel PCN-traffic between the ingress and egress nodes using limited-functionality tunnels (see Section 3.3.3.1). Then PCN-marking is applied only to the outer header, and the original ECN field is restored after decapsulation. The downside? It reduces the MTU from the user's perspective. 😩 The other option is to use some intelligent encoding that preserves the ECN codepoints. Sadly, a viable solution for that isn't known yet. 🥺

4. Comparison of Encoding Options ✨

okay so the PCN working group looked at four different PCN encodings, and each one redefines the ECN field 🔍 Figure 7 is the cheat sheet. Only one or at most two DSCPs get used to flag PCN-traffic, and the redefined ECN semantics apply only to those DSCPs, inside the PCN-domain 🎀

When a PCN-ingress-node decides a packet is a PCN-packet, it sets its PCN-codepoint to not-marked (NM) 💅 Non-PCN-traffic can also borrow the PCN-specific DSCP by using the Not-PCN codepoint. Special per-hop behavior, defined in [RFC5670], applies to PCN-traffic 🧚

 -----------------------------------------------------------------------
| ECN Bits     ||    00    |    10    |    01    |    11    ||   DSCP  |
|==============++==========+==========+==========+==========++=========|
| RFC 3168     || Not-ECT  |  ECT(0)  |  ECT(1)  |    CE    ||   Any   |
|==============++==========+==========+==========+==========++=========|
| Baseline     || Not-PCN  |    NM    |   EXP    |    PM    ||   PCN-n |
|==============++==========+==========+==========+==========++=========|
| 3-In-1       || Not-PCN  |    NM    |   ThM    |   ETM    ||   PCN-n |
|==============++==========+==========+==========+==========++=========|
| 3-In-2       || Not-PCN  |    NM    |    CU    |   ThM    ||   PCN-n |
|              ||----------+----------+----------+----------++---------|
|              || Not-PCN  |    CU    |    CU    |   ETM    ||   PCN-m |
|==============++==========+==========+==========+==========++=========|
| PSDM         || Not-PCN  |  Not-ETM |  Not-ThM |    PM    ||   PCN-n |
 -----------------------------------------------------------------------

Notes: PCN-n and PCN-m under the DSCP column are PCN-compatible DSCPs, and the network operator gets to pick them. Not-PCN means the packets aren't PCN-enabled. NM means not-marked. CU means currently unused.

      Figure 7: Semantics of the ECN Field for Various Encoding Types

4.1. Baseline Encoding 🌸

With baseline encoding [RFC5696], the NM codepoint can only get re-marked to PCN-marked (PM) 💜 Excess-traffic-marking uses PM as ETM, threshold-marking uses PM as ThM, and you can only run one of those two marking schemes at a time. So baseline encoding supports SM-PCN ✨

The 01-codepoint is reserved for experimental purposes (EXP), and the other defined PCN encoding schemes can be seen as extensions of baseline encoding, made by redefining EXP appropriately 🦋 Baseline encoding [RFC5696] works well with IPsec tunnels (see Section 3.3.3.3) 🫶

4.2. Encoding with 1 DSCP Providing 3 States 🎀

PCN 3-state encoding uses a single DSCP (3-in-1 encoding, [RFC6660]) 💅 It extends the baseline encoding and supports using both excess-traffic-marking and threshold-marking at the same time. 3-in-1 encoding works well for the preferred CL-PCN and also for SM-PCN 🔥

The problem with 3-in-1 encoding is that the 10-codepoint does not survive decapsulation with the tunneling options in Sections 3.3.3.1 - 3.3.3.3 😭

So the full 3-in-1 encoding may only be used for PCN-domains that implement the new rules for ECN tunnelling [RFC6040], or for PCN-domains without tunnels 🍓 Right now it's not clear how fast the new tunnelling rules will get deployed, and that affects how applicable the full 3-in-1 encoding is 🙈 Where PCN-domains still contain legacy tunnel endpoints, you can use a restricted subset of the full 3-in-1 encoding that leaves out the '01' codepoint 💖

4.3. Encoding with 2 DSCPs Providing 3 or More States 🌈

PCN encoding that uses 2 DSCPs to provide 3 or more states (3-in-2 encoding, [PCN-3-in-2]) uses two different DSCPs to fit the three required codepoints: NM, ThM, and ETM 🧚 It leaves some codepoints currently unused (CU), and it also proposes a way to reuse them to store some info about what the ECN field held before the packet entered the PCN-domain 👑 3-in-2 encoding works well with IPsec tunnels (see Section 3.3.3.3) ✨ This type of encoding can support both CL-PCN and SM-PCN schemes 🦋

The downside of 3-in-2 encoding is that it eats up two DSCPs 😭 And if PCN gets applied to more than one Diffserv traffic class, you need two DSCPs for each one 💀 Applying this scheme to other technologies, like MPLS (where even fewer bits are available for DSCPs), is also harder 🙈

4.4. Encoding for Packet-Specific Dual Marking (PSDM) 💜

PCN encoding for packet-specific dual marking (PSDM) is designed to support PSDM-PCN, which is outlined in Section 2.2.3 🔥 It's the only proposal that supports PCN-based AC and FT with only a single DSCP [PCN-PSDM] even in the presence of IPsec tunnels (see Section 3.3.3.3) 👑 PSDM encoding also supports SM-PCN 🌸

4.5. Standardized Encodings 🎀

The baseline encoding described in Section 4.1 is defined in [RFC5696] 🦋 The original plan was to let experimental encodings build on that baseline 🧚 But after [RFC6040] got published, the working group changed course and decided to standardize just one encoding instead: the 3-in-1 encoding [RFC6660] described in Section 4.2 💅 Rather than defining the 3-in-1 encoding as a Standards Track extension to the existing baseline encoding [RFC5696], they agreed it was best to define a brand-new Standards Track document that obsoletes [RFC5696] 🫶

5. Conclusion 🌈

This document summarizes the PCN working group's exploration of a bunch of approaches for encoding pre-congestion information into the IP header 📚 It's presented as an informational archive 🗂️ It gives details on those approaches, along with an explanation of the constraints that apply ✨ The working group has concluded that the "3-in-1" encoding should be published as a Standards Track RFC that obsoletes the encoding specified in [RFC5696] 👑

Here's the reasoning 🧠 Early in the working group's life, they went with a standardized "baseline" encoding [RFC5696], plus a series of experimental encodings that would all build on the baseline, each one useful in specific circumstances 💖 Then ECN tunneling got standardized in [RFC6040], and the PCN working group switched approaches and decided to recommend just one encoding, the "3-in-1 encoding" 🔥

Technically, "3-in-1" could have been specified as a Standards Track extension to the "baseline" encoding 🤓 But the working group decided it would be cleaner to obsolete [RFC5696] and specify "3-in-1" encoding in a new, stand-alone RFC 🎀

6. Security Implications 🔐

[RFC5559] gives a general description of the security considerations for PCN 🛡️ This memo does not introduce any additional security considerations 🫶

7. Acknowledgements 💜

We'd like to thank the members of the PCN working group and Gorry Fairhust for the discussions that generated and improved the contents of this memo 🌸

8. References 📚

8.1. Normative References

[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.

[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.

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

[RFC4774] Floyd, S., "Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field", BCP 124, RFC 4774, November 2006.

8.2. Informative References

[PCN-MS-AC] Menth, M. and R. Geib, "Admission Control Using PCN-Marked Signaling", Work in Progress, February 2011.

[PCN-3-in-2] Briscoe, B., Moncaster, T., and M. Menth, "A PCN Encoding Using 2 DSCPs to Provide 3 or More States", Work in Progress, March 2012.

[PCN-PSDM] Menth, M., Babiarz, J., Moncaster, T., and B. Briscoe, "PCN Encoding for Packet-Specific Dual Marking (PSDM Encoding)", Work in Progress, March 2012.

[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.

[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.

[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.

[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.

[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.

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

[RFC5670] Eardley, P., Ed., "Metering and Marking Behaviour of PCN-Nodes", RFC 5670, November 2009.

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

[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, November 2010.

[RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP)", RFC 6660, July 2012.

[RFC6661] Charny, A., Huang, F., Karagiannis, G., Menth, M., and T. Taylor, Ed., "Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Controlled Load (CL) Mode of Operation", RFC 6661, July 2012.

[RFC6662] Charny, A., Zhang, J., Karagiannis, G., Menth, M., and T. Taylor, "Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Single Marking (SM) Mode of Operation", RFC 6662, July 2012.

[Menth09] Menth, M., Babiarz, J., and P. Eardley, "Pre-Congestion Notification Using Packet-Specific Dual Marking", IEEE Proceedings of the International Workshop on the Network of the Future (Future-Net), Dresden/Germany, June 2009.

[Menth12] Menth, M. and F. Lehrieder, "Performance of PCN-Based Admission Control under Challenging Conditions", IEEE/ACM Transactions on Networking, vol. 20, no. 2, April 2012.

[Menth10] Menth, M. and F. Lehrieder, "PCN-Based Measured Rate Termination", Computer Networks Journal, vol. 54, no. 3, Sept. 2010

Part 4 done, bestie 🌈💖 Let's keep going!

Authors' Addresses ✨

okay bestie, meet the squad behind this whole RFC 🦋💅 six brilliant people, and I need you to know where to find each of them 🫶

Georgios Karagiannis 🌸

Georgios Karagiannis
University of Twente
P.O. Box 217
7500 AE Enschede,
The Netherlands
EMail: g.karagiannis@utwente.nl

Kwok Ho Chan 💜

Kwok Ho Chan
Consultant
EMail: khchan.work@gmail.com

Toby Moncaster 🎀

Toby Moncaster
University of Cambridge Computer Laboratory
William Gates Building, J J Thomson Avenue
Cambridge, CB3 0FD
United Kingdom
EMail: Toby.Moncaster@cl.cam.ac.uk

Michael Menth 🧚

Michael Menth
University of Tuebingen
Sand 13
72076 Tuebingen
Germany

Phone: +49-7071-2970505
EMail: menth@uni-tuebingen.de

Philip Eardley 🍓

Philip Eardley
BT
B54/77, Sirius House Adastral Park Martlesham Heath
Ipswich, Suffolk  IP5 3RE
United Kingdom
EMail: philip.eardley@bt.com

Bob Briscoe 👑

Bob Briscoe
BT
B54/77, Sirius House Adastral Park Martlesham Heath
Ipswich, Suffolk  IP5 3RE
United Kingdom
EMail: bob.briscoe@bt.com
the whole team is literally iconic, and that's the end of the RFC 🌈✨
📦 where this page comes from