Hubbry Logo
Explicit Congestion NotificationExplicit Congestion NotificationMain
Open search
Explicit Congestion Notification
Community hub
Explicit Congestion Notification
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Explicit Congestion Notification
Explicit Congestion Notification
Explicit Congestion Notification
View on Wikipedia
from Wikipedia
Internet protocol suite
Application layer
Transport layer
Internet layer
Link layer

Explicit Congestion Notification (ECN) is an extension to the Internet Protocol and to the Transmission Control Protocol and is defined in RFC 3168 (2001). ECN allows end-to-end notification of network congestion without dropping packets. ECN is an optional feature that may be used between two ECN-enabled endpoints when the underlying network infrastructure also supports it.

Conventionally, TCP/IP networks signal congestion by dropping packets. When ECN is successfully negotiated, an ECN-aware router may set a mark in the IP header instead of dropping a packet in order to signal impending congestion. The receiver of the packet echoes the congestion indication to the sender, which reduces its transmission rate as if it detected a dropped packet.

Rather than responding properly or ignoring the bits, some outdated or faulty network equipment has historically dropped or mangled packets that have ECN bits set.[1][2][3] As of 2015, measurements suggested that the fraction of web servers on the public Internet for which setting ECN prevents network connections had been reduced to less than 1%.[4]

Passive support has existed in Ubuntu Linux since 12.04 and in Windows Server since 2012.[5] Passive support in the most popular websites has increased from 8.5% in 2012 to over 70% in May 2017.[5] Adoption across the Internet now requires clients to actively request ECN. In June 2015, Apple announced that ECN will be enabled by default on its supported and future products, to help drive the adoption of ECN signaling industry-wide.[6]

Operation

[edit]

ECN requires specific support at both the Internet layer and the transport layer for the following reasons:

  • In TCP/IP, routers operate within the Internet layer, while the transmission rate is handled by the endpoints at the transport layer.
  • Congestion may be handled only by the transmitter, but since it is known to have happened only after a packet was sent, there must be an echo of the congestion indication by the receiver to the transmitter.

Without ECN, congestion indication echo is achieved indirectly by the detection of lost packets. With ECN, the congestion is indicated by setting the ECN field within an IP packet to CE (Congestion Experienced) and is echoed back by the receiver to the transmitter by setting proper bits in the header of the transport protocol. For example, when using TCP, the congestion indication is echoed back by setting the ECE bit.

Operation of ECN with IP

[edit]

ECN uses the two least significant (right-most) bits of the Traffic Class field in the IPv4 or IPv6 header to encode four different code points:

  • 00 – Not ECN-Capable Transport, Not-ECT
  • 01 – ECN Capable Transport(1), ECT(1)
  • 10 – ECN Capable Transport(0), ECT(0)
  • 11 – Congestion Experienced, CE.

When both endpoints support ECN they mark their packets with ECT(0) or ECT(1). Routers treat the ECT(0) and ECT(1) codepoints as equivalent. If the packet traverses an active queue management (AQM) queue (e.g., a queue that uses random early detection (RED)) that is experiencing congestion and the corresponding router supports ECN, it may change the code point to CE instead of dropping the packet. This act is referred to as "marking" and its purpose is to inform the receiving endpoint of impending congestion. At the receiving endpoint, this congestion indication is handled by the upper layer protocol (transport layer protocol) and needs to be echoed back to the transmitting node in order to signal it to reduce its transmission rate.

Because the CE indication can only be handled effectively by an upper layer protocol that supports it, ECN is only used in conjunction with upper layer protocols, such as TCP, that support congestion control and have a method for echoing the CE indication to the transmitting endpoint.

Operation of ECN with TCP

[edit]

TCP supports ECN using two flags in the TCP header. The first, ECN-Echo (ECE) is used to echo back the congestion indication (i.e., signal the sender to reduce the transmission rate). The second, Congestion Window Reduced (CWR), to acknowledge that the congestion-indication echoing was received. Use of ECN on a TCP connection is optional; for ECN to be used, it must be negotiated at connection establishment by including suitable options in the SYN and SYN-ACK segments.

When ECN has been negotiated on a TCP connection, the sender indicates that IP packets that carry TCP segments of that connection are carrying traffic from an ECN Capable Transport by marking them with an ECT code point. This allows intermediate routers that support ECN to mark those IP packets with the CE code point instead of dropping them in order to signal impending congestion.

Upon receiving an IP packet with the Congestion Experienced code point, the TCP receiver echoes back this congestion indication using the ECE flag in the TCP header. When an endpoint receives a TCP segment with the ECE bit it reduces its congestion window as for a packet drop. It then acknowledges the congestion indication by sending a segment with the CWR bit set.

A node keeps transmitting TCP segments with the ECE bit set until it receives a segment with the CWR bit set.

To see affected packets with tcpdump, use the filter predicate (tcp[13] & 0xc0 != 0).

ECN and TCP control packets

[edit]

Since the Transmission Control Protocol (TCP) does not perform congestion control on control packets (pure ACKs, SYN, FIN segments), control packets are usually not marked as ECN-capable.

A 2009 proposal[7] suggests marking SYN-ACK packets as ECN-capable. This improvement, known as ECN+, has been shown to provide dramatic improvements to performance of short-lived TCP connections.[8]

Operation of ECN with other transport protocols

[edit]

ECN is also defined for other transport layer protocols that perform congestion control, notably DCCP and Stream Control Transmission Protocol (SCTP). The general principle is similar to TCP, although the details of the on-the-wire encoding differ.

It is possible to use ECN with protocols layered above UDP. However, UDP requires that congestion control be performed by the application, and early UDP based protocols such as DNS did not use ECN. More recent UDP based protocols such as QUIC are using ECN for congestion control.

Effects on performance

[edit]

Since ECN is only effective in combination with an active queue management (AQM) policy, the benefits of ECN depend on the precise AQM being used. A few observations, however, appear to hold across different AQMs.

As expected, ECN reduces the number of packets dropped by a TCP connection, which, by avoiding a retransmission, reduces latency and especially jitter. This effect is most drastic when the TCP connection has a single outstanding segment,[9] when it is able to avoid an RTO timeout; this is often the case for interactive connections, such as remote logins, and transactional protocols, such as HTTP requests, the conversational phase of SMTP, or SQL requests.

Effects of ECN on bulk throughput are less clear[10] because modern TCP implementations are fairly good at resending dropped segments in a timely manner when the sender's window is large.

Use of ECN has been found to be detrimental to performance on highly congested networks when using AQM algorithms that never drop packets.[8] Modern AQM implementations avoid this pitfall by dropping rather than marking packets at very high load.

