[e2e] Can feedback be generated more fast in ECN?

[Sally Floyd]

For more recent (1997 and 1998) discussions of reasons not to choose
Source Quench as the default congestion notification mechanism,
you would read the two notes "ECN vs. Source Quench" and "Addendum
on Source Quench" listed at the bottom of the ECN web page at
"http://www.aciri.org/floyd/ecn.html".  I am also appending the
second of these two notes below.

- Sally

Addendum on Source Quench:

> To: braden at ISI.EDU
> Subject: Re: Source Quench
> Date: Thu, 07 May 1998 11:20:27 PDT
> From: Sally Floyd <floyd>
> 
> ...
> 
> These are all of the reasons that I can know for not doing
> Source Quench:
> 
> (1) It is not a general solution, particularly for multicast.  Some
> connections have receiver-based congestion control instead of
> sender-based congestion control.  (And in addition, one would not like
> to have a "Source Quench" implosion in a multicast tree.)
> 
> (2) Source Quench packets can be dropped, so they are not reliable.  If
> data packets in the forward direction carrying the CE (Congestion
> Experienced) bit are dropped, then the application detects packet drops
> and uses packet drops as an indication of congestion, so this is a
> robust indication of congestion.  And there are robust mechanisms that
> receivers can use to inform senders that a packet has been received
> with the CE (Congestion Experienced) bit set.
> 
> (3) Even if well-done, Source Quench packets add traffic in the
> reverse direction on what might be a congested path.
> 
> (4) While there are some applications/environments where it might be
> highly advantageous for the sender to receive some indication of
> congestion without having to wait a roundtrip time, this is not the
> common case.  This is particularly true for a environment with active
> queue management, which is the kind of environment that is most likely
> to be using some new form of congestion indication.
> 
> - Sally