Explicit Congestion Notification - ECN, ECE, CWE, NS, ECT, CE

Last modified on 16 Feb, 2021. Revision 10
ECN is a mechanism in TCP/IP where routers can signal that they are almost overloaded. This lets endpoints slow down before packet-loss actually occurs.As of v12.00.24 and v13.00.06, the TCPECN setting in Clavister cOS Core defaults to "Ignore", meaning that it passes the ECN-related bits through, unmodified.
Up to date for
Core 12.00.24, 13.00.06
Status OK


Signalling Congestion - forward direction - IP header

Evolution of IP header ToS bits into DSCP and ECN

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

So, if the sender sets the bits to “00”, no router will mark the packet as congested, as they then assume ECN is not supported.


Notifying the sender - return direction - TCP header

When a host receives “Congestion Encountered, CE” in the IP header of a packet, it has to somehow notify the sender of this for it to be useful.

For a TCP connection, this happens in the TCP ACK packet returned.

  • ECE - Echo of Congestion Encountered - starts being set in TCP packets when "CE" is seen
  • CWR - Congestion Window Reduced = "OK, I saw your ECE, you can turn it off now"
  • NS = Nonce Sum RFC3540 was meant to improve robustness of the protocol but was never standardized. The bit assignment still remains in the specification, however, and should be treated the same way as ECE and CWD - either passed-on, or stripped.

Problems with firewalls

ECE and CWR were not defined in the original TCP specification, and were often referred to as “christmas-tree lamp test” bits- XMAS and, naturally, YMAS.

Firewalls long took them as an indication of “something fishy” going on and defaulted to blocking packets that had them set, leading to ECN-enabled TCP connections breaking.

See BCP60 - Inappropriate TCP Resets Considered Harmful by ECN wizard Sally Floyd for a write-up on this subject. (And yes the Mikael Olsson in the Acknowledgements sections is ours)

ECN in cOS Core

Clavister cOS Core has long defaulted to stripping the ECN bits which does not break TCP, but does disable ECN. This due to the fact that there have been bugs in endpoints (and, notably, other firewalls, e.g. CVE-2001-0183 - FreeBSD ipfw allowing ruleset bypass with ECE bit set) related to this bit, and the simple fact that ECN functionality was only recently widely-enabled by default.

cOS Core’s behavior is controlled by the “TCPECN” setting.

As of mid 2020, v12.00.24 and v13.00.06, the TCPECN setting defaults to “Ignore”, meaning that it passes the ECN-related bits through, unmodified.


Further reading

Related articles

The TCP Window Scale Log Event
15 Nov, 2022 tcp log core
QoS / Traffic Shaping: Will cOS Core alter DiffServ tagging?
6 Feb, 2023 core trafficshaping pipes tcp



Tagstcpecn