Early-Warning ECN for WAN
draft-hu-rtgwg-pre-ecn-wan-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Jiayuan Hu | ||
| Last updated | 2026-10-25 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-hu-rtgwg-pre-ecn-wan-02
Routing Area Working Group Jiayuan. Hu, Ed.
Internet-Draft China Telecom
Updates: 6040 (if approved) 25 October 2026
Intended status: Informational
Expires: 28 April 2027
Early-Warning ECN for WAN
draft-hu-rtgwg-pre-ecn-wan-02
Abstract
This document defines the precise use of ECN in WAN. With the
growing demand for AI computing power, the computational capacity of
a single Artificial Intelligence Data Center (AIDC) can no longer
meet the requirements of large-scale model training. This has led to
the emergence of cross-AIDC distributed model training, driving the
need for transmitting RoCEv2 packets over WAN networks. AI training
is highly sensitive to network packet loss, where even minimal packet
loss can significantly degrade training efficiency. Additionally,
elephant flows and extreme concurrent traffic impose higher demands
on network performance.
ECN achieves active feedback of network congestion by setting ECN
flag bits in the header of IP packets, which is an effective traffic
control method. RFC 6040 introduces the application of ECN in WAN.
However, due to the much higher end-to-end delay in WAN than in DC,
and the frequent occurrence of instantaneous traffic bursts in WAN,
it is easy to trigger ECN at the wrong time. This document focuses
on the precise use of ECN in WAN, by introducing different reactions
of ECN in different WAN transmission scenarios. It updates RFC 6040
to specify a domain-local early-warning semantics for the ECT(1)
codepoint within managed WAN infrastructure.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Hu Expires 28 April 2027 [Page 1]
Internet-Draft Early-Warning ECN October 2026
This Internet-Draft will expire on 28 April 2027.
Copyright Notice
Copyright (c) 2026 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 (https://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 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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Relationship to Other Work . . . . . . . . . . . . . . . . . 3
3. Conventions Used in This Document . . . . . . . . . . . . . . 4
3.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
3.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
4. ECN for WAN . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. ECN Mechanism for WANs . . . . . . . . . . . . . . . . . 5
4.2. Two-Threshold ECN Mechanism for WAN . . . . . . . . . . . 7
4.2.1. Mechanism Overview . . . . . . . . . . . . . . . . . 7
4.2.2. Congestion Notification Packet (CNP) and Ingress PE
Action . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.3. Deployment and Compatibility Considerations . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6.1. Threats Related to the Two-Threshold Mechanism . . . . . 10
6.2. Covert Channel Considerations . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 11
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
The rapid growth of AI computing power, particularly for large-scale
model training, has necessitated distributed training across multiple
Artificial Intelligence Data Centers (AIDCs). This shift has
increased the demand for reliable and high-performance transmission
of RoCEv2 (RDMA over Converged Ethernet version 2) traffic over the
WAN. However, AI workloads are highly sensitive to network
Hu Expires 28 April 2027 [Page 2]
Internet-Draft Early-Warning ECN October 2026
congestion and packet loss, even minor packet drops can significantly
degrade training efficiency. Due to the long links and significant
end-to-end latency in wide area networks, traditional congestion
control mechanisms may not be effective in a timely manner. They are
insufficient for AI workloads due to their reactive nature and
inability to ensure near-zero packet loss.
To address these challenges, this draft explores the precise
utilization of Explicit Congestion Notification (ECN) in WAN
environments, particularly for RoCEv2 over IP tunnels. ECN enables
proactive congestion signaling by marking packets instead of dropping
them, allowing endpoints to adjust transmission rates before
congestion escalates. However, traditional ECN implementations face
challenges in WAN scenarios, including inconsistent ECN propagation
across tunnel boundaries and inefficient congestion response
mechanisms. This work focuses on optimizing ECN for lossless RoCEv2
transmission in WANs by:
1. Ensuring Accurate ECN Propagation: Defining rules for consistent
ECN field handling across IP-in-IP tunnels to prevent packet loss.
2. Enhancing Congestion Feedback: Adjust the sending rate within a
small range of the wide area network to reduce the impact of latency
on end-to-end communication.
3. Supporting Multi-Level Congestion Signaling: Extending ECN to
differentiate between varying congestion severities, improving
responsiveness for AI traffic.
By refining ECN mechanisms for WAN environments, this approach
enhances network efficiency for distributed AI training while
maintaining backward compatibility with existing protocols. The
proposed framework provides a scalable and reliable solution for
future large-scale distributed computing applications.
2. Relationship to Other Work
This document is scoped to ECN codepoint semantics and their
propagation across IP-in-IP tunnels in a WAN. The early-warning
signal (ECT(1)) defined here is distinct from the Pre-Congestion
Notification (PCN) concept of [RFC5559], which is encoded on Diffserv
codepoints rather than the ECN field; this document therefore does
not use the PCN term. Re-use of ECT(1) within a single managed WAN
domain follows the flexibility permitted by [RFC8311] and the
guidance for specifying alternate ECN semantics in [RFC4774] (BCP
124).
Hu Expires 28 April 2027 [Page 3]
Internet-Draft Early-Warning ECN October 2026
This work complements the "Fast CNP with Proxy" concept of
[I-D.xiao-fann-fast-cnp-with-proxy], which is being progressed in the
FANN working group and addresses how a congested node can notify a
traffic sender when it cannot understand or deliver the notification
directly. This document instead keeps early-warning congestion local
to the ingress domain, and propagates only the severe congestion
codepoint (CE) toward the end host. The two approaches address
different problems and may be combined.
This document is also related to, but independent from, the Fast
Network Notifications (FANN) framework. FANN defines a general
framework for fast, low-latency network notifications (congestion
level, queue length, latency). This document can be regarded as an
ECN-oriented use case that provides fast congestion feedback through
the ECN codepoints and an in-domain CNP.
The Fast CNP without a proxy, defined in [I-D.xiao-fann-fast-cnp], is
sent by a congested node directly to the traffic sender in RoCEv2
networks. This document is complementary to it: the in-domain CNP
described here targets the ingress PE of the WAN domain instead of
the traffic sender, and keeps early-warning handling internal to the
domain.
The ECT(1) codepoint is also used by the Low Latency, Low Loss, and
Scalable Throughput (L4S) service [RFC9330] [RFC9331] [RFC9332] as
the identifier for L4S-capable traffic. The early-warning semantics
defined in this document therefore conflict with L4S when both are
active in the same domain. This mechanism is intended to be deployed
only within a single managed WAN domain in which L4S traffic and L4S
marking are not enabled; at the domain boundary an early-warning mark
MUST NOT be propagated to nodes that do not understand it (see
Section 4.2.3). Operators that enable L4S in a domain MUST NOT
enable this mechanism on the same path.
The tunnel behavior defined here is consistent with the guidelines
for adding congestion notification to protocols that encapsulate IP
in [RFC9599]: the outer IP header carries the ECN codepoints used for
congestion signaling, while the inner RoCEv2 payload is left
unmodified.
More accurate ECN feedback for TCP, e.g., AccECN [RFC9768], improves
the granularity of end-to-end ECN feedback at the transport layer.
The mechanism in this document is orthogonal to it: it operates at
the network layer within a managed WAN domain and does not change the
transport-layer ECN feedback loop.
3. Conventions Used in This Document
Hu Expires 28 April 2027 [Page 4]
Internet-Draft Early-Warning ECN October 2026
3.1. Requirements Language
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. This document is an Informational
contribution; the keywords precisely describe the behaviour of the
mechanism and do not impose normative requirements beyond the scope
of this document.
3.2. Abbreviations
AIDC: Artificial Intelligence Data Center
RoCEv2: RDMA over Converged Ethernet version 2
ECN: Explicit Congestion Notification
CNP: Congestion Notification Packet
4. ECN for WAN
4.1. ECN Mechanism for WANs
In WANs, tunneling is a fundamental technique used to encapsulate and
transport data packets across different network domains while
maintaining security, performance, and compatibility. Tunneling
works by embedding an original packet (the inner payload) within a
new packet (the outer header), allowing it to traverse intermediate
networks that may not natively support the original protocol.
ECN, as a traditional congestion notification mechanism, has also
been extended from DC to WAN. [RFC6040] introduces how to label and
use ECN mechanisms in tunnels, which are divided into tunnel ingress
behavior and tunnel egress behavior. Each behavior contains two
encapsulation modes: a "compatibility mode," which is for backward
compatibility with tunnel decapsulators that do not comprehend ECN,
and a REQUIRED "normal mode." The detail of ingress behavior is
shown below:
Hu Expires 28 April 2027 [Page 5]
Internet-Draft Early-Warning ECN October 2026
+-----------------+------------------------------+
| Incoming Header | Departing Outer Header |
| (also equal to +---------------+--------------+
| departing Inner | Compatibility | Normal |
| Header) | Mode | Mode |
+-----------------+---------------+--------------+
| Not-ECT | Not-ECT | Not-ECT |
| ECT(0) | Not-ECT | ECT(0) |
| ECT(1) | Not-ECT | ECT(1) |
| CE | Not-ECT | CE |
+-----------------+---------------+--------------+
Figure 1: Early-Warning ECN: Encapsulation Behaviours
For the decapsulation behavior, detail is shown below:
+---------+------------------------------------------------+
|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) | light CE* | CE |
| ECT(1) | ECT(1) | ECT(1) (!) | light CE* | CE |
| CE | CE | CE | CE(!!!)| CE |
+---------+---------+------------+------------+------------+
* "light CE" denotes the early-warning congestion state defined
in this document within a managed WAN domain. It is a local
state at the decapsulating PE: the outer ECT(1) mark is consumed
to trigger in-domain CNP handling, and the inner ECN field is
left unchanged, so the local semantics are not exposed to
nodes outside the domain.
Figure 2: Early-Warning ECN: Decapsulation Behaviours
In the decapsulation table above, '(!)' and '(!!!)' follow the
notation of [RFC6040] for combinations of inner and outer ECN fields
that were currently unused (CU) when it was specified, for which it
also specifies that a decapsulator SHOULD log the event. The 'light
CE' entries deviate from [RFC6040] only in the column for an arriving
outer ECT(1) header: within a managed WAN domain, an arriving outer
ECT(1) mark denotes the early-warning state defined in this document.
The decapsulating PE consumes this mark to trigger in-domain CNP
handling and leaves the inner ECN field unchanged, so that the
domain-local ECT(1) semantics are not propagated beyond the domain
boundary.
Hu Expires 28 April 2027 [Page 6]
Internet-Draft Early-Warning ECN October 2026
ECT(0) and ECT(1) can both indicate the same degree of congestion
marking (such as "not congestion marked") according to the reasoning
above. However, it also makes it possible to construct future
schemes in which ECT(1) can represent other situations in WAN
scenarios.
4.2. Two-Threshold ECN Mechanism for WAN
The high latency and bursty nature of WAN links introduce significant
challenges for timely and accurate congestion management.
Traditional single-threshold ECN or packet-drop mechanisms often
result in delayed feedback, causing over-correction (global
synchronization) or under-correction (persistent congestion). To
address this, this draft proposes a Two-Threshold ECN Mechanism
specifically designed for WAN environments carrying latency-
sensitive, loss-averse traffic like RoCEv2 for AI training.
4.2.1. Mechanism Overview
This mechanism redefines the use of the ECT(1) codepoint within a
controlled domain (e.g., a provider's WAN core), leveraging the
flexibility permitted by [RFC8311]. Network devices (e.g., routers,
switches) supporting this mechanism are configured with two queue
occupancy thresholds: a Lower Threshold (T1) and a Higher Threshold
(T2).
ECT(1) as "Pre-Congestion" or "Early Warning" Signal: When the
average queue length exceeds T1, the device interprets this as
incipient or light congestion. Packets with an outer IP header ECN
field of ECT(0) or ECT(1) are remarked to ECT(1) with a probability
that increases linearly with the queue length. This ECT(1) marking
is defined within this WAN domain as an early-warning congestion
signal (referred to below simply as the "early-warning signal"). Its
purpose is to signal an impending congestion condition before queues
build to a level that would impact latency or cause loss.
CE as "Severe Congestion" Signal: When the average queue length
exceeds T2, the device interprets this as severe congestion requiring
immediate action. Packets are marked with the CE codepoint following
a standard RED-like algorithm. This signal mandates a direct and
measurable reduction in the data sender's transmission rate.
Hu Expires 28 April 2027 [Page 7]
Internet-Draft Early-Warning ECN October 2026
4.2.2. Congestion Notification Packet (CNP) and Ingress PE Action
A critical component of this mechanism is the generation and
processing of a Congestion Notification Packet (CNP). This is a
control packet generated by the congested device (or a network
controller monitoring it) and sent to the tunnel ingress Provider
Edge (PE) device -- the point where the traffic entered the WAN
domain.
CNP Format: this specification does not mandate a new CNP wire
format; the CNP is carried as a control message between the congested
device and the ingress PE over an existing channel (for example, a
UDP-based or in-band control channel). At minimum, the CNP MUST
identify the affected flow (e.g., a 5-tuple or a flow identifier),
the congestion level (early or severe), and include a value or
timestamp sufficient for rate limiting. The ingress PE MUST rate-
limit CNP handling to avoid reacting to transient micro-bursts, and
SHOULD discard CNPs inconsistent with the locally observed queue
state.
4.2.2.1. Upon reaching T1 (ECT(1) marking):
The congested device generates and sends a CNP to the ingress PE.
This CNP identifies the affected flow (e.g., via 5-tuple) and
indicates a light congestion event.
Ingress PE Action: Upon receiving this CNP, the ingress PE MAY take
proactive measures to alleviate the impending congestion without
involving the end host. This can include:
Local Rate Adjustment: Slightly reducing the transmission rate for
the identified flow into the tunnel.
Traffic Rerouting: Dynamically steering the flow to an alternative,
less congested path within the WAN if available (e.g., using SRv6
policy).
ECN Propagation at the Egress: independently of the CNP, when a
packet carrying the outer ECT(1) early-warning mark reaches the
decapsulating (egress) PE, that PE does NOT copy the mark to the
inner IP header (following a modified "pipe model" logic for this
codepoint). The end host remains unaware of this early warning,
preventing an over-reaction from a distant sender whose feedback loop
is delayed by the WAN RTT.
Hu Expires 28 April 2027 [Page 8]
Internet-Draft Early-Warning ECN October 2026
4.2.2.2. Upon reaching T2 (CE marking):
The congested device generates and sends a CNP to the ingress PE, now
indicating a severe congestion event.
Ingress PE Action: Upon receiving this CNP, the ingress PE MUST
intensify its local congestion control for the affected flow, for
example by applying stronger versions of the Local Rate Adjustment
and Traffic Rerouting actions described for the T1 case.
Independently of this, the decapsulating (egress) PE performs
standard RFC 6040 "normal mode" decapsulation: the CE codepoint from
the outer header is copied to the inner IP header, so that the end-
to-end transport's congestion control is engaged.
The packet, now with CE set in the inner header, is forwarded to the
receiver. The receiver's transport (e.g., RoCEv2) then feeds this
congestion signal back to the original sender, which MUST reduce its
transmission rate according to its congestion control algorithm.
4.2.3. Deployment and Compatibility Considerations
Backward Compatibility: Devices not implementing this two-threshold
mechanism will treat ECT(1) as equivalent to ECT(0) per [RFC3168],
and will process CE normally. This ensures safe co-existence and
incremental deployment.
Domain of Application: This mechanism is intended for use within a
managed WAN domain (e.g., a single provider's core). The re-
definition of the ECT(1) semantics is a local policy, confined to the
outer tunnel header inside the domain. At the egress PE leaving this
domain, standard RFC 6040 rules apply for forwarding packets into
external networks.
Egress Behavior at the Domain Boundary: when a packet traverses the
egress PE that leaves the managed WAN domain, the outer header is
stripped and the inner ECN field is preserved, following the standard
RFC 6040 normal-mode decapsulation rules (see the decapsulation table
above). In particular, an early-warning (ECT(1)) mark applied to the
outer header inside the domain MUST NOT be propagated to an inner
endpoint that does not understand it: the egress PE consumes that
mark for in-domain CNP handling and leaves the inner ECN field
unchanged, so that the local ECT(1) semantics are not leaked to nodes
outside the domain. CE is asserted only when severe congestion
applies.
Threshold Tuning: The values of T1 and T2 are critical and should be
set based on link capacity, typical traffic profiles, and the desired
latency-loss trade-off for the target applications (e.g., AI
Hu Expires 28 April 2027 [Page 9]
Internet-Draft Early-Warning ECN October 2026
training). T1 should be set low enough to provide meaningful early
warning but high enough to avoid triggering on transient micro-
bursts. T2 MUST be set strictly greater than T1, so that the early-
warning and severe congestion regions are clearly separated.
5. IANA Considerations
No IANA actions are required by this specification; it does not
define new protocol elements, codepoints, or registries.
6. Security Considerations
The proposed enhancements introduce new mechanisms that must be
evaluated for potential security vulnerabilities. This section
expands upon the security considerations of [RFC3168] and [RFC6040]
within the context of this draft.
6.1. Threats Related to the Two-Threshold Mechanism
CNP Spoofing and Forgery: An attacker could generate malicious CNPs
and send them to an ingress PE, falsely indicating congestion. This
could trigger unnecessary rate reduction or rerouting, leading to
denial-of-service (performance degradation) for legitimate flows or
manipulation of traffic paths for interception.
Threshold Manipulation: An on-path attacker with access to network
device configuration could alter the T1 or T2 thresholds. Lowering
T1 excessively would cause frequent ECT(1) marking and CNP
generation, leading to under-utilization of the link. Raising T2
excessively could suppress legitimate CE signals, leading to
bufferbloat and packet loss.
ECN Field Tampering within the Tunnel: As noted in [RFC3168] and
[RFC6040], the outer ECN field is mutable. An attacker within the
WAN could erase CE marks to hide congestion from the sender, or could
set false CE/ECT(1) marks to artificially throttle flows. The two-
threshold mechanism's use of ECT(1) as a significant signal creates a
new vector for manipulation.
6.2. Covert Channel Considerations
[RFC6040] explicitly relaxed earlier restrictions on the covert
channel bandwidth across tunnels, deeming a 2-bit per packet channel
manageable. This mechanism does not alter that fundamental
assessment. However, the specific semantics where the ingress PE
does not propagate ECT(1) outwards but does act on a CNP could
theoretically be exploited by a colluding ingress and egress point to
encode information. This is considered a manageable risk within a
Hu Expires 28 April 2027 [Page 10]
Internet-Draft Early-Warning ECN October 2026
single administrative domain.
7. References
7.1. Normative References
[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>.
[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>.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, DOI 10.17487/RFC6040, November
2010, <https://www.rfc-editor.org/info/rfc6040>.
[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>.
[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>.
[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>.
7.2. Informative References
[RFC5559] Eardley, P., Ed., "Pre-Congestion Notification (PCN)
Architecture", RFC 5559, DOI 10.17487/RFC5559, June 2009,
<https://www.rfc-editor.org/info/rfc5559>.
[RFC9330] Briscoe, B., Ed., De Schepper, K., Bagnulo, M., and G.
White, "Low Latency, Low Loss, and Scalable Throughput
(L4S) Internet Service: Architecture", RFC 9330,
DOI 10.17487/RFC9330, January 2023,
<https://www.rfc-editor.org/info/rfc9330>.
Hu Expires 28 April 2027 [Page 11]
Internet-Draft Early-Warning ECN October 2026
[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>.
[RFC9332] De Schepper, K., Briscoe, B., Ed., and G. White, "Dual-
Queue Coupled Active Queue Management (AQM) for Low
Latency, Low Loss, and Scalable Throughput (L4S)",
RFC 9332, DOI 10.17487/RFC9332, January 2023,
<https://www.rfc-editor.org/info/rfc9332>.
[RFC9599] Briscoe, B. and J. Kaippallimalil, "Guidelines for Adding
Congestion Notification to Protocols that Encapsulate IP",
BCP 89, RFC 9599, DOI 10.17487/RFC9599, August 2024,
<https://www.rfc-editor.org/info/rfc9599>.
[RFC9768] Briscoe, B., Kühlewind, M., and R. Scheffenegger, "More
Accurate Explicit Congestion Notification (AccECN)
Feedback in TCP", RFC 9768, DOI 10.17487/RFC9768, April
2026, <https://www.rfc-editor.org/info/rfc9768>.
[I-D.xiao-fann-fast-cnp-with-proxy]
Min, X., Han, T., and Z. Hu, "Fast Congestion Notification
Packet (CNP) with Proxy", Work in Progress, Internet-
Draft, draft-xiao-fann-fast-cnp-with-proxy-05, September
2026, <https://datatracker.ietf.org/doc/draft-xiao-fann-
fast-cnp-with-proxy/>.
[I-D.xiao-fann-fast-cnp]
Min, X., Li, H., Han, T., Cheng, W., Yang, J., and X. He,
"Fast Congestion Notification Packet (CNP) in RoCEv2
Networks", Work in Progress, Internet-Draft, draft-xiao-
fann-fast-cnp-01, September 2026,
<https://datatracker.ietf.org/doc/draft-xiao-fann-fast-
cnp/>.
Contributors
Thanks to all the contributors.
Author's Address
Hu Expires 28 April 2027 [Page 12]
Internet-Draft Early-Warning ECN October 2026
Jiayuan Hu (editor)
China Telecom
109, West Zhongshan Road, Tianhe District
Guangzhou
Guangzhou, 510000
China
Email: hujy5@chinatelecom.cn
Hu Expires 28 April 2027 [Page 13]