Implementations

[edit]

Many modern implementations of the TCP/IP protocol suite have some support for ECN; however, they usually ship with ECN disabled.

ECN support in TCP by hosts

[edit]

Microsoft Windows

[edit]

Windows versions since Windows Server 2008 and Windows Vista support ECN for TCP.[11] Since Windows Server 2012, it is enabled by default in Windows Server versions, because Data Center Transmission Control Protocol (DCTCP) is used.[12] In previous Windows versions and non-server versions it is disabled by default.

ECN support can be enabled using a shell command such as netsh interface tcp set global ecncapability=enabled.

BSD

[edit]

On FreeBSD, ECN for TCP can be configured using the net.inet.tcp.ecn.enable sysctl. By default, it is enabled only for incoming connections that request it. It can also be enabled for all connections or disabled entirely.[13]

NetBSD 4.0 implements ECN support for TCP; it can be activated through the sysctl interface by setting 1 as value for the sysctl parameter net.inet.tcp.ecn.enable.[14]

Likewise, on OpenBSD, the sysctl net.inet.tcp.ecn can be used.[15]

Linux

[edit]

Since version 2.4.20 of the Linux kernel, released in November 2002,[16] Linux supports three working modes of the ECN for TCP, as configured through the sysctl interface by setting parameter /proc/sys/net/ipv4/tcp_ecn to one of the following values:[17]

  • 0 – disable ECN and neither initiate nor accept it
  • 1 – enable ECN when requested by incoming connections, and also request ECN on outgoing connection attempts
  • 2 – (default) enable ECN when requested by incoming connections, but do not request ECN on outgoing connections

Beginning with version 4.1 of the Linux kernel, released in June 2015, the tcp_ecn_fallback mechanism[18]: §6.1.1.1  is enabled by default[19] when ECN is enabled (the value of 1). The fallback mechanism attempts ECN connectivity in the initial setup of outgoing connections, with a graceful fallback for transmissions without ECN capability, mitigating issues with ECN-intolerant hosts or firewalls.

Mac OS X

[edit]

Mac OS X 10.5 and 10.6 implement ECN support for TCP. It is controlled using the Boolean sysctl variables net.inet.tcp.ecn_negotiate_in and net.inet.tcp.ecn_initiate_out.[20] The first variable enables ECN on incoming connections that already have ECN flags set; the second one tries to initiate outgoing connections with ECN enabled. Both variables default to 0,[failed verification] but can be set to 1 to enable the respective behavior.

In June 2015, Apple Inc. announced that OS X 10.11 would have ECN turned on by default,[6] but the OS shipped without that default behavior. In macOS Sierra, ECN is enabled for half of TCP sessions.[21]

iOS

[edit]

In June 2015, Apple Inc. announced that iOS 9, its next version of iOS, would support ECN and have it turned on by default.[6] TCP ECN negotiation is enabled on 5% of randomly selected connections over Wi-Fi / Ethernet in iOS 9 and 50% of randomly selected connections over Wi-Fi / Ethernet and a few cellular carriers in iOS 10[22][23] and 100% for iOS 11[24]

Solaris

[edit]

The Solaris kernel supports three states of ECN for TCP:[25]

  • never – no ECN
  • active – use ECN
  • passive – only advertise ECN support when asked for.

As of Solaris 11.4, the default behavior is active. ECN usage can be modified via ipadm set-prop -p ecn=active tcp.[26]

ECN support in IP by routers

[edit]

Since ECN marking in routers is dependent on some form of active queue management, routers must be configured with a suitable queue discipline in order to perform ECN marking.

Cisco IOS routers perform ECN marking if configured with the WRED queuing discipline since version 12.2(8)T.

Linux routers perform ECN marking if configured with one of the RED or GRED queue disciplines with an explicit ecn parameter, by using the sfb discipline, by using the CoDel Fair Queuing (fq_codel) discipline, or the CAKE[27] queuing discipline.

Modern BSD implementations, such as FreeBSD, NetBSD and OpenBSD, have support for ECN marking in the ALTQ queueing implementation for a number of queuing disciplines, notably RED and Blue. FreeBSD 11 included CoDel, PIE, FQ-CoDel and FQ-PIE queuing disciplines implementation in ipfw and dummynet framework with ECN marking capability.[28]

Data Center TCP

[edit]

Data Center Transmission Control Protocol (Data Center TCP or DCTCP) utilizes ECN to enhance the Transmission Control Protocol congestion control algorithm.[29] It is used in data center networks. Whereas the standard TCP congestion control algorithm is only able to detect the presence of congestion, DCTCP, using ECN, is able to gauge the extent of congestion.[30]

DCTCP modifies the TCP receiver to always relay the exact ECN marking of incoming packets at the cost of ignoring a function that is meant to preserve signalling reliability. This makes a DCTCP sender vulnerable to loss of ACKs from the receiver, which it has no mechanism to detect or cope with.[31] As of July 2014, algorithms that provide equivalent or better receiver feedback in a more reliable approach are an active research topic.[31]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Explicit Congestion Notification

View on Grokipedia
from Grokipedia
Explicit Congestion Notification (ECN) is a network protocol extension that enables routers to explicitly signal impending congestion to endpoints without dropping packets, thereby improving the efficiency of congestion control in IP networks. ECN was first proposed on an experimental basis in RFC 2481 in January 1999, before being advanced to standards track and defined in RFC 3168, published in September 2001. ECN integrates with both the Internet Protocol (IP) and Transmission Control Protocol (TCP) by repurposing two bits in the IP header—specifically bits 6 and 7 of the Differentiated Services (DS) field in IPv4 or the Traffic Class field in IPv6—to indicate ECN capability and congestion status. These bits define four codepoints: 00 for Not-ECN-Capable Transport (Not-ECT), indicating non-ECN support; 10 for ECN-Capable Transport (ECT(0)); 01 for ECT(1), which provides differentiation for potential future uses; and 11 for Congestion Experienced (CE), which routers set to mark packets when queue thresholds signal congestion. In operation, a TCP sender negotiates ECN capability during the connection setup by setting the ECN-Echo (ECE) and Congestion Window Reduced (CWR) flags in the SYN and SYN-ACK segments; upon agreement, the sender marks outgoing packets with an ECT codepoint. If a router detects congestion via mechanisms like Random Early Detection (RED), it sets the CE codepoint on the packet instead of discarding it, allowing the receiver to echo this indication back to the sender using the ECE flag in acknowledgments. The sender then responds by reducing its congestion window as if a packet loss had occurred and signals confirmation to the receiver via the CWR flag, ensuring end-to-end feedback without interrupting data flow. This approach addresses the limitations of traditional , which relies solely on packet drops to infer network overload, by providing proactive notification that reduces latency and , particularly benefiting real-time and delay-sensitive applications. ECN supports incremental deployment, as non-ECN devices can coexist by treating ECN-marked packets as normal, though middleboxes may require configuration to avoid interfering with ECN signaling. Subsequent standards, such as RFC 6679 for RTP over UDP and RFC 9331 for Low Latency, Low Loss, Scalable throughput (L4S) service, have extended ECN's applicability to other protocols and advanced congestion management scenarios.

