Working of Explicit Congestion Notification

Explicit Congestion Notification (ECN) is an extension to the Internet Protocol and to the Transmission Control Protocol. It is defined in RFC 3168. It 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.            

In this article, we will see the working of Explicit Congestion Notification.

Step 1: Assuming that ECN negotiation is done between sender and receiver. The sender and receiver have informed each other that they support the ECN algorithm, in their initial handshake. 

Now sender is sending a data packet to another side. It will set ECT in the IP header to inform the router that both sender and receiver are ECN enabled and they have spoken to each other. On the contrary, if ECN negotiation is failed then the sender will set the Non-ECT codepoint in the data packet. The sender is sending ECT, it can be ECT(0) or (1) because both are the same. This is to tell the router that if congestion occurs then don’t drop this packet, instead mark this and forward.

Step 2: In the below picture, the router is using AQM algorithm, see the queue at the bottom. When this packet is arrived, AQM algorithm runs and tells the router that drop this packet. But wait a minute, the ECT bit is on in the IP header, the router can’t drop this packet. So, the router will change ECT to CE in the IP header. CE indicates that the router is experiencing congestion. CE is sent from router to receiver. Only the router has the authority to change ECT to CE, no one else can do that. The packet came with ECT and going with CE, the IP header is modified.

ECT [0 1] -> CE [1 1]

Step 3: When a packet is received at the receiver. The receiver sees the CE mark in the IP header and understands that router is congested. Now receiver has the responsibility to inform the sender about congestion. So, the receiver now will mark this congestion information in TCP header and not in IP header, because some intermediary devices may temper with IP header. 

The receiver marks the ECE bit in the TCP header. Note that the ECE bit is used when ECN negotiation is taking place. The receiver uses this ECE for two purposes. The sender avoids this confusion by simply checking the context of the packet. Because when SYN/ACK bits are on, then the ECE bit is indicating ECN negotiation, not the congestion. But right now, the ECE bit is on in the ACK packet, so the sender knows that router is congested.

Step 4: Now the CE mark reaches the sender. The sender will reduce its congestion window by half. If the sender is using NewReno then cwnd will be reduced by 50%. But, what if the ACK packet bringing CE information gets dropped due to congestion and doesn’t reach the sender. So, the receiver will keep on sending this CE flag in subsequent packets until it gets confirmation from the sender. If one or more ACK are dropped then also at least one ACK will reach the sender and inform about the congestion in the link. The receiver is configured in such a way that it will keep on sending CE until it reaches to sender.

Step 5: Now, CE is reached to sender and sender has reduced cwnd by half. Now sender has to inform the receiver that it has reduced the congestion window to avoid congestion. The sender will set the CWR flag in the TCP header along with the ECT in the IP header. When a packet arrives at a router, then if the router feels the congestion it can market ECT to CE. When the packet reaches the receiver then it will get a CWR flag and stop sending the CE flag to the sender in subsequent ACK packets. 

So, flags in the IP header and TCP header work together. 

Now suppose that sender gets the CE mark and reduced the cwnd and sent CWR flag to the receiver. Till the time CWR reaches the receiver, the receiver will keep on sending CE flags to the sender. As per the rule, the sender should reduce the cwnd again by half every time it receives CE, but it will not happen. The sender will reduce the congestion window by half only once. It will not reduce it for every CE. The sender will check if the CE belongs to the current congestion window or not. If CE does not belong to the current congestion window, that means this CE is a fresh CE, so it will reduce the cwnd. This feature is the same as NewReno cwnd reduction during a fast recovery phase.

Step 6: Now receiver has received the CWR from the sender. So, it will stop sending CE in subsequent ACK packets. 

Linux Kernel Command Line:

To check the ECN setting:

=> $ sysctl net.ipv4.tcp_ecn

=> Expected outcome:

=> $ net.ipv4.tcp_ecn = 2

=> To Disable the ECN:

=> $ sudo sysctl -w net.ipv4.tcp_ecn=0

=> Expected outcome:

=> $ net.ipv4.tcp_ecn = 0

Possible values are:

=> 0 Disable ECN.  Neither initiate nor accept ECN.

=> 1 Enable ECN when requested by incoming connections and also request ECN on outgoing connection attempts.

=> 2 Enable ECN when requested by incoming connections but do not request ECN on outgoing connections.

=> Default: 2

Method:

• The sender sets the ECT flag in the IP header in the packet and forwards it to the router.
• Router converts ECT to CE if congestion is experienced otherwise not.
• The receiver sees the CE and sets the ECE flag in the TCP header in the ACK packet and forwards it to the router.
• Now, the router can’t fiddle with the ECE flag because it is in the TCP header and the router can only access the IP header.
• When the sender receives CE, it sends CWR in TCP header and ECT in IP header and forwards to router.
• When the receiver gets CWR, it stops sending CE in TCP packet in subsequent ACK packet.