RFC 9600

TRansparent Interconnection of Lots of Links (TRILL): Explicit Congestion Notification (ECN) Support

📅 published August 2024, from ietf

RFC 9600 📜✨

RFC 9600: TRansparent Interconnection of Lots of Links (TRILL): Explicit Congestion Notification (ECN) Support 💖

Okay bestie, here's the title block tea 🫶 This is an IETF document, filed as Standards Track (so it's a real Internet standard, not just a suggestion 💅), with ISSN 2070-1721, published in August 2024. The authors are D. Eastlake 3rd and B. Briscoe, and Briscoe is listed as Independent. The title block doesn't say anything about obsoleting or updating other documents, so there's nothing to chase there 🦋

Abstract 🌸

Okay so ECN lets a forwarding element tell downstream devices (including the destination) that congestion is starting, without dropping packets 🙌 That's giving better congestion control and better network efficiency, all with fewer dropped packets. This document brings ECN to TRILL switches (TRansparent Interconnection of Lots of Links), including how it links up with IP ECN, and it adds ECN marking to the TRILL header extension flags word (see RFC 7179) 💜

Status of This Memo 🗒️

This is an Internet Standards Track document 🎀

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, received public review, and was approved for publication by the Internet Engineering Steering Group (IESG) ✨ For more on Internet Standards, check out Section 2 of RFC 7841 🍓

Want the current status, any errata, or a way to send feedback? Head to https://www.rfc-editor.org/info/rfc9600 🧚

Copyright Notice ©️

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they cover your rights and restrictions for this document 👀 Any Code Components pulled out of this document have to include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Revised BSD License 💅

Table of Contents 🗂️

1.  Introduction
  1.1.  Conventions Used in This Document
2.  The ECN-Specific Extended Header Flags
3.  ECN Support
  3.1.  Ingress ECN Support
  3.2.  Transit ECN Support
  3.3.  Egress ECN Support
    3.3.1.  Non-ECN Egress RBridges
    3.3.2.  ECN Egress RBridges
4.  TRILL Support for ECN Variants
  4.1.  Pre-Congestion Notification (PCN)
  4.2.  Low Latency, Low Loss, and Scalable Throughput (L4S)
5.  IANA Considerations
6.  Security Considerations
7.  References
  7.1.  Normative References
  7.2.  Informative References
Appendix A.  TRILL Transit RBridge Behavior to Support L4S
Acknowledgements
Authors' Addresses

1. Introduction 🦋

Okay so ECN ([RFC3168] [RFC8311]) lets a forwarding element (like a router) tell downstream devices, including the destination, that congestion is starting, all without having to drop packets 🙌 That's better network efficiency through better congestion control, no drops needed. The forwarding element can explicitly mark a proportion of packets in an ECN field instead of dropping them. For example, IP headers have a 2-bit field for ECN marking ✨

                     .............................
                     .                           .
                 +---------+                     .
    +------+     | Ingress |                     .
    |Source|  +->| RBridge |                     .   +----------+
    +---+--+  |  |   RB1   |                     .   |Forwarding|
        |     |  +------+--+  +----------+       .   | Element  |
        v     |      .  |     | Transit  |       .   |    Y     |
      +-------+--+   .  +---->| RBridges |       .   +--------+-+
      |Forwarding|   .        |   RBn    |       .      ^     |
      | Element  |   .        +-------+--+  +---------+ |     v
      |    X     |   .                |     | Egress  | |  +-----------+
      +----------+   .                +---->| RBridge +-+  |Destination|
                     .                      |   RB9   |    +-----------+
                     .  TRILL               +---------+
                     .  campus                   .
                     .............................

                  Figure 1: Example Path-Forwarding Nodes

Okay the big idea here: [RFC3168] already noticed that tunnels and lower-layer protocols would need to support ECN, and that ECN markings have to survive getting wrapped up and unwrapped again 🎀 [RFC9599] gives guidelines for adding ECN to protocols like TRILL, which often wrap IP packets, including how ECN gets carried from IP into the protocol and back out again 💜