Introduction

Definition and Purpose

Explicit Congestion Notification (ECN) is an extension to the (IP) and transport protocols like TCP that enables routers to signal impending congestion to endpoints by marking IP packets instead of discarding them. This mechanism utilizes two bits in the —the ECN-Capable (ECT) codepoint to indicate ECN support and the Congestion Experienced (CE) codepoint to mark packets when congestion is detected. The primary purpose of ECN is to provide end-to-end notification of , allowing senders to reduce their transmission rates proactively before occurs, thereby enhancing overall and efficiency. In contrast to traditional drop-based signaling in algorithms like Reno or CUBIC, which interpret packet drops as congestion indicators and trigger window reductions after loss, ECN avoids the associated inefficiencies such as retransmission and throughput degradation. A central concept in ECN is the CE mark, which routers apply to packets when queue buildup signals incipient congestion, informing the receiver and ultimately the sender without interrupting the data flow. For instance, in a router facing queue overflow, an ECN-capable packet with the ECT codepoint would have its header marked with CE rather than being dropped, enabling the protocol to relay this feedback to the sender for rate adjustment. This approach mitigates the delays and resource waste from lost packets, supporting better utilization in IP networks.

Historical Development

The concepts underlying Explicit Congestion Notification (ECN) emerged from efforts to improve TCP's congestion control by providing proactive signals from routers, rather than relying solely on as an implicit indicator. In 1993, Sally Floyd and published a seminal paper introducing Random Early Detection (RED), a gateway that probabilistically discards packets during early stages of congestion to notify TCP senders, addressing the limitations of TCP's loss-based feedback in preventing buffer overflows and global synchronization. This work laid the foundation for explicit signaling mechanisms. Building directly on RED, Floyd's 1994 paper, "TCP and Explicit Congestion Notification," proposed replacing probabilistic drops with bit markings in packet headers to explicitly notify endpoints of congestion, enabling faster and more efficient responses without . The path to standardization began in the late 1990s within the IETF. In January 1999, RFC 2481 was issued as an experimental specification by K. K. Ramakrishnan and Sally Floyd, outlining the addition of ECN to the IP header's octet and corresponding modifications to TCP for negotiating and handling ECN signals. The IETF's Explicit Congestion Notification (ECN) , chartered around 1999 and active through 2001, coordinated these efforts to ensure compatibility across network elements. In September 2001, RFC 3168, authored by Ramakrishnan, Floyd, and David Black, obsoleted RFC 2481 and advanced ECN to Proposed Standard status, providing comprehensive definitions for ECN codepoints in IP, detailed TCP semantics, and interoperability guidelines to support with non-ECN traffic. Despite , ECN deployment remained limited for over a due to challenges such as interference, where firewalls and NAT devices often dropped or rewrote ECN-marked packets, mistaking them for malformed traffic. Adoption began accelerating in the amid surging from data centers, video streaming, and mobile networks, which amplified the inefficiencies of loss-based congestion control. In 2018, RFC 8311 updated RFC 3168 by relaxing experimental restrictions, permitting both ECN-Capable Transport (ECT) codepoints for marking and encouraging broader testing to support low-latency applications and more precise congestion feedback. This revival reflected the growing need for scalable, drop-avoiding mechanisms in high-bandwidth environments.

Standards and Specifications

Core RFCs

The foundational standards for Explicit Congestion Notification (ECN) are defined in a series of IETF RFCs that establish its operation at the IP layer and integration with transport protocols. RFC 3168, published in 2001, introduces ECN as an extension to IP and TCP, enabling routers to mark packets to signal congestion without dropping them. It specifies the use of two bits in the IP header—the Type of Service (TOS) field in IPv4 or the Traffic Class field in IPv6—to encode ECN codepoints: Not-ECT (00, indicating non-ECN-capable transport), ECT(0) (10, ECN-capable transport), ECT(1) (01, an alternate ECN-capable codepoint for potential future use), and CE (11, congestion experienced). Routers detect incipient congestion using active queue management (AQM) algorithms such as Random Early Detection (RED) and probabilistically mark ECN-capable packets by setting the CE codepoint instead of dropping them, while dropping packets only when queues are full. At the transport layer, TCP endpoints negotiate ECN capability during the SYN/SYN-ACK exchange using the ECN-Echo (ECE) and Congestion Window Reduced (CWR) flags in the TCP header; receivers echo CE marks via the ECE flag in ACKs, prompting the sender to reduce its congestion window (typically by half) and acknowledge the response with CWR. ECN's integration with other transport protocols builds on this IP-layer foundation. For the (SCTP), ECN is specified in RFC 4960 (2007), which adapts the IP ECN bits for SCTP's chunk-based structure. SCTP uses the IP header's ECN codepoints directly, with receivers reporting CE marks via ECNE (ECN Echo) chunks and senders responding with CWR chunks to indicate congestion window reduction; occurs during association setup using parameter types in the INIT and INIT-ACK chunks. Similarly, for the (DCCP), designed for unreliable, congestion-controlled flows, ECN support is defined in RFC 4340 (2006). DCCP packets carry ECN capability in feature during connection setup and use the IP ECN bits for marking, with receivers confirming CE via the ECE bit in acknowledgments and senders reducing their sending rate upon receipt; it emphasizes ECN for applications like where is undesirable. All core ECN RFCs emphasize interoperability and to support incremental deployment. Non-ECN devices treat ECN bits as don't-cares or low-priority bits, ignoring marks without adverse effects, while ECN-capable endpoints fall back to non-ECN operation if fails or es block ECN setup packets. For instance, if a packet with ECN is dropped by a non-supporting , the sender retransmits without ECN flags to maintain connectivity. These rules ensure ECN traffic coexists seamlessly with legacy non-ECN flows across diverse networks.

Extensions and Recent Developments

