Explicit Congestion Notification (ECN), Why isn't the notification done by the Router?

Question

Quoting from Wikipedia:

"When both endpoints support ECN they mark their packets with ECT(0) or ECT(1). Routers treat the ECT(0) and ECT(1) codepoints as equivalent. If the packet traverses an active queue management (AQM) queue (e.g., a queue that uses random early detection (RED)) that is experiencing congestion and the corresponding router supports ECN, it may change the code point to CE instead of dropping the packet. This act is referred to as "marking" and its purpose is to inform the receiving endpoint of impending congestion. At the receiving endpoint, this congestion indication is handled by the upper layer protocol (transport layer protocol) and needs to be echoed back to the transmitting node in order to signal it to reduce its transmission rate."

So, the congestion feedback mechanism is carried out in the transport layer (TCP) via receiving end sending segments with ECE flag set to 1. My question is, why doesn't the router that first experiences congestion just send, for instance, an ICMP message immediately back to the sender (I know that ICMP does not have a congestion option, however, can't it be simply implemented?) so that the sender can reduce its congestion window earlier? Why wait until the datagrams reach to the receiving end? What happens if the segments make it to the receiving end long enough to cause a burst transmission by the sender to lead to a bufferbloat (which might have been prevented by an early notification) so that other connections on the router experience high latency and jitter even if it may be for a short period of time?

It might be the case that the beneficial effect of this on the network is not worth the effort and the reason why the receiving end is the one that does the echoing of the congestion might be because the router can't bother preparing control messages in an environment in which many connections are regulated. However, I cannot find any sources on this topic.

Additionally, I first thought that maybe the packet needs to go through all the routing nodes to make clear the nodes that are going through congestion, however, there is not an information option that keep tracks of individual nodes in neither of the frame, datagram, and segment header fields. Another reason I thought why the segments make it to the receiving end to send congestion feedback rather than being sent directly by the router is keeping the congestion control on the transport layer (specificially TCP) but internet layer (e.g. IPv4) also supports congestion information via a 2 bit ECN field, which makes me question this reason. I am not sure if my reasonings make practical sense, though.

Answer 1

My question is, why doesn't the router that first experiences congestion just send, for instance, an ICMP message immediately back to the sender (I know that ICMP does not have a congestion option, however, can't it be simply implemented?)

Such a mechanism did exist as early as 1980 – it was the ICMP "Source Quench" message. (It got removed in 1995; think I remember reading posts about it having an issue of not being precise enough and subject to spoofed "Source Quench" packets.)

Therefore, there already have been discussions about ECN vs Source Quench:

• According to https://wiki.geant.org/pages/releaseview.action?pageId=121340501:

  The biggest problem with ICMP Source Quench are:

  • that the mechanism causes more traffic to be generated in a situation of congestion (although in the other direction)
  • that, when ICMP Source Quench messages are lost, it fails to slow down the sender.

• According to https://personal.utdallas.edu/~kxs028100/courses/Papers/explicit-congestion-notification.pdf:

  Source Quench messages are rarely used, in part because they can consume network bandwidth in times of congestion [...] In the draft, Source Quench messages are criticized as consuming network bandwidth, and as being both ineffective and unfair [...] This use of Slow-Start combined with a small slow start threshold makes the use of Source Quench particularly unattractive for large-window TCP connections in high-speed environments.

• According to https://end2end-interest.postel.narkive.com/PlR0pX2J/e2e-ecn-vs-source-quench:

  • ECN takes advantage of the destination being able to reach the source (source quench may not, as ICMP is not end-to-end).
  • ECN takes advantage of the TCP destination being able to retain state to retransmit the ECN signal (asking a router to retain state for source quench retransmission is problematic for a number of reasons).
  • ECN introduces no new traffic (a conservative "do no harm" property, as adding traffic to deal with too much traffic has the potential to make things worse).