Looking at Figure 1 (assuming IP traffic): RB1 is the encapsulator and RB9 is the decapsulator 👀 Traffic from Source to RB1 might or might not get marked as having hit congestion at forwarding elements like X before it gets encapsulated at ingress RB1. Whatever ECN marking it has gets encapsulated along with a TRILL header [RFC6325] 🍓

This document says how the ECN marking on ingress traffic gets copied into the TRILL extension header flags word, and it requires that copying for IP traffic 🔥 It also lets a congested RBridge (like RBn or RB1 up there) mark congestion in the TRILL header extension flags word [RFC7179] 🌈

At RB9, the TRILL egress, things get combined: any ECN markings in the TRILL header flags word and in the encapsulated traffic get merged, so downstream forwarding elements (like Y and the Destination) can tell if congestion happened anywhere earlier on the path from the Source 🧚

Real talk: a big chunk of the guidance for adding ECN to lower-layer protocols [RFC9599] is about safely passing congestion notifications along when some nodes don't support or understand ECN 🫶 That "ECN ignorance" isn't a huge problem with RBridges using this spec, because the method here makes sure that if an egress RBridge is ECN ignorant (so it can't pass ECN along further) and congestion was hit, the egress RBridge will at least drop the packet, and that drop itself tells the end stations about the congestion 💀

1.1. Conventions Used in This Document 📚

The terminology and acronyms defined in [RFC6325] mean the same thing here 💅

In this document, "IP" refers to both IPv4 and IPv6 ✨

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🔑

Abbreviations, bestie 🧠

AQM: Active Queue Management
CCE: Critical Congestion Experienced
CE: Congestion Experienced
CItE: Critical Ingress-to-Egress
ECN: Explicit Congestion Notification
ECT: ECN-Capable Transport
L4S: Low Latency, Low Loss, and Scalable throughput
NCHbH: Non-Critical Hop-by-Hop
NCCE: Non-Critical Congestion Experienced
Not-ECT: Not ECN-Capable Transport
PCN: Pre-Congestion Notification

2. The ECN-Specific Extended Header Flags 🎀

The ECN extension header fields in TRILL are defined as a 2-bit TRILL-ECN field and a 1-bit CCE field, both inside the 32-bit TRILL header extension flags word [RFC7780] 💖

Figure 2 labels these as "ECN" and "CCE". The TRILL-ECN field is bits 12 and 13, which sit in the range reserved for NCHbH bits. The CCE field is bit 26, which sits in the range reserved for CItE bits. The CRItE bit is the critical Ingress-to-Egress summary bit, and it'll be one if, and only if, any bit in the CItE range (21-26) is one, or there's a critical feature invoked in some further extension of the TRILL header after the extension flags word 🔥 Everything else in Figure 2 isn't about ECN, so for what those other bits and fields mean, check [RFC7780], [RFC7179], and [IANAthFlags] 🧚

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Crit.|  CHbH   |   NCHbH   |CRSV | NCRSV |   CItE    |  NCItE  |
   |.....|.........|...........|.....|.......|...........|.........|
   |C|C|C|       |C|N|     |   |     |       |         | |   |     |
   |R|R|R|       |R|C|     |ECN| Ext |       |         |C|Ext|     |
   |H|I|R|       |C|C|     |   | Hop |       |         |C|Clr|     |
   |b|t|s|       |A|A|     |   | Cnt |       |         |E|   |     |
   |H|E|v|       |F|F|     |   |     |       |         | |   |     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 2: The TRILL-ECN and CCE TRILL Header Extension Flags Word
                                   Fields

Table 1 shows what the TRILL-ECN codepoints mean 👑 The first three match the corresponding ECN codepoints in the IP header, as defined in [RFC3168]. The fourth one, 0b11, gets called NCCE so it doesn't get mixed up with CE in IP 💜

        +========+=========+=====================================+
        | Binary | Name    | Meaning                             |
        +========+=========+=====================================+
        |   00   | Not-ECT | Not ECN-Capable Transport           |
        +--------+---------+-------------------------------------+
        |   01   | ECT(1)  | ECN-Capable Transport (1)           |
        +--------+---------+-------------------------------------+
        |   10   | ECT(0)  | ECN-Capable Transport (0)           |
        +--------+---------+-------------------------------------+
        |   11   | NCCE    | Non-Critical Congestion Experienced |
        +--------+---------+-------------------------------------+

                   Table 1: TRILL-ECN Field Codepoints

3. ECN Support 🌸

This section is all about interworking between TRILL and the original standardized form of ECN in IP [RFC3168] 🦋

The subsections below describe the behavior needed to support ECN at TRILL ingress, transit, and egress 💅 Ingress is when a native frame gets wrapped in a TRILL header to become a TRILL Data packet. Transit happens in every RBridge where TRILL Data packets get queued, usually at the output port (including the output port of the TRILL ingress). Egress is when a TRILL Data packet gets unwrapped and sent out as a native frame through an RBridge port ✨

An RBridge that supports ECN MUST behave as described in the relevant subsections below. Those line up with the recommended provisions in Section 3 of this document and Sections 4.2 through 4.4 of [RFC9599] 🔥 Even so, the scheme is built to safely pass along some form of congestion notification even when some RBridges on a TRILL Data packet's path support ECN and others don't 🫶

3.1. Ingress ECN Support ✨

okay bestie, let's start at the ingress RBridge 🎀, the one that wraps the packet up first. Here's what it has to do:

When encapsulating an IP frame, the ingress RBridge MUST:
- set the F flag in the main TRILL header [RFC7780];
- create a flags word as part of the TRILL header;
- copy the two ECN bits from the IP header into the TRILL-ECN field (flags word bits 12 and 13); and
- ensure the CCE flag is set to zero (flags word bit 26).
When encapsulating a frame for a non-IP protocol (where that protocol has a means of indicating that ECN is understood by the ingress RBridge), the ingress RBridge MUST follow the guidelines in Section 4.3 of [RFC9599] to add a flags word to the TRILL header. For a non-IP protocol with an ECN field similar to IP, this would be achieved by copying into the TRILL-ECN field from the encapsulated native frame.

3.2. Transit ECN Support 🚦

next up is the transit behavior 💅. It's required at all RBridges where TRILL Data packets get queued, usually at the output port, so basically everywhere the packets are waiting in line.

An RBridge that supports ECN MUST implement some form of AQM according to the guidelines of [RFC7567]. The RBridge detects congestion either by monitoring its own queue depth or by participating in a link-specific protocol.
If the TRILL header flags word is present, whenever the AQM algorithm decides to indicate critical congestion on a TRILL Data packet, it MUST set the CCE flag (flags word bit 26). Note that Classic ECN marking [RFC3168] only uses critical congestion indications, but the two variants in Section 4.1 use a combination of critical and non-critical congestion indications.
If the TRILL header flags word is not present, the RBridge will either drop the packet or it MAY do all of the following instead to indicate congestion:
- set the F flag in the main TRILL header;
- add a flags word to the TRILL header;
- set the TRILL-ECN field to Not-ECT (00); and
- set the CCE flag and the critical Ingress-to-Egress summary bit (CRItE).

Note that a transit RBridge that supports ECN does not refer to the TRILL-ECN field before signaling CCE in a packet. It signals CCE irrespective of whether the packet indicates that the transport is ECN capable. The egress/decapsulation behavior ensures that a CCE indication is converted to a drop if the transport is not ECN capable. 🙈

3.3. Egress ECN Support 🧚

now we're at the egress end, where the packet gets unwrapped 🎁.

3.3.1. Non-ECN Egress RBridges

if the egress RBridge doesn't support ECN, it just ignores bits 12 and 13 of any flags word that's present, because it has no special ECN logic. Nonetheless, if a transit RBridge has set the CCE flag, the egress will drop the packet. This is because drop is the default behavior for an RBridge decapsulating a CItE flag when it has no specific logic to understand it. Drop is the intended behavior for such a packet, as required by Section 4.4 of [RFC9599]. 💀

3.3.2. ECN Egress RBridges

if an RBridge supports ECN, there are two cases to think about, an IP inner packet and a non-IP inner packet, and the egress behavior is as follows:

Decapsulating an inner IP packet: the RBridge sets the ECN field of the outgoing native IP packet using Table 3. It MUST set the ECN field of the outgoing IP packet to the codepoint at the intersection of the row for the arriving encapsulated IP packet and the column for 3-bit ECN codepoint in the arriving outer TRILL Data packet TRILL header. If no TRILL header extension flags word is present, the 3-bit ECN codepoint is assumed to be all zero bits.

The name of the TRILL 3-bit ECN codepoint used in Table 3 is defined using the combination of the TRILL-ECN and CCE fields in Table 2. Specifically, the TRILL 3-bit ECN codepoint is called CE if either NCCE or CCE is set in the TRILL header extension flags word. Otherwise, it has the same name as the 2-bit TRILL-ECN codepoint.

In the case where the TRILL 3-bit ECN codepoint indicates CE but the encapsulated native IP frame indicates a Not-ECT, it can be seen that the RBridge MUST drop the packet. Such packet dropping is necessary because a transport above the IP layer that is not ECN capable will have no ECN logic, so it will only understand dropped packets as an indication of congestion. 😭

Decapsulating a non-IP protocol frame: if the frame has a means of indicating ECN that is understood by the RBridge, it MUST follow the guidelines in Section 4.4 of [RFC9599] when setting the ECN information in the decapsulated native frame. For a non-IP protocol with an ECN field similar to IP, this would be achieved by combining the information in the TRILL header flags word with the encapsulated non-IP native frame, as specified in Table 3.

+================+=====+=========================================+
| TRILL-ECN      | CCE | Arriving TRILL 3-Bit ECN Codepoint Name |
+=========+======+     |                                         |
| Name    | Bits |     |                                         |
+=========+======+=====+=========================================+
| Not-ECT |  00  |  0  | Not-ECT                                 |
+---------+------+-----+-----------------------------------------+
| ECT(1)  |  01  |  0  | ECT(1)                                  |
+---------+------+-----+-----------------------------------------+
| ECT(0)  |  10  |  0  | ECT(0)                                  |
+---------+------+-----+-----------------------------------------+
| NCCE    |  11  |  0  | CE                                      |
+---------+------+-----+-----------------------------------------+
| Not-ECT |  00  |  1  | CE                                      |
+---------+------+-----+-----------------------------------------+
| ECT(1)  |  01  |  1  | CE                                      |
+---------+------+-----+-----------------------------------------+
| ECT(0)  |  10  |  1  | CE                                      |
+---------+------+-----+-----------------------------------------+
| NCCE    |  11  |  1  | CE                                      |
+---------+------+-----+-----------------------------------------+

    Table 2: Mapping of TRILL-ECN and CCE Fields to the TRILL
                     3-Bit ECN Codepoint Name

+=====================+============================================+
| Inner Native Header |  Arriving TRILL 3-Bit ECN Codepoint Name   |
|                     +=========+============+============+========+
|                     | 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   |
+---------------------+---------+------------+------------+--------+

                   Table 3: Egress ECN Behavior

An asterisk in Table 3 indicates a combination that is currently unused in all variants of ECN marking (see Section 4) and therefore SHOULD be logged. 🌈

With one exception, the mappings in Table 3 are consistent with those for IP-in-IP tunnels [RFC6040], which ensures backward compatibility with all current and past variants of ECN marking (see Section 4). It also ensures forward compatibility with any future form of ECN marking that complies with the guidelines in [RFC9599], including cases where ECT(1) represents a second level of marking severity below CE.

The one exception is that the drop condition in Table 3 need not be logged because, with TRILL, it is the result of a valid combination of events.

4. TRILL Support for ECN Variants ✨

this section is informative, not normative 📚. It discusses interworking between TRILL and variants of the standardized form of ECN in IP [RFC3168]. See also [RFC8311].

The ECN wire protocol for TRILL (Section 2) and the ingress (Section 3.1) and egress (Section 3.3) ECN behaviors have been designed to support the other known variants of ECN as detailed below. New variants of ECN will have to comply with the guidelines for defining alternative ECN semantics [RFC4774]. It is expected that the TRILL ECN wire protocol is generic enough to support such potential future variants. 💜

4.1. Pre-Congestion Notification (PCN)

The PCN wire protocol [RFC6660] is recognized by the use of a PCN-compatible Diffserv codepoint in the IP header and a nonzero IP-ECN field. For TRILL or any lower-layer protocol, equivalent traffic-classification codepoints would have to be defined, but that is outside the scope of this document.

The PCN wire protocol is similar to ECN, except it indicates congestion with two levels of severity. It uses:

11 (CE) as the most severe, termed the Excess-Traffic-Marked (ETM) codepoint
01 ECT(1) as a lesser severity level, termed the Threshold-Marked (ThM) codepoint. This difference between ECT(1) and ECT(0) only applies to PCN, not to the classic ECN support specified for TRILL in this document before Section 4.

To implement PCN on a transit RBridge would require a detailed specification. In brief:

the TRILL CCE flag would be used for the Excess-Traffic-Marked (ETM) codepoint;
ECT(1) in the TRILL-ECN field would be used for the Threshold-Marked codepoint.

Then, the ingress and egress behaviors defined in Section 3 would not need to be altered to ensure support for PCN as well as ECN. 🦋

4.2. Low Latency, Low Loss, and Scalable Throughput (L4S)

L4S is currently on the IETF's experimental track. An outline of how a transit TRILL RBridge would support L4S [RFC9331] is given in Appendix A.

5. IANA Considerations 🍓

IANA has updated the "TRILL Extended Header Flags" registry by replacing the lines for bits 9-13 and 21-26 with the following:

+=======+==============================================+===========+
| Bits  | Purpose                                      | Reference |
+=======+==============================================+===========+
| 9-11  | available non-critical hop-by-hop flags      | [RFC7179] |
+-------+----------------------------------------------+-----------+
| 12-13 | TRILL-ECN (Explicit Congestion Notification) | RFC 9600  |
+-------+----------------------------------------------+-----------+
| 21-25 | available critical ingress-to-egress flags   | [RFC7179] |
+-------+----------------------------------------------+-----------+
| 26    | Critical Congestion Experienced (CCE)        | RFC 9600  |
+-------+----------------------------------------------+-----------+

      Table 4: Updated "TRILL Extended Header Flags" Registry

6. Security Considerations 💀

TRILL support of ECN is a straightforward combination of previously specified ECN and TRILL with no significant new security considerations.

For general security considerations regarding adding ECN to lower layer protocols, see [RFC9599] and [RFC6040].

For general TRILL protocol security considerations, see [RFC6325].

7. References 📖

7.1. Normative References ✨

okay bestie, this is the list of stuff you have to read to get the whole picture 📚 Each entry gives the title, the number, and the DOI so you can find the exact doc 🔍

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.

[RFC4774] Floyd, S., "Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field", BCP 124, RFC 4774, DOI 10.17487/RFC4774, November 2006, <https://www.rfc-editor.org/info/rfc4774>.

[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, <https://www.rfc-editor.org/info/rfc6325>.

[RFC7179] Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and C. Bestler, "Transparent Interconnection of Lots of Links (TRILL): Header Extension", RFC 7179, DOI 10.17487/RFC7179, May 2014, <https://www.rfc-editor.org/info/rfc7179>.

[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF Recommendations Regarding Active Queue Management", BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, <https://www.rfc-editor.org/info/rfc7567>.

[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, <https://www.rfc-editor.org/info/rfc7780>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation", RFC 8311, DOI 10.17487/RFC8311, January 2018, <https://www.rfc-editor.org/info/rfc8311>.

[RFC9599] Briscoe, B. and J. Kaippallimalil, "Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP", RFC 9599, DOI 10.17487/RFC9599, August 2024, <https://www.rfc-editor.org/info/rfc9599>.

7.2. Informative References 🌸

these are the extra-credit reads, the ones that give you context and backstory without being strictly needed to implement 🧚

[IANAthFlags] IANA, "TRILL Extended Header Flags", <http://www.iana.org/assignments/trill-parameters/>.

[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, <https://www.rfc-editor.org/info/rfc6040>.

[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, DOI 10.17487/RFC6660, July 2012, <https://www.rfc-editor.org/info/rfc6660>.

[RFC9331] De Schepper, K. and B. Briscoe, Ed., "The Explicit Congestion Notification (ECN) Protocol for Low Latency, Low Loss, and Scalable Throughput (L4S)", RFC 9331, DOI 10.17487/RFC9331, January 2023, <https://www.rfc-editor.org/info/rfc9331>.

Appendix A. TRILL Transit RBridge Behavior to Support L4S 💜

okay this appendix is the good stuff 🔥 It's about how a TRILL transit RBridge can handle L4S marking. The L4S wire protocol for IP is specified in [RFC9331]. L4S is one example of how TRILL ECN handling might evolve [RFC8311], and it's kinda similar to the original ECN wire protocol for IP [RFC3168], with a few differences:

An AQM that supports L4S classifies packets with ECT(1) or CE in the IP header into an L4S queue and a "Classic" queue otherwise.
The meaning of CE markings applied by an L4S queue is not the same as the meaning of a drop by a "Classic" queue (contrary to the original requirement for ECN [RFC3168]). Instead, the likelihood that the Classic queue drops packets is defined as the square of the likelihood that the L4S queue marks packets. For example, when there is a drop probability of 0.0009 (0.09%), the L4S marking probability will be 0.03 (3%).

ngl this seems like it could be a problem 😭 The way a transit TRILL RBridge defers the choice between marking and dropping to the egress doesn't quite fit with that. BUT the pseudocode below shows how a transit TRILL RBridge can still do L4S marking so that the egress behavior from Section 3.3 (for Classic ECN [RFC3168]) gets the outcome we want 🙌

   /* p is an internal variable calculated by any L4S AQM
    *  dependent on the delay being experienced in the Classic queue.
    * bit13 is the least significant bit of the TRILL-ECN field
    */

   % On TRILL transit
   if (bit13 == 0 ) {
         % Classic Queue
         if (p > max(random(), random()) )
            mark(CCE)                         % likelihood: p^2

   } else {
         % L4S Queue
         if (p > random() ) {
            if (p > random() )
               mark(CCE)                      % likelihood: p^2
            else
               mark(NCCE)                     % likelihood: p - p^2
         }
   }

with that transit behavior, an egress that supports ECN (Section 3.3) will either drop packets or propagate their ECN markings, depending on whether the arriving inner header is from an ECN-capable transport or a not ECN-capable one 💅

Even if an egress has no L4S-specific logic of its own, it still ends up dropping packets with the square of the probability that an ECN-supporting egress would. Here's the breakdown 🧠

Egress with ECN support:
- L4S: Propagates both the Critical and Non-Critical CE marks (CCE and NCCE) as a CE mark.
  - Likelihood: p^2 + p - p^2 = p
- Classic: Propagates CCE marks as CE or drop, depending on the inner header.
  - Likelihood: p^2
Egress without ECN support:
- L4S: Does not propagate NCCE as a CE mark, but drops CCE marks.
  - Likelihood: p^2
- Classic: Drops CCE marks.
  - Likelihood: p^2

Acknowledgements 🫶

huge thanks to Loa Andersson and Adam Roach for their helpful comments 💖

Authors' Addresses 🎀

meet the authors! 🦋

Donald E. Eastlake, 3rd
Independent
2386 Panoramic Circle
Apopka, FL 32703
United States of America
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com

Bob Briscoe
Independent
United Kingdom
Email: ietf@bobbriscoe.net
URI:   http://bobbriscoe.net/

📦 where this page comes from

ietf: rfc9600 2024-08
💖 girlified by claude-haiku-5-5 on 2026-10-19: a language model's rewrite of the original, under its terms