ECN+, ECN+/Wait, ECN+/TryOnce and Alternative Backoff with ECN (ABE)

ECN algorithm did not allow to set ECT flag on control packets like SYN, SYN/ACK, ACK, URG, FIN, etc. ECN+ algorithm and its extensions basically extend the ECN idea and allow ECT flag on SYN/ACK packet. If ECN is permitted on SYN packet then it might be misused and attackers can launch an SYN flood attack on the server and eventually Denial of Service attack is made. Imagine an attacker sending an SYN packet with ECN enabled, then the server accepts it and sends SYN/ACK packet and the attacker doesn’t respond to it to complete the 3-way handshake. In the interim, resources and time of server will be wasted which could be used for genuine users. If such SYN packets are sent in large numbers, then the server is under DOS attack. Also, the network will become much congested because the router will not drop these packets due to ECN enabled flag.

There are four extensions of ECN:

• ECN+
• ECN+/wait
• ECN+/TryOnce 
• Alternative Backoff with ECN (ABE)

ECN+:

This is the direct extension of the original ECN algorithm. It allows one of the control packets to use the ECN flag. It is legitimate to not permit SYN packets to use the ECN flag due to the possibility of attacks. But why not allow SYN/ACK? ECN+ basically allows SYN/ACK packet to use ECN flag. It says the second packet of 3 way handshake must not be dropped cause it will cause resources wastage if dropped. The server has to wait for one RTO time and overhead of retransmitting it. Please note that it didn’t permit any other control packet (except one: SYN/ACK) to use ECN.

Working of ECN+:

Step 1: Sender sends the SYN packet with ECN set up. Sender is informing the server that it supports ECN.

Step 2: Server accepts the connection request and replies back SYN/ACK packet with ECN confirmation. This packet contains ECT, it informs the router that it must mark the packet if congestion is experienced instead of dropping.

Step 3: The router feels congestion and hence marks the SYN/ACK  packet with the CE flag.

Step 4: The sender will send ECN Echo in the ACK packet to inform the server that the router is congested.

Step 5: Server gets the congestion information and reduces its cwnd to 1, not to the initial value of 10 because the router is congested. Now the server will send one data packet with ECT.

ECN+/wait:

It is an extension of ECN+. It is suitable for mild to moderate level congestion.  SYN/ACK packet is permitted to carry ECT(0) or ECT(1) in the IP header. It means the SYN/ACK packet can get marked by the router if there is congestion. ECN+ is a server-side mechanism.

When congestion information is received to a server, it will strictly decrease its congestion window to 1, not to the initial congestion window. Because there is congestion on the path from server to sender. So, instead of starting with an initial congestion window of 10, it starts with 1.

Working of ECN+/wait:

If an ACK arrives with an ECN-Echo, the server reduces the congestion window to 1 segment and waits for one RTT before sending the data packet. 

Step 1: Sender sends the SYN packet with ECN set up. Sender is informing the server that it supports ECN.

Step 2: server accepts the connection request and replies back SYN/ACK packet with ECN confirmation. This packet contains ECT, it informs the router that it must mark the packet if congestion is experienced instead of dropping.

Step 3: The router feels congestion and hence marks the SYN/ACK packet with the CE flag.

Step 4: The Sender will send ECN Echo in ACK packet to inform the server that the router is congested.

Step 5: The Server gets the congestion information and reduces its cwnd to 1, not to the initial value of 10 because the router is congested.

Step 6: The Server will wait for 1 RTT time period to let the router come out of the congestion state. Then, the server will send one data packet with ECT.

 ECN+/TryOnce:

It is an extension of ECN+. It is suitable for high levels of congestion. If an ACK arrives with an ECN-Echo, the server reduces the congestion window to 1. Besides, it first retransmits the SYN/ACK without ECT and confirms that the network is not heavily congested

Working of ECN+/TryOnce:

Step 1: Sender sends the SYN packet with ECN set up. Sender is informing the server that it supports ECN.

Step 2: server accepts the connection request and replies back SYN/ACK packet with ECN confirmation. This packet contains ECT, it informs the router that

 it must mark the packet if congestion is experienced instead of dropping.

Step 3: The router feels congestion and hence marks the SYN/ACK packet with the CE flag.

Step 4: the sender will send ECN Echo in the ACK packet to inform the server that the router is congested.

Step 5: server gets the congestion information and reduces its cwnd to 1, not to the initial value of 10 because the router is congested.

Step 6: now the server will not sit quietly for 1 RTT time. Instead, it will check if the network is still heavily congested or not. So, it will send SYN/ACK once again without the ECT flag. If network is still congested, then this packet will get dropped and the server will not get an ACK for that, its RTO timer will expire. 

Step 7: once the server’s timer expires, it concludes that the network is still congested, so it waits for   3 seconds now. After that, it again sends the SYN/ACK packet without ECT to check if the network has come out of the congestion state. This will continue until the network comes out congested and the server gets the ACK for this duplicate packet.

Step 8: when an ACK comes for this duplicate SYN/ACK packet, the server knows that network is no longer congested, so now it will send 1 data packet, cause its congestion window is reduced to 1.

Alternative Backoff with ECN:

It differentiates the congestion response for a marked packet and dropped packet. It is mentioned in RFC 8511. Backoff is in the context of the congestion window. It says the ECN marked packet should not be treated as dropped and thus give a less aggressive response to the marked packet. The reduction in congestion window should be lesser than the case when packets are dropped. 

ECN signals are treated the same as ‘packet drop’ signals by the TCP senders. This behavior was recommended in RFC 3168 (the original ECN mechanism). ABE defines an alternative behavior for ECN marked packets. Because ‘ECN marked’ packets are not ‘actually’ dropped. So the congestion window reduction can be less aggressive. Recommendations by RFC 8511 for congestion response by a TCP Sender using ABE: 

• For CUBIC: multiply cwnd by 0.85 if the packet is ECN marked, 0.7 if it is dropped.
• For Reno: multiply cwnd by [0.7, 0.85] if a packet is ECN marked, 0.5 if it is dropped.