Independent

2386 Panoramic Circle Apopka FL 32703 United States of America +1-508-333-2270 d3e3e3@gmail.com

Independent

United Kingdom ietf@bobbriscoe.net http://bobbriscoe.net/

RTG TRILL example Explicit Congestion Notification (ECN) allows a forwarding element to notify downstream devices, including the destination, of the onset of congestion without having to drop packets. This can improve network efficiency through better congestion control without packet drops. This document extends ECN to TRansparent Interconnection of Lots of Links (TRILL) switches, including integration with IP ECN, and provides for ECN marking in the TRILL header extension flags word (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. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2024 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 () 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

• .  Introduction
  • .  Conventions Used in This Document
• .  The ECN-Specific Extended Header Flags
• .  ECN Support
  • .  Ingress ECN Support
  • .  Transit ECN Support
  • .  Egress ECN Support
    • .  Non-ECN Egress RBridges
    • .  ECN Egress RBridges
• .  TRILL Support for ECN Variants
  • .  Pre-Congestion Notification (PCN)
  • .  Low Latency, Low Loss, and Scalable Throughput (L4S)
• .  IANA Considerations
• .  Security Considerations
• .  References
  • .  Normative References
  • .  Informative References
• .  TRILL Transit RBridge Behavior to Support L4S
• Acknowledgements
• Authors' Addresses

Introduction Explicit Congestion Notification (ECN) allows a forwarding element (such as a router) to notify downstream devices, including the destination, of the onset of congestion without having to drop packets. This can improve network efficiency through better congestion control without packet drops. The forwarding element can explicitly mark a proportion of packets in an ECN field instead of dropping packets. For example, a 2-bit field is available for ECN marking in IP headers.

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

In , it was recognized that tunnels and lower-layer protocols would need to support ECN, and ECN markings would need to be propagated, as headers were encapsulated and decapsulated. gives guidelines on the addition of ECN to protocols like TRILL that often encapsulate IP packets, including propagation of ECN from and to IP. In , assuming IP traffic, RB1 is an encapsulator and RB9 is a decapsulator. Traffic from Source to RB1 might or might not get marked as having experienced congestion in forwarding elements, such as X, before being encapsulated at ingress RB1. Any such ECN marking is encapsulated with a TRILL header . This document specifies how ECN marking in traffic at the ingress is copied into the TRILL extension header flags word and requires such copying for IP traffic. It also enables congestion marking by a congested RBridge (such as RBn or RB1 above) in the TRILL header extension flags word . At RB9, the TRILL egress, it specifies how any ECN markings in the TRILL header flags word and in the encapsulated traffic are combined so that subsequent forwarding elements, such as Y and the Destination, can see if congestion was experienced at any previous point in the path from the Source. A large part of the guidelines for adding ECN to lower-layer protocols concerns safe propagation of congestion notifications in scenarios where some of the nodes do not support or understand ECN. Such ECN ignorance is not a major problem with RBridges using this specification, because the method specified assures that, if an egress RBridge is ECN ignorant (so it cannot further propagate ECN) and congestion has been encountered, the egress RBridge will at least drop the packet, and this drop will itself indicate congestion to end stations.

Conventions Used in This Document The terminology and acronyms defined in are used herein with the same meaning. In this documents, "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 when, and only when, they appear in all capitals, as shown here. Abbreviations:

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

The ECN-Specific Extended Header Flags The extension header fields for ECN in TRILL are defined as a 2-bit TRILL-ECN field and a one-bit CCE field in the 32-bit TRILL header extension flags word . These fields are shown in as "ECN" and "CCE". The TRILL-ECN field consists of bits 12 and 13, which are in the range reserved for NCHbH bits. The CCE field consists of bit 26, which is in the range reserved for CItE bits. The CRItE bit is the critical Ingress-to-Egress summary bit and will be one if, and only if, any of the bits in the CItE range (21-26) are one or there is a critical feature invoked in some further extension of the TRILL header after the extension flags word. The other bits and fields shown in are not relevant to ECN. See , , and for the meaning of these other bits and fields.

The TRILL-ECN and CCE TRILL Header Extension Flags Word Fields 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| | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

shows the meaning of the codepoints in the TRILL-ECN field. The first three have the same meaning as the corresponding ECN field codepoints in the IP header, as defined in . However, codepoint 0b11 is called NCEE to distinguish it from CE in IP. TRILL-ECN Field Codepoints

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

ECN Support This section specifies interworking between TRILL and the original standardized form of ECN in IP . The subsections below describe the required behavior to support ECN at TRILL ingress, transit, and egress. The ingress behavior occurs as a native frame is encapsulated with a TRILL header to produce a TRILL Data packet. The transit behavior occurs in all RBridges where TRILL Data packets are queued, usually at the output port (including the output port of the TRILL ingress). The egress behavior occurs where a TRILL Data packet is decapsulated and output as a native frame through an RBridge port. An RBridge that supports ECN MUST behave as described in the relevant subsections below, which correspond to the recommended provisions in of this document and Sections through of . Nonetheless, the scheme is designed to safely propagate some form of congestion notification even if some RBridges in the path followed by a TRILL Data packet support ECN and others do not.

Ingress ECN Support The behavior at an ingress RBridge is as follows:

• When encapsulating an IP frame, the ingress RBridge MUST:
  • set the F flag in the main TRILL header ;
  • 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 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.

Transit ECN Support The transit behavior, shown below, is required at all RBridges where TRILL Data packets are queued, usually at the output port.

• An RBridge that supports ECN MUST implement some form of AQM according to the guidelines of . 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 only uses critical congestion indications, but the two variants in 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.

Egress ECN Support

Non-ECN Egress RBridges If the egress RBridge does not support ECN, that RBridge will ignore bits 12 and 13 of any flags word that is present because it does not contain any 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 .

ECN Egress RBridges If an RBridge supports ECN, for the two cases of an IP and a non-IP inner packet, the egress behavior is as follows:

Decapsulating an inner IP packet:

The RBridge sets the ECN field of the outgoing native IP packet using . 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 is defined using the combination of the TRILL-ECN and CCE fields in . 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 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 .

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

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

Egress ECN Behavior

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

An asterisk in indicates a combination that is currently unused in all variants of ECN marking (see ) and therefore SHOULD be logged. With one exception, the mappings in are consistent with those for IP-in-IP tunnels , which ensures backward compatibility with all current and past variants of ECN marking (see ). It also ensures forward compatibility with any future form of ECN marking that complies with the guidelines in , including cases where ECT(1) represents a second level of marking severity below CE. The one exception is that the drop condition in need not be logged because, with TRILL, it is the result of a valid combination of events.

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 . See also . The ECN wire protocol for TRILL () and the ingress () and egress () 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 . It is expected that the TRILL ECN wire protocol is generic enough to support such potential future variants.

Pre-Congestion Notification (PCN) The PCN wire protocol 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 .

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 would not need to be altered to ensure support for PCN as well as ECN.

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 is given in .

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: Updated "TRILL Extended Header Flags" Registry

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

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 and . For general TRILL protocol security considerations, see .

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK] There have been a number of proposals for alternate semantics for the Explicit Congestion Notification (ECN) field in the IP header RFC 3168. This document discusses some of the issues in defining alternate semantics for the ECN field, and specifies requirements for a safe coexistence in an Internet that could include routers that do not understand the defined alternate semantics. This document evolved as a result of discussions with the authors of one recent proposal for such alternate semantics. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Routing Bridges (RBridges) provide optimal pair-wise forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. They achieve these goals using IS-IS routing and encapsulation of traffic with a header that includes a hop count. RBridges are compatible with previous IEEE 802.1 customer bridges as well as IPv4 and IPv6 routers and end nodes. They are as invisible to current IP routers as bridges are and, like routers, they terminate the bridge spanning tree protocol. The design supports VLANs and the optimization of the distribution of multi-destination frames based on VLAN ID and based on IP-derived multicast groups. It also allows unicast forwarding tables at transit RBridges to be sized according to the number of RBridges (rather than the number of end nodes), which allows their forwarding tables to be substantially smaller than in conventional customer bridges. [STANDARDS-TRACK] The IETF Transparent Interconnection of Lots of Links (TRILL) base protocol (RFC 6325) specifies minimal hooks to safely support TRILL Header extensions. This document specifies an initial extension providing additional flag bits and specifies some of those bits. It updates RFC 6325. This memo presents recommendations to the Internet community concerning measures to improve and preserve Internet performance. It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management (AQM) in network devices to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of AQM mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification. Based on 15 years of experience and new research, this document replaces the recommendations of RFC 2309. Since the publication of the TRILL (Transparent Interconnection of Lots of Links) base protocol in 2011, active development and deployment of TRILL have revealed errata in RFC 6325 and areas that could use clarifications or updates. RFC 7177, RFC 7357, and an intended replacement of RFC 6439 provide clarifications and updates with respect to adjacency, the TRILL ESADI (End Station Address Distribution Information) protocol, and Appointed Forwarders, respectively. This document provides other known clarifications, corrections, and updates. It obsoletes RFC 7180 (the previous "TRILL clarifications, corrections, and updates" RFC), and it updates RFCs 6325, 7177, and 7179. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This memo updates RFC 3168, which specifies Explicit Congestion Notification (ECN) as an alternative to packet drops for indicating network congestion to endpoints. It relaxes restrictions in RFC 3168 that hinder experimentation towards benefits beyond just removal of loss. This memo summarizes the anticipated areas of experimentation and updates RFC 3168 to enable experimentation in these areas. An Experimental RFC in the IETF document stream is required to take advantage of any of these enabling updates. In addition, this memo makes related updates to the ECN specifications for RTP in RFC 6679 and for the Datagram Congestion Control Protocol (DCCP) in RFCs 4341, 4342, and 5622. This memo also records the conclusion of the ECN nonce experiment in RFC 3540 and provides the rationale for reclassification of RFC 3540 from Experimental to Historic; this reclassification enables new experimental use of the ECT(1) codepoint. Independent Futurewei Informative References IANA This document redefines how the explicit congestion notification (ECN) field of the IP header should be constructed on entry to and exit from any IP-in-IP tunnel. On encapsulation, it updates RFC 3168 to bring all IP-in-IP tunnels (v4 or v6) into line with RFC 4301 IPsec ECN processing. On decapsulation, it updates both RFC 3168 and RFC 4301 to add new behaviours for previously unused combinations of inner and outer headers. The new rules ensure the ECN field is correctly propagated across a tunnel whether it is used to signal one or two severity levels of congestion; whereas before, only one severity level was supported. Tunnel endpoints can be updated in any order without affecting pre-existing uses of the ECN field, thus ensuring backward compatibility. Nonetheless, operators wanting to support two severity levels (e.g., for pre-congestion notification -- PCN) can require compliance with this new specification. A thorough analysis of the reasoning for these changes and the implications is included. In the unlikely event that the new rules do not meet a specific need, RFC 4774 gives guidance on designing alternate ECN semantics, and this document extends that to include tunnelling issues. [STANDARDS-TRACK] The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. The overall rate of PCN-traffic is metered on every link in the PCN- domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes pass information about these PCN-marks to Decision Points that then decide whether to admit or block new flow requests or to terminate some already admitted flows during serious pre-congestion. This document specifies how PCN-marks are to be encoded into the IP header by reusing the Explicit Congestion Notification (ECN) codepoints within a PCN-domain. The PCN wire protocol for non-IP protocol headers will need to be defined elsewhere. Nonetheless, this document clarifies the PCN encoding for MPLS in an informational appendix. The encoding for IP provides for up to three different PCN marking states using a single Diffserv codepoint (DSCP): not-marked (NM), threshold-marked (ThM), and excess-traffic-marked (ETM). Hence, it is called the 3-in-1 PCN encoding. This document obsoletes RFC 5696. [STANDARDS-TRACK] This specification defines the protocol to be used for a new network service called Low Latency, Low Loss, and Scalable throughput (L4S). L4S uses an Explicit Congestion Notification (ECN) scheme at the IP layer that is similar to the original (or 'Classic') ECN approach, except as specified within. L4S uses 'Scalable' congestion control, which induces much more frequent control signals from the network, and it responds to them with much more fine-grained adjustments so that very low (typically sub-millisecond on average) and consistently low queuing delay becomes possible for L4S traffic without compromising link utilization. Thus, even capacity-seeking (TCP-like) traffic can have high bandwidth and very low delay at the same time, even during periods of high traffic load. The L4S identifier defined in this document distinguishes L4S from 'Classic' (e.g., TCP-Reno-friendly) traffic. Then, network bottlenecks can be incrementally modified to distinguish and isolate existing traffic that still follows the Classic behaviour, to prevent it from degrading the low queuing delay and low loss of L4S traffic. This Experimental specification defines the rules that L4S transports and network elements need to follow, with the intention that L4S flows neither harm each other's performance nor that of Classic traffic. It also suggests open questions to be investigated during experimentation. Examples of new Active Queue Management (AQM) marking algorithms and new transports (whether TCP-like or real time) are specified separately.