ECN support for the (RTP) over UDP is specified in RFC 6679 (2012), enabling congestion notification for delay-sensitive applications such as voice and video without packet drops. In 2018, RFC 8311 updated the original ECN specification in RFC 3168 by relaxing restrictions that previously prohibited widespread deployment of experimental ECN capabilities, thereby enabling broader testing and innovation in congestion signaling beyond basic loss avoidance. The Accurate ECN (AccECN) protocol, detailed in draft-ietf-tcpm-accurate-ecn (advancing toward as of 2025), enhances TCP feedback by encoding multiple ECN signals per round-trip time within existing TCP header fields, allowing for more precise detection and response to congestion without requiring additional options. The Low Latency, Low Loss, Scalable Throughput (L4S) architecture, formalized in RFC 9330 in 2023, leverages ECN markings in a dual-queue approach at network devices to isolate classic congestion-responsive traffic from scalable control algorithms, achieving sub-millisecond queuing delays while maintaining high throughput. ECN++, specified in draft-ietf-tcpm-generalized-ecn (updated in 2025), experimentally extends ECN support to TCP control packets such as and ACK, facilitating ECN negotiation during connection setup and enabling congestion signaling on retransmissions for improved initial sizing. Ongoing IETF work includes draft-halmir-mpls-ecn (2025), which integrates ECN into MPLS networks via network actions labels to propagate congestion markings across label-switched paths without packet drops. Additionally, QUIC's core specification in RFC 9000 incorporates ECN feedback mechanisms, with extensions in RFC 9002 enabling endpoints to report ECN-CE counts for congestion control, supporting low-latency applications over UDP. These developments are driven by increasing demands in data centers, networks, and AI workloads, where low-loss congestion signaling is essential for handling high-volume, latency-sensitive traffic without traditional packet drops.

How ECN Works

ECN in the IP Layer

Explicit Congestion Notification (ECN) operates at the IP layer by utilizing two bits in the to indicate congestion without dropping packets. These bits, known as the ECN field, are located in the Differentiated Services (DS) field in IPv4 or the Traffic Class octet in : specifically, bits 6 and 7. The ECN field supports four codepoints: 00 for Not-ECT (Not ECN-Capable Transport), indicating packets ineligible for ECN marking; 01 for ECT(1) and 10 for ECT(0), both denoting ECN-Capable Transport where packets may be marked during congestion; and 11 for CE (Congestion Experienced), signaling that congestion has occurred along the path. Packets marked as ECT are eligible for routers to set the CE codepoint instead of discarding them, allowing end systems to react to congestion signals. Routers integrate ECN with (AQM) mechanisms, such as Random Early Detection (RED) or (CoDel), to detect and respond to incipient congestion based on queue occupancy. In AQM-enabled routers, the probability of applying an ECN mark increases as the average queue length grows, providing an early warning before queues overflow. For instance, in RED with ECN support (RED-ECN), the marking decision uses the average queue size to probabilistically select ECT packets for CE marking rather than dropping them, thereby preserving packet delivery while notifying endpoints of building congestion. Similarly, monitors queue delay and applies ECN marks when delays exceed a target threshold, aiming to control latency without relying solely on drops. The marking process occurs when a router determines that an ECT packet would otherwise be dropped due to congestion; instead, it sets the ECN field to CE and forwards the packet. This probabilistic marking helps avoid synchronized bursts from multiple flows. Non-ECT packets (codepoint 00) are treated traditionally: they may be dropped if the queue is full, but not marked. Once set to CE, the codepoint must not be altered by subsequent routers or tunnels, ensuring the congestion signal propagates to the destination. The ECN field placement is identical in IPv4 and IPv6, facilitating consistent handling across protocol versions. In IPv4, setting the CE codepoint requires recalculating the header due to the change in the DS field. IPv6, lacking a header , avoids this step. For tunneling protocols like IP-in-IP, ECN marks are preserved by copying the outer header's ECN field to the inner header upon decapsulation, or setting CE if either header indicates congestion, to prevent mark loss in encapsulated traffic. In RED-ECN, the marking probability PmarkP_{\text{mark}} for an average queue length qq between the minimum threshold min⁡th\min_{th} and maximum threshold max⁡th\max_{th} is given by: Pmark=max⁡P×q−min⁡thmax⁡th−min⁡thP_{\text{mark}} = \max_P \times \frac{q - \min_{th}}{\max_{th} - \min_{th}} where max⁡P\max_P is the maximum marking probability (typically 0.02). No marking occurs if q<min⁡thq < \min_{th}, and all packets are eligible for marking (or dropping) if q>max⁡thq > \max_{th}. This linear increase helps signal moderate congestion gradually.

ECN in the Transport Layer

In the transport layer, receivers inspect the Explicit Congestion Notification (ECN) field in the IP header of incoming packets to detect congestion experienced (CE) marks set by network nodes. Upon detecting one or more CE marks, the receiver echoes this information back to the sender using dedicated fields or flags in the transport protocol header, ensuring timely feedback without altering the underlying data flow. This mechanism allows endpoints to respond to congestion signals proactively, treating them as equivalent to packet drops for the purpose of rate adjustment. Senders integrate ECN feedback into their congestion control algorithms by reducing the congestion window (cwnd) upon receipt of echoed marks, typically halving it once per round-trip time in a akin to fast recovery after a detected loss. This response decreases the amount of outstanding data, alleviating network pressure while maintaining throughput stability. The sender may also acknowledge the congestion reduction to the receiver via a specific , confirming that the signal has been acted upon and preventing persistent echoing. Similar high-level feedback mechanisms are employed in non-TCP protocols like (DCCP), where receivers use Ack Vectors to echo CE marks, allowing senders to invoke comparable congestion responses. ECN handling in the emphasizes distinguishing marks from actual packet losses, as a CE-marked packet is successfully delivered and requires no retransmission—only a congestion control adjustment. This separation ensures that ECN enhances efficiency for delay-sensitive or loss-intolerant applications by avoiding unnecessary recovery actions triggered by drops.

Negotiation and Compatibility

