TCP Flags Continued: CWR + ECE

Today we venture forth looking at a couple of additional flags found in the TCP header: CWR and ECE. These TCP flags are used together with two flags in the IP header (ECT and CE) to warn senders of congestion in the network thereby avoiding packet drops and retransmissions.

Background

Prior to the advent of explicit congestion notification [ECN], the primary feedback mechanism available was packet drops. While recovery from packet drops would be handled by the transport layer or an upper layer, they would typically result in latency arising from retransmit timeouts [RTO]. If one is using a latency sensitive application, this delay could have adverse implications for one’s experience. Some mechanism was needed to notify both sender and receiver of congestion.

Managing Congestion

Enter RFC2481 “A Proposal to Add Explicit Congestion Notification (ECN) to IP” which was superseded by RFC3168 with the same name. To assist in notifying the end-points, changes were made to the TCP and IP headers. First, two one-bit flags were added to the reserved field of the TCP header: bit 8 (CWR – Congestion Window Reduced) and bit 9 (ECE – ECN-Echo). Lastly, two flags were changed in the IP header in the differentiated services field: bit 14 (ECT) and 15 (CE). A table summarizing the changes is provided below.

During the synchronization phase of a connection between client and server, the TCP CWR and ECE flags work in conjunction to establish whether the connection is capable of leveraging congestion notification. In order to work, both client and server need to support ECN. To accomplish this, the sender sends a SYN packet with the ECE and CWR flags set, and the receiver sends back the SYN-ACK with only the ECE flag set. Any other configuration indicates a non-ECN setup.

So how does it work? Assuming an ECN-aware network, an oversimplification of the process looks like this: when a router detects congestion, rather than dropping packets destined to a receiver, it marks them with the CE flag in the IP header and delivers the packet to the receiver.

Prior to 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.

Implementation

To date, the adoption of ECN has been tepid. However, with the demand for lower latency applications from video to browsing there have been some heartening developments. Whereas Linux distributions default to passive ECN negotiation where ECN is available at the client’s request; Apple is moving forward to ECN enabled by default. Lastly, while ECN has been available since Windows 2008/Vista and disabled by default, Windows 2012 changes this by enabling it by default as part of the Data Center TCP implementation.

Summary

While there are real benefits in using congestion notification, its adoption is driven primarily by client request. Finally, there is still some risk of encountering routers which will mishandle ECN marked packets.