When ECN is successfully negotiated, an ECN-aware router may set a mark in the IP header instead of dropping a packet in order to signal impending congestion.
[1][2][3] As of 2015[update], measurements suggested that the fraction of web servers on the public Internet for which setting ECN prevents network connections had been reduced to less than 1%.
Because the CE indication can only be handled effectively by an upper layer protocol that supports it, ECN is only used in conjunction with upper layer protocols, such as TCP, that support congestion control and have a method for echoing the CE indication to the transmitting endpoint.
The first, ECN-Echo (ECE) is used to echo back the congestion indication (i.e., signal the sender to reduce the transmission rate).
This allows intermediate routers that support ECN to mark those IP packets with the CE code point instead of dropping them in order to signal impending congestion.
When an endpoint receives a TCP segment with the ECE bit it reduces its congestion window as for a packet drop.
This effect is most drastic when the TCP connection has a single outstanding segment,[9] when it is able to avoid an RTO timeout; this is often the case for interactive connections, such as remote logins, and transactional protocols, such as HTTP requests, the conversational phase of SMTP, or SQL requests.
Effects of ECN on bulk throughput are less clear[10] because modern TCP implementations are fairly good at resending dropped segments in a timely manner when the sender's window is large.
Use of ECN has been found to be detrimental to performance on highly congested networks when using AQM algorithms that never drop packets.
[8] Modern AQM implementations avoid this pitfall by dropping rather than marking packets at very high load.
ECN support can be enabled using a shell command such as netsh interface tcp set global ecncapability=enabled.
FreeBSD 11 included CoDel, PIE, FQ-CoDel and FQ-PIE queuing disciplines implementation in ipfw/dummynet framework with ECN marking capability.
[30] DCTCP modifies the TCP receiver to always relay the exact ECN marking of incoming packets at the cost of ignoring a function that is meant to preserve signalling reliability.
This makes a DCTCP sender vulnerable to loss of ACKs from the receiver, which it has no mechanism to detect or cope with.
[31] As of July 2014[update], algorithms that provide equivalent or better receiver feedback in a more reliable approach are an active research topic.