ECN stands for Explicit Congestion Notification algorithm. It is not a congestion control algorithm like slow start restart and AIMD. This algorithm has only one responsibility to inform the sender about congestion building at the routers. Hence, ECN is a congestion notification or congestion signaling algorithm. It informs the sender about congestion so that respective measures can be taken to avoid that.
ECN is Congestion Signaling Mechanism defined in RFC 3168. It came around in 1999 and went on to become finalized around in 2001. It uses two bits in the TCP header and two bits in the IP header. It marks the packets, where marking = flipping a bit in the headers.
=> Assume that X is sending an envelope to a person Z who is two houses away from him.
=> X passes the envelope to intermediary person Y.
=> Y will see if he is getting congested or not.
=> If Y is getting congested then he will mark the envelope with a cross mark with a pen
on one corner of the envelope and will pass it to the next person.
=> When Z receives the envelop, it observes the cross mark on the envelope
corner and understands that one of the intermediary person is getting congested,
=> Z will send an ACK to the sender X with the same
mark on ACK envelop. By seeing mark X will know about congestion.
ECN can be used with AQM algorithms. We have seen AQM algorithms, proactively drop the packets when the link gets congested. But what if instead of ‘dropping’ the packets, they can be ‘marked’, this would be wonderful. Since ECN doesn’t drop the packets, this avoids retransmissions. That’s why ECN algorithms are very popular today. Because the purpose is only to let the known sender that the router is getting congested, So why drop the packet for that when we can tell the sender this using ECN. Also dropping packets will not tell the sender about congestion immediately. It is very important for time-sensitive packets because their traffic is very low.
In order to use ECN mechanism; Sender, Receiver and Router ‘all’ must support ECN functionality. Currently, ECN is implemented in all operating systems, such as mobiles, servers, laptops, and even in intermediary devices such as routers. But it is disabled by default. The reason is not that there is something wrong with ECN but because ECN is deployed along with AQM algorithms. AQM is not so popular because of parameters configuration.
Recommended by RFC 3168: ECN must not be applied to TCP control packets. The authors have strongly recommended that ECN must not be applied on control packets. Examples of control packets are: SYN, SYN/ACK, ACK, FIN, RST, PSH, URG. So only data packets not be marked with ECN.
ECN bits in the TCP header:
The 2 bits have been taken from the reserved section. Now 4 bits are left reserved and 2 bits are taken up by the ECN. These two bits are CWR and ECE. Note the order in which they appear. We can’t change the order of these two flag bits. CWR is on the left and ECE is on the right.
- CWR: Congestion Window Reduced Flag
- ECE: ECE Echo
Since these are 2 bits. There are 4 possible combinations. Combinations are called codepoints here.
ECN Codepoints in the TCP header
| S. No. | CWR | ECE | Codepoint | Sent From | To |
|---|---|---|---|---|---|
| 1. | 0 | 0 | Non-ECN set up | any | any |
| 2. | 0 | 1 | ECN Echo | Receiver | Sender |
| 3. | 1 | 0 | Congestion window reduced | Sender | Receiver |
| 4. | 1 | 1 | ECN Setup | Sender | Receiver |
- [0 0] is non-ECN setup codepoint. This can be sent from any to any. When this codepoint is shared from X->Y then X is telling Y that it does not support ECN.
- [0 1] is ECN Echo codepoint. This is sent from receiver to sender. First when sender tells receiver that he supports ECN then receiver will tell sender about itself, whether he supports ECN or not. If receiver supports ECN then it will reply back with this codepoint. This codepoint is also used when receiver tells sender about congestion. So, this codepoint has two usage.
- [1 0] is CWR codepoint. This is sent from sender to receiver. This codepoint is used as an acknowledgment which is sent from sender to receiver. Sender tells receiver that he has reduced its congestion window size when it came to know about congestion.
- [1 1] is ECN setup codepoint. This is sent from sender to receiver. This codepoint is sent by the sender to the receiver telling that the sender support ECN.
ECN Negotiation:
- Step 1: Sender sends the SYN packet to the receiver with ECN set-up codepoint. ECN set-up means CWR=1 and ECE=1. Sender is telling receiver that it supports ECN. This information is always conveyed in SYN packet while establishing the TCP connection via 3 way handshakes. Now receiver has to reply back to sender its status about ECN.
- Step 2: If receiver is supporting ECN then it will echo back to the sender by using ECN-Echo codepoint. CWR=0 and ECE=1, it informs the sender that yes, receiver is also ECN enabled. Suppose if receiver is not supporting ECN then it will reply back CWR=0 and ECE=0. This is what the 4th codepoint indicates. This is non-ECN setup which means the entity is not ECN enabled. This codepoint can be shared by sender to receiver and vice-versa.
- Step 3: Now, the ECN information is being exchanged by the sender and receiver. Sender can ask for data from receiver now as usual.
But what if the sender and receiver both are supporting ECN and it has to mark the packet instead of dropping that. Router can’t read TCP header, it can only read IP header of the packet. So, 2 bits are used in IP header to inform the router about ECN.
ECN bits in IP header:
Router is the one who is going to run AQM and router is the one who is going to mark the packets. So, the router must know that sender and receiver are ECN enabled. Because of this purpose that routers can’t access TCP header, 2 new bits were added in IP header. See first row, the third field in IP header. There were 8 bits reserved for differentiated services. 2 bits out of them have been used for ECN codepoints.
The first bit is called ECT: ECN Capable Transport and the second bit is called CE: Congestion Experienced. Again there will be four codepoints, but these will be different from ECN codepoints used for the sender and receiver usage.
ECN Codepoints in IP header:
| S. No. | ECT | CE | Codepoint | Sent From | To |
|---|---|---|---|---|---|
| 1. | 0 | 0 | non-ECT | any | any |
| 2. | 0 | 1 | ECT(1): ECN Capable Transport | sender | receiver |
| 3. | 1 | 0 | ECT(0): ECN Capable Transport | sender | receiver |
| 4. | 1 | 1 | CE: Congestion Experienced | router | receiver |
- [0 0] means non-ECT. That means packet is not ECN supported, So there is no point of marking this packet. If there is congestion then this packet must be dropped instead of marking it.
- [0 1] is ECT(0) codepoints means that packet is ECT supported.
- [1 0] is ECT(1) codepoint, it also means that packet is ECT enabled. If a packet is ECT(0) or (1) then this packet will not be dropped by the router instead it will be marked.
- [1 1] is CE codepoint. When router is congested and packet is ECT enabled then router will mark this packet as CE. Router will flip the 0 bit of ECT codepoint and make it CE. It does not drop the packet, just marks it and transfers to the receiver.