The negotiation of Explicit Congestion Notification (ECN) capability in TCP occurs during the three-way to ensure both endpoints support the mechanism before enabling it. The initiating endpoint sends a packet with both the ECN-Echo (ECE) and Congestion Window Reduced (CWR) flags set in the TCP header to signal its ECN capability. If the responding endpoint supports ECN, it replies with a SYN-ACK packet that sets the ECE flag while clearing the CWR flag; the initiator then sends an ACK to complete the , confirming mutual support. If the responder does not support ECN, it clears both ECE and CWR flags in the SYN-ACK, allowing the connection to proceed without ECN. According to the rules in RFC 3168, endpoints must not set the ECN-Capable Transport (ECT) codepoint in the IP header of data packets unless ECN capability has been successfully negotiated in both directions—meaning the endpoint has sent an ECN-setup SYN or SYN-ACK and received a corresponding response. If negotiation fails or is not attempted, endpoints are required to clear any ECN bits (such as Congestion Experienced, or CE) in outgoing packets to prevent unintended signaling. Routers, in turn, ignore ECN markings on non-ECT packets and treat them as non-ECN-capable, potentially dropping them during congestion rather than marking them. Compatibility challenges arise primarily from middleboxes, such as firewalls and network address translators (NATs), which may strip ECN bits, drop ECN-setup packets, or respond with resets (RSTs), often mistaking them for port-scanning attempts or invalid traffic. To mitigate this, RFC 8311 updates RFC 3168 by relaxing restrictions on ECN usage, permitting experimentation with ECN on TCP control packets (like ) and retransmissions even before full negotiation, and advising middleboxes against discarding such packets unless responding to a verified attack; this encourages broader deployment without immediate blocking. If ECN negotiation fails—due to lack of support, middlebox interference, or no response—the connection automatically falls back to traditional packet drop-based congestion control, ensuring reliable operation without any inherent penalty for attempting ECN. For validating endpoint ECN support and detecting compatibility issues like middlebox stripping, tools such as the TCP Behavior Inference Tool (TBIT) can probe remote hosts over the to infer ECN capability and path behavior.

Applications and Protocols

ECN with TCP

Explicit Congestion Notification (ECN) integrates with TCP primarily through modifications to the TCP header and specific behaviors during connection establishment and data transfer. Two bits in the 6-bit field of the TCP header are repurposed for ECN: bit 9 for the ECN-Echo (ECE) flag and bit 8 for the Congestion Window Reduced (CWR) flag. The receiver sets the ECE flag in acknowledgment (ACK) packets to report the receipt of one or more IP packets marked with the Congestion Experienced (CE) codepoint, informing the sender of without . In response, the sender sets the CWR flag in the subsequent data packet's TCP header to acknowledge that it has reacted to the congestion indication by reducing its transmission rate. ECN capability must be negotiated during the TCP three-way handshake to ensure both endpoints support the mechanism and to prevent misinterpretation of flags. The SYN packet from the client includes both ECE and CWR flags set to indicate ECN support. The server replies with a SYN-ACK packet setting only the ECE flag, confirming its capability while avoiding CWR to prevent confusion with data transmission responses. Neither endpoint sets the Explicit Congestion Notification (ECT) codepoint in the IP header of SYN or SYN-ACK packets under the original specification, which helps avoid complications with initial congestion window sizing and potential attacks. This negotiation ensures ECN is activated only for data packets after successful handshake completion. During data transfer, the receiver echoes congestion marks by setting ECE in every ACK following the receipt of a CE-marked packet, entering an ECN-Echo state until the sender acknowledges the reduction. Upon receiving the first ECE-marked ACK in a round-trip time (RTT), the sender reduces its congestion window (cwnd) by half—equivalent to the response for a detected —and enters a state where it ignores subsequent ECE marks until the next RTT to prevent over-reaction. The sender then sets CWR in the TCP header of the next full-sized data packet, prompting the receiver to cease setting ECE in further ACKs. This process is formalized as: \text{new_cwnd} = \frac{\text{cwnd}}{2} applied to the first ECN mark per RTT, with the minimum cwnd clamped at one maximum segment size (MSS) and retransmission timers reset if necessary. The original ECN specification prohibits setting ECT on non-data TCP control packets, such as pure ACKs, window probes, retransmissions, SYN, SYN-ACK, FIN, and RST, to mitigate denial-of-service risks and ensure control packet reliability. The ECN++ experimental extension addresses this limitation by permitting ECT marking on these packets, including during handshakes and graceful shutdowns, while preserving negotiation integrity. Specifically, it allows SYN and SYN-ACK packets to carry ECT after negotiation confirmation, and extends CE marking and feedback to FIN and RST for end-to-end congestion signaling in control flows. ECN behaviors remain compatible with modern TCP congestion control variants, which adapt the core window reduction mechanism to their algorithms. For instance, CUBIC employs the standard ECN response of halving cwnd upon ECE receipt to maintain its cubic scaling function for long-distance networks. BBRv2 similarly integrates ECN by treating CE marks as primary congestion signals, halving cwnd on ECE and using them to refine bandwidth and RTT estimates for better queue management. Across these variants, the per-RTT adjustment \text{new_cwnd} = \frac{\text{cwnd}}{2} on the first mark ensures consistent congestion avoidance.

ECN with Other Protocols

Explicit Congestion Notification (ECN) has been adapted for various transport protocols beyond TCP to enable congestion signaling in diverse network environments, particularly those requiring reliability, unreliability, or real-time performance. These adaptations leverage the IP-layer ECN marking while incorporating protocol-specific mechanisms for , feedback, and congestion response, ensuring compatibility with the underlying unreliable service of IP. In the (SCTP), ECN support is integrated to provide reliable, message-oriented transport with congestion awareness. SCTP uses a dedicated ECN-Echo (ECE) chunk for receivers to report congestion experienced (CE) marks from incoming packets, providing cumulative feedback on marked data chunks. Upon receiving an ECE chunk, the sender responds by reducing its slow-start threshold and congestion window, mirroring TCP's congestion avoidance but adapted to SCTP's multi-streaming model. This mechanism, specified in the SCTP standard, enhances throughput in multi-homed scenarios without relying on . The (DCCP) incorporates ECN to support unreliable, congestion-controlled delivery suitable for applications like and . ECN capability is negotiated during connection setup using DCCP's feature negotiation framework, where endpoints exchange ECN Inc and ECN Confirm values to establish support and verify nonces for feedback integrity. Receivers report ECN marks via Confirm packets, which include byte counts of confirmed data and handle nonce echoes to prevent misreporting; this allows senders to adjust rates promptly for low-latency flows. DCCP's design makes it particularly apt for real-time media, where ECN reduces compared to loss-based signaling. QUIC, a UDP-based multiplexed transport protocol, embeds ECN feedback directly into its acknowledgment (ACK) frames to support modern web applications, including . In version 1, endpoints negotiate ECN during connection setup via transport parameters, and receivers report cumulative counts of ECN-Capable Transport (ECT) and CE-marked packets in ACK frames, enabling precise congestion window adjustments without . Extensions like Accurate ECN (AccECN) further refine this by providing per-packet feedback signals, allowing more granular responses to congestion and integration with low-latency services in deployments. This approach leverages 's and stream multiplexing for robust, privacy-preserving congestion control. For UDP-based protocols lacking built-in transport headers, such as those used in real-time applications, ECN is implemented at the application level, exemplified by the (RTP) for VoIP. RTP over UDP sets the IP ECN field to ECT(0) for sent packets and uses out-of-band signaling, often via (SDP) attributes, to negotiate ECN capability between endpoints. Receivers feedback ECN marks through (RTCP) reports, such as extended RTCP feedback messages tallying CE packets, prompting senders to reduce rates adaptively. This setup avoids modifying UDP but relies on application-layer coordination for congestion responsiveness in bandwidth-constrained scenarios like voice calls. A key challenge in applying ECN to UDP-based protocols stems from UDP's connectionless nature, which lacks a standardized for capability negotiation. Unlike connection-oriented protocols, UDP requires custom out-of-band mechanisms—such as SDP for RTP or application-specific signaling—to agree on ECN use, increasing and potential for incompatibility across diverse endpoints. Additionally, ensuring end-to-end ECN through middleboxes demands careful handling of feedback without native acknowledgments, often leading to reliance on periodic reports that may delay congestion response.