TRILL Transit RBridge Behavior to Support L4S The specification of the Low Latency, Low Loss, and Scalable throughput (L4S) wire protocol for IP is given in . L4S is one example of the ways TRILL ECN handling may evolve . It is similar to the original ECN wire protocol for IP , except:

• 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 ). Instead, the likelihood that the Classic queue drops packets is defined as the square of the likelihood that the L4S queue marks packets -- e.g., when there is a drop probability of 0.0009 (0.09%), the L4S marking probability will be 0.03 (3%).

This seems to present a problem for the way that a transit TRILL RBridge defers the choice between marking and dropping to the egress. Nonetheless, the following pseudocode outlines how a transit TRILL RBridge can implement L4S marking in such a way that the egress behavior already described in for Classic ECN will produce the desired outcome. /* 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 the above transit behavior, an egress that supports ECN () will drop packets or propagate their ECN markings depending on whether the arriving inner header is from an ECN-capable or not ECN-capable transport. Even if an egress has no L4S-specific logic of its own, it will drop packets with the square of the probability that an egress would if it did support ECN, for the following reasons:

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

Acknowledgements The helpful comments of and are hereby acknowledged.

Authors' Addresses Independent

2386 Panoramic Circle Apopka FL 32703 United States of America +1-508-333-2270 d3e3e3@gmail.com

Independent

United Kingdom ietf@bobbriscoe.net http://bobbriscoe.net/