To: braden@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