Data Center and Specialized Uses

In data centers, Explicit Congestion Notification (ECN) enables efficient congestion management in environments with shallow switch buffers and high-speed links. Data Center TCP (DCTCP), proposed by Microsoft Research in 2010, leverages ECN to address buffer pressure in such networks. Switches mark packets with the Congestion Experienced (CE) codepoint when queue occupancy exceeds a small threshold (e.g., 65 packets for 10 Gbps links), providing multi-bit feedback on congestion levels. The sender estimates the fraction of marked packets (α) using an exponential moving average: α ← (1 − g) × α + g × F, where g is a smoothing factor (typically 1/16) and F is the observed mark fraction in recent acknowledgments. Upon congestion, the congestion window (cwnd) is reduced proportionally: cwnd ← cwnd × (1 − α/2). This approach maintains low queue lengths (e.g., tens of packets) while achieving near line-rate throughput, reducing buffer usage by up to 90% compared to standard TCP. RDMA over Converged Ethernet (RoCE), particularly RoCEv2, integrates ECN to support lossless fabrics in storage and compute interconnects, reducing reliance on Priority Flow Control (PFC) which can cause . ECN marking signals congestion via the IP Differentiated Services (DS) field, allowing endpoints to adjust rates without packet drops. In RoCE networks, switches enable ECN on specific priorities (e.g., 0-7), and adapters like ConnectX series implement ECN reaction points (RP) and notification points (NP) to process marks and generate congestion notification packets (CNPs). This setup mitigates PFC storms in high-throughput scenarios, such as GPU clusters, by enabling proactive based on CE marks. /Mellanox implementations, deployed in production s, configure ECN per port and priority via interfaces, ensuring compatibility with shallow-buffered Ethernet switches for RDMA traffic. Low Latency, Low Loss, Scalable throughput (L4S) extends ECN for data center applications by using a dual-queue architecture to isolate latency-sensitive "mice" flows (short, interactive) from bandwidth-intensive "elephant" flows (long-lived). The L4S queue applies frequent ECN marking (ECT(1) codepoint) with a Coupled AQM that balances marking rates between queues: the Classic queue (ECT(0)) uses drop-tail or mild ECN, while the L4S queue enforces sub-millisecond queuing delay (e.g., <1 ms at 99th percentile) via aggressive, scalable controls like DCTCP-style reductions. This separation prevents elephant flows from inflating latency for mice flows, enabling near-zero queuing delay in controlled data center environments. RFC 9332 specifies the coupling mechanism, where L4S marking probability (p_L) relates to Classic drop probability (p_C) as p_C ≈ (p_L / 2)^2 for fairness. Emerging 2025 trends highlight ECN's role in edge computing for AI networks, where low-latency inference demands sub-10 ms end-to-end delays. In RAN, ECN-like signaling (e.g., via L4Span) estimates per-user and marks packets to throttle rates, supporting real-time AI tasks like distributed at the . Integration of with (TSN) in industrial IoT enables converged networks for low-latency control loops in factories using TSN's deterministic scheduling (IEEE 802.1Qbv). For inter-data center traffic, Google's B4 WAN employs ECN-enabled TCP variants to optimize global flows, achieving high utilization across continents. /Mellanox hardware further supports these uses in AI fabrics, with ECN tuned for RoCE in GPU-accelerated clusters.

Performance Considerations

Benefits and Improvements

Explicit Congestion Notification (ECN) enhances network efficiency by signaling congestion through packet marking rather than dropping, thereby avoiding the delays associated with retransmissions and enabling proactive congestion control. This mechanism reduces overall latency, particularly in scenarios involving bursty traffic or mild congestion, where traditional drop-based methods like tail-drop queuing lead to unnecessary and recovery times. Studies indicate that ECN can lower tail latency in web services compared to non-ECN TCP, as it mitigates the impact of and retransmission timeouts (RTOs). In environments, ECN supports protocols like Data Center TCP (DCTCP), which uses ECN markings to estimate fractional buffer occupancy and adjust sending rates accordingly. DCTCP achieves near-line-rate throughput (e.g., 95% of link capacity at 1 Gbps) on buffered links during congestion, while reducing average and tail latencies for short flows to under 1 ms, compared to 19 ms with standard TCP. This results in up to a 90% reduction in required buffer space without degradation, allowing networks to operate with smaller queues and higher utilization. The Low Latency, Low Loss, Scalable throughput (L4S) architecture further improves ECN by enabling scalably responsive congestion controls that maintain standing queue delays below 1 ms—even under heavy load—versus 10-100 ms in classic ECN or drop-tail systems. Simulations and evaluations show that L4S supports 2x buffer size reduction without increased loss, promoting better link utilization through rapid rate adaptations to early congestion signals. In real-world applications, ECN improves VoIP quality by reducing and bursty losses that degrade audio, as markings allow endpoints to rates before drops occur, preserving low-delay paths. Similarly, for video streaming, ECN minimizes artifacts from by sustaining higher throughput during congestion, leading to smoother playback without frequent rebuffering.

Limitations and Challenges

