TCP Flags Continued: CWR + ECE

CWR (Congestion Window Reduced) and ECE (ECN-Echo) are two TCP header flags that work together to signal network congestion between sender and receiver without dropping packets.

CWR and ECE, combined with two IP header flags (ECT and CE), replace the traditional drop-based congestion signal with an explicit warning that lets senders slow down before packets are lost.

Why ECN Replaced Packet Drops as a Congestion Signal

Without ECN, the only congestion feedback mechanism was packet drops. Drops triggered retransmit timeouts (RTO) at the transport layer, adding latency that hit hardest on latency-sensitive applications such as streaming, browsing, and real-time communication.

How CWR and ECE Work Together

ECN required changes to both the TCP and IP headers (RFC 3168). Two one-bit flags were added to the TCP header:

1. CWR (bit 8)
2. ECE (bit 9)

Two flags were repurposed in the IP header's differentiated services field:

1. ECT (bit 14)
2. CE (bit 15)

Step 1: ECN Negotiation During the Handshake

During the synchronization phase of a connection between client and server, the TCP CWR and ECE flags work together to establish whether the connection supports congestion notification.

The sender transmits a SYN packet with the ECE and CWR flags set, and the receiver responds with a SYN-ACK that has only the ECE flag set. Any other configuration indicates a non-ECN setup.

Step 2: Router Marks Congestion Instead of Dropping

In an ECN-aware network, the process works like this (simplified): when a router detects congestion, instead of dropping packets destined for a receiver, it marks them with the CE flag in the IP header and delivers the packet.

Step 3: Receiver Signals Congestion Back to Sender

Before acknowledging the receipt of the packet, the receiver sets the ECE flag in the TCP header of the ACK and sends it back to the sender. The sender, having received the ECE-marked ACK, responds by halving the send window and reducing the slow start threshold.

Together these three steps replace the drop entirely: the router signals congestion via CE, the receiver echoes it via ECE, and the sender reduces its window via CWR, all without a single packet being dropped or retransmitted.

Is ECN Widely Supported Today?

ECN support is now broadly available across modern operating systems and increasingly enabled by default:

• Linux: ECN has been available for years; most distributions default to passive negotiation, enabling ECN when the client requests it
• macOS and iOS: Apple enabled ECN by default starting with iOS 9 and OS X El Capitan; it has been on by default across Apple platforms since
• Windows: ECN has been available since Windows Vista/Server 2008; Windows Server 2012 introduced Data Center TCP (DCTCP), which uses ECN for congestion signaling in data center environments. ECN remains disabled by default in standard Windows configurations but can be enabled via PowerShell

Despite broad OS support, real-world adoption depends on network infrastructure. Some older or misconfigured routers mishandle ECN-marked packets, which is why passive negotiation (ECN enabled only when both sides agree) remains the safer default for public internet traffic.

Should You Enable ECN?

For most modern environments, ECN is worth enabling as it reduces retransmission-driven latency without requiring changes to your application layer.

The main caveat is network infrastructure: if your traffic passes through older routers that mishandle CE-marked packets, ECN can cause more problems than it solves.

If you're seeing unexplained latency spikes or retransmission patterns in your network traffic, ECN misconfiguration is one place to look.