Hi Alex,
The issue with ECN is an extensive one.
The basic idea is this (intentionally somewhat simplified): Routers may be configured with congestion avoidance mechanisms such as Random Early Detection (RED) to prevent their packet buffers from overfilling and then dropping multiple packets en-masse till they get emptied again. The RED family of mechanisms tries to prevent this by randomly dropping certain packets long before the packet buffers are full, and increasing the probability of the drops as the packet buffers get more and more full. With TCP, a dropped packet/segment in a TCP session will ultimately result in the sender slowing down as it will be waiting for an acknowledgement for the lost packet that will never come, and after a while, it will retransmit the data. RED drops the packets randomly to possibly affect multiple TCP streams but not all at once - that would result in all of them slowing down, and all of them getting back to speed, resulting into oscillations of link usage. This phenomenon is called TCP Global Synchronization, and you can Google for many explanations and demonstrations of it.
ECN tries to achieve the same goal of throttling down a sender without dropping its packets. What it does is this: Instead of dropping the TCP segment, the router will mark the entire packet as a packet that would otherwise have been dropped, but still send it on its way. When the receiver receives such a packet, it will process it (so the data does not get lost), and based on the special marking, it will also understand that this packet contributed to a congestion somewhere along the way, and so the sender needs to be informed to slow down. Therefore, when the receivers sends back an acknowledgement, it will also set a special flag in this acknowledgement saying to the sender: "You need to slow down because you are contributing to a congestion in the network". Upon receiving this acknowledgement, the sender will temporarily reduce the data transfer speed.
I personally consider ECN to be preferable to simply losing the packets (and there are equally subject matter experts who dislike ECN), but there are several pieces to the puzzle which make its deployment more complex. First of all, ECN needs to be supported by end hosts as well as the routers in the network infrastructure. If the end hosts do not negotiate the use of ECN for their TCP sessions, routers will not use ECN marking, and drop packets instead, even if they are configured to use ECN themselves. Vice versa, if the end hosts support ECN but routers do not, the routers will continue dropping the packets instead of forwarding them with the special marking.
Second, routers currently only use the ECN marking if they are explicitly configured for RED or WRED (Weighted RED) with ECN support. To my best knowledge, outside of explicit RED or WRED configuration (which is off by default) with an explicit permission to use ECN, routers will not use ECN for any to-be-dropped packet.
Third, if your offices are interconnected by MPLS, ECN would very likely not be used at all because MPLS labels have very limited options when it comes to QoS markings including ECN. There have been various approaches proposed for the ECN support in MPLS, but the true adoption of any of them seems to be practically nonexistent.
The bottom line is: It is unclear whether you would benefit from enabling the ECN support on your end hosts. Doing so will not cause any harm, but the added value may be negligible and not worth the effort.
ECN is quite a topic with many contradictory opinions - I hope that this thread will be joined by multiple friends here at CSC to provide their own view and input.
Feel welcome to raise any questions, comments, or concerns!
Best regards,
Peter