One significant limitation of Explicit Congestion Notification (ECN) is interference from middleboxes, such as firewalls and NAT devices, which often drop or alter packets marked with ECN bits, mistaking them for malformed . This issue persists in the core, where studies indicate that ECN feedback loops fail approximately 40% of the time, particularly at autonomous system boundaries, leading to unreliable congestion signaling and fallback to packet loss-based mechanisms. Recent measurements confirm that while ECN support has grown threefold on servers since earlier assessments, middlebox-induced traversal problems still affect a notable fraction of paths, complicating end-to-end deployment. Asymmetric routing poses another challenge for ECN, as the mechanism relies on bidirectional feedback where acknowledgments carry congestion marks from the reverse path; if the return path includes devices that block or modify these signals, the sender receives lost or incomplete feedback, potentially causing underutilization of bandwidth. This requires precise tuning of (AQM) algorithms, such as adjusting marking thresholds dynamically, to compensate for path asymmetries and maintain effective congestion control without excessive latency spikes. In environments with frequent route changes, like mobile or multi-homed networks, such tuning becomes even more critical to avoid feedback loops breaking entirely. ECN introduces additional overhead through its process during connection setup and the extra for marking and feedback interpretation, which is minimal in standard scenarios but can become noticeable in ultra-low-latency applications like real-time gaming or financial trading where sub-millisecond delays are essential. This overhead arises from the need to inspect and set ECN bits in IP headers and TCP options, potentially conflicting with optimized paths. Security risks in ECN stem from its susceptibility to adversarial manipulation, where malicious middleboxes or on-path can inject false congestion marks to legitimate , mimicking denial-of-service effects without overt packet drops. Mitigations are addressed through extensions like Accurate ECN (AccECN), which enhances feedback accuracy by providing multiple signals per round-trip time and includes validation checks to detect and ignore anomalous markings, thereby preserving in untrusted networks. Despite progress, adoption gaps remain a key barrier, with low ECN support in ISP core routers limiting widespread use; as of 2025, only select providers like have begun rolling out Low Latency, Low Loss, Scalable throughput (L4S) capabilities in limited areas, with ongoing trials by others such as demonstrating up to 94% delay reductions in live networks. This fragmented deployment hinders L4S's potential for interactive applications, as uncoordinated upgrades risk interworking issues with classic ECN paths.

Deployment and Implementations

End-Host Support

End-host support for Explicit Congestion Notification (ECN) has been integrated into major operating systems, enabling endpoints to negotiate and utilize ECN capabilities during connection establishment. In support for ECN was introduced in version 2.4 in 2001, allowing TCP to respond to congestion signals without . The configuration is managed via the parameter net.ipv4.tcp_ecn, where a value of 2 (the kernel default since early implementations) enables ECN for incoming connections that request it, while outgoing connections do not initiate unless explicitly configured otherwise. This setting persists across kernel series, including the 5.x releases from the late onward, promoting broader adoption in server and client environments. Windows provides ECN support for TCP starting with and , with the feature enabled by default in editions since 2012 but disabled by default in client versions like and 11 to mitigate compatibility issues with legacy networks. Users can enable it globally using the command netsh int tcp set global ecn=enabled, and its status can be verified via with Get-NetTCPSetting, which reports ECN capability across TCP profiles. On Apple platforms, ECN support has been available in the kernel since macOS 10.5 (2007), though it remained disabled by default until macOS 10.11 El Capitan and in 2015, when Apple enabled it for all supported devices to improve performance over and cellular networks, including during handoffs. Subsequent versions, such as and (2016), extended this to 100% enablement on and select cellular providers, prioritizing low-latency scenarios. Android, built on the , inherits ECN support from kernel versions integrated since its early releases, with full usability available since Android 4.0 (2011) through kernel configurations, though user-facing enablement requires root access or custom builds. BSD variants like and include ECN in their TCP stacks by default, with FreeBSD's net.inet.tcp.ecn.enable set to 2, permitting incoming ECN requests while outgoing connections do not initiate negotiation unless explicitly configured. Web applications and browsers further enhance end-host ECN usage, particularly with QUIC; for instance, Google Chrome and Mozilla Firefox negotiate ECN during QUIC handshakes as per the protocol's specification, enabling congestion feedback in HTTP/3 sessions without relying solely on TCP. As of 2025, ECN support is near-universal among client operating systems, though actual deployment remains limited due to middlebox interference, such as legacy firewalls that drop ECN-marked packets, with APNIC measurements indicating low TCP ECN option rates of around 2-3% in client-initiated connections from February to August 2025, though server-side adoption remains opt-in to avoid interactions with legacy infrastructure.

Network Device Support

Explicit Congestion Notification (ECN) support in network devices, particularly routers and switches, enables intermediate hardware to mark packets indicating congestion rather than dropping them, integrating with mechanisms like (WRED) for proactive . In routers, and IOS XE platforms have supported ECN since version 12.2(8)T in 2001, with integration into WRED for marking packets based on queue thresholds to signal impending congestion without loss. Juniper Junos operating system provides (CoS) ECN capabilities, allowing per-queue marking for IP traffic since version 8.0, enhancing end-to-end notification in TCP/IP networks. Open-source routing platforms like , built on , include default (AQM) features that support ECN marking through kernel-level configurations for congestion avoidance. Data center switches from (formerly Mellanox) have incorporated ECN since around , particularly for RoCEv2 deployments, where it enables end-to-end congestion control in high-performance fabrics by marking packets in hardware queues. Arista and Cumulus Linux-based switches support ECN in leaf-spine architectures, optimizing RoCE traffic in AI and storage networks through buffer threshold-based marking to prevent loss in oversubscribed environments. Application-Specific Integrated Circuits (ASICs) like Broadcom's Jericho series perform ECN marking directly in hardware, as seen in Jericho-based AI networking solutions that use ECN signaling for proactive congestion control across distributed data centers. In Network Function Virtualization (NFV) environments, cloud providers such as Google Cloud Platform (GCP) enable ECN in virtual routers and Kubernetes Engine (GKE) nodes, where TCP stacks can be configured to use ECN for queue management in containerized workloads. As of 2025, ECN adoption in enterprise routers continues to grow, driven by needs for low-latency AI and cloud applications, though specific penetration rates vary by vendor. (ISP) deployment is increasing through Low Latency, Low Loss, Scalable throughput (L4S) pilots, which rely on ECN for real-time congestion signaling in production networks. Monitoring tools like sFlow provide ECN statistics by sampling traffic and queue metrics on supported devices, aiding in visibility of marking rates and congestion events. ECN configuration in network devices typically involves threshold-based marking, where a minimum threshold (min-th) triggers initial Congestion Experienced (CE) marks, ramping up probability until a maximum threshold (max-th). For example, setting min-th to 10 packets and max-th to 30 packets allows gradual CE marking as queue depth increases, configurable via scheduler profiles in systems like Junos.

