To: mallman@lerc.nasa.gov
cc: kkrama@att.research.com
Subject: Re: ECN vs. Source Quench
Date: Thu, 20 Nov 1997 09:45:31 PST
From: Sally Floyd <floyd>

>    A quick comment...  Why not use a source quench type mechanism
>rather than an ECN bit that is echoed back to the sender?  

The 1994 ECN paper was written describing both source quench and ECN
bits as possible mechanisms.  The Source Quench style has the
disadvantage that it adds traffic in the reverse direction in times of
congestion.  My own assumption is that, as RED gets deployed in routers
giving feedback about incipient congestion, and as levels of statistical
multiplexing get higher so that each individual flow is contributing a
smaller **fraction** of the load at each congested link, it becomes
less and less important to push mechanisms that get feedback back to
the source in less than a RTT.  (ECN gets feedback to the source sooner
than packet drops do, but it still takes a RTT.)

I would agree that there are special cases, mainly high-bandwidth flows
over very-long-delay satellite links, where there might be significant
benefit to shortening the feedback loop (as would be done with Source
Quench).  This strikes me as a special, non-typical case, that might
require special mechanisms.  And there is the possible drawback with
Source Quench-style mechanisms that they take the receiver out of the
loop.  (The TCP receiver now plays a rather passive role in terms of
congestion control decisions; receivers in multicast applications are
much more active in this regard.  Thus, the ECN bit is likely to be
much more useful than Source Quench-style mechanisms would be for new
congestion control mechanisms, I think.)

- Sally