References

  1. https://www.rfc-editor.org/rfc/rfc3168.html
  2. https://www.rfc-editor.org/rfc/rfc2481.html
  3. https://www.rfc-editor.org/rfc/rfc6679.html
  4. https://www.rfc-editor.org/rfc/rfc9331.html
  5. https://datatracker.ietf.org/doc/html/rfc3168
  6. https://datatracker.ietf.org/doc/html/rfc5681
  7. https://datatracker.ietf.org/doc/html/rfc8312
  8. https://datatracker.ietf.org/doc/html/rfc8087
  9. https://www.utdallas.edu/~jjue/cs6390/papers/red.pdf
  10. https://www.icir.org/floyd/papers/tcp_ecn.4.pdf
  11. https://www.rfc-editor.org/rfc/rfc2481
  12. https://datatracker.ietf.org/wg/ecn/history/
  13. https://ozgualay.com/wp-content/uploads/2018/05/ecn_commag_2018.pdf
  14. https://datatracker.ietf.org/doc/html/rfc4960
  15. https://datatracker.ietf.org/doc/html/rfc4340
  16. https://datatracker.ietf.org/doc/html/rfc6679
  17. https://datatracker.ietf.org/doc/html/rfc8311
  18. https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/
  19. https://datatracker.ietf.org/doc/draft-ietf-tcpm-generalized-ecn/
  20. https://datatracker.ietf.org/doc/draft-halmir-mpls-ecn/
  21. https://datatracker.ietf.org/doc/html/rfc9000
  22. https://datatracker.ietf.org/doc/html/rfc3168#section-5
  23. https://datatracker.ietf.org/doc/html/rfc2309#section-4
  24. https://datatracker.ietf.org/doc/html/rfc3168#section-6.1
  25. https://datatracker.ietf.org/doc/html/rfc3168#section-9.1
  26. https://datatracker.ietf.org/doc/html/rfc3168#section-10
  27. https://datatracker.ietf.org/doc/html/rfc4341
  28. https://www.icir.org/tbit/ecn-tbit.html
  29. https://datatracker.ietf.org/doc/html/rfc3168#section-6.1.1
  30. https://datatracker.ietf.org/doc/html/rfc3168#section-6.1.2
  31. https://datatracker.ietf.org/meeting/104/materials/slides-104-iccrg-an-update-on-bbr-00
  32. https://datatracker.ietf.org/doc/html/rfc9260
  33. https://people.csail.mit.edu/alizadeh/papers/dctcp-sigcomm10.pdf
  34. https://datatracker.ietf.org/doc/rfc8257/
  35. https://docs.nvidia.com/networking/display/MLNXOFEDv461000/Explicit%2BCongestion%2BNotification%2B%28ECN%29
  36. https://www.cisco.com/c/en/us/td/docs/dcn/whitepapers/roce-storage-implementation-over-nxos-vxlan-fabrics.html
  37. https://datatracker.ietf.org/doc/rfc9332/
  38. https://www.ericsson.com/en/reports-and-papers/ericsson-technology-review/articles/5g-tsn-integration-for-industrial-automation
  39. https://datatracker.ietf.org/doc/html/rfc9330
  40. https://www.researchgate.net/publication/283815632_Enabling_Internet-Wide_Deployment_of_Explicit_Congestion_Notification
  41. https://www.semanticscholar.org/paper/7e6ac399537acad37d2b68da7294059ebb784ef4
  42. https://conferences.sigcomm.org/sigcomm/2021/files/papers/3452296.3472927.pdf
  43. https://www.researchgate.net/publication/322650897_Alternative_backoff_Achieving_low_latency_and_high_throughput_with_ECN_and_AQM
  44. https://www.theverge.com/news/601100/comcast-l4s-low-latency-internet
  45. https://www.vodafone.com/news/technology/vodafone-and-nokia-achieve-world-first-trial-of-lag-busting-technology-on-fibre-broadband
  46. https://blog.apnic.net/2025/09/11/measuring-explicit-congestion-notification/
  47. https://www.catchpoint.com/learn/the-internet-resilience-report-2025
  48. https://lists.debian.org/debian-devel/2001/09/msg00082.html
  49. https://wiki.archlinux.org/title/Network_configuration/Ethernet
  50. https://www.kernel.org/doc/html/latest/networking/ip-sysctl.html
  51. https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
  52. https://www.speedguide.net/articles/windows-1011-tcp-ip-tweaks-5077
  53. https://learn.microsoft.com/en-us/answers/questions/2236017/how-to-resolve-ecn-negotiation-failure-between-win
  54. https://eclecticlight.co/2015/12/31/el-capitan-does-it-deal-with-network-congestion-at-last/
  55. https://arstechnica.com/gadgets/2016/06/ipv6-ecn-qos-and-other-networking-improvements-in-ios-10-and-macos-sierra/
  56. https://www.caida.org/workshops/isma/1102/slides/aims1102_sbauer.pdf
  57. https://wiki.freebsd.org/TransportProtocols/tcp_rfc_notes
  58. https://man.freebsd.org/cgi/man.cgi?query=tcp&sektion=4
  59. https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC
  60. https://labs.apnic.net/index.php/2025/09/08/measuring-ecn/
  61. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_conavd/configuration/15-mt/qos-conavd-15-mt-book/qos-conavd-wred-ecn.html
  62. https://www.juniper.net/documentation/us/en/software/junos/cos/topics/topic-map/explicit-congestion-notification.html
  63. https://forum.vyos.io/t/qos-qoe-support-in-vyos/12376
  64. https://enterprise-support.nvidia.com/s/article/howto-configure-ecn-on-mellanox-ethernet-switches--spectrum-x
  65. https://www.arista.com/assets/data/pdf/AI-Network-Fabric_Deployment_Guide.pdf
  66. https://www.broadcom.com/blog/hyperports-supercharge-the-multi-building-ai-training-clusters
  67. https://docs.cloud.google.com/kubernetes-engine/docs/how-to/node-system-config
  68. https://techexpo.scte.org/session/the-programmable-network-automation-interoperability-and-intelligence/l4s-real-time-congestion-management-at-the-speed-of-software/
  69. https://www.cisco.com/c/en/us/td/docs/iosxr/cisco8000/netflow/configuration/b-netflow-configuration-ios-xr-8000/monitor-traffic-using-sflow.html
  70. https://www.juniper.net/documentation/us/en/software/junos/cos-ex/cos/topics/example/cos-schedulers-explicit-congestion-notification-configuring.html
Add your contribution
Related Hubs
User Avatar
No comments yet.