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

[Neil Spring]

On Fri, Feb 16, 2001 at 12:04:38PM -0800, Eric A. Hall wrote:
> A scenario where both ends of a connection suffer medium levels of
> congestion instantaneously and within a single RTT is unlikely at best, it
> is not at all common, to say the very least. Yet it is required in order
> for ECN to have enough data to be reliable, regardless of rwin (cwin is
> the real restrictor), regardless of the actual loss rates, and regardless
> of any other number. In short, you can use whatever numbers you want to
> (as long as loss is high enough to kill SQ), but the scenario of both
> end-points collapsing within a single RTT is improbable at very best.

Should all the acknowledgements in a window be lost,
which I agree may happen with some probability especially
with small windows, I would expect the sender to react
as if massive packet loss had occurred, and recover with
a timeout.  The sender then begins a congestion response.

(from the late-night message:)
> Although it would seem so on the surface, that's not necessarily the case.
> I think what you mean is that ECN *can* provide reliable congestion
> signalling if the TCP segments get through.

The absence of acknowledgement (whether or not it contains
an ECN-echo flag) is itself a congestion signal.  So,
it doesn't matter whether the ECN acknowledgements get
through, the sender will back off.  I see this as a core
lemma in the argument that ECN is reliable.  Similarly,
if data segments are lost, there are already mechanisms
in place for detecting and responding to the loss.

The absence of source quench is the absence of a congestion
signal.  If a source quench message is lost, the sender
will not back off, and will have to wait for another source
quench.  If the goal is to deliver congestion signals early
and quickly to avoid congestion before it becomes severe,
this seems like a strange architecture.

Let's say, arbitrarily, that the loss rate on the return
path is 50%.  That's enough that, should the TCP segments
get through (we're not choosing to drop packets), there's
a 50-50 chance that the source quench message will pass,
and the sender will slow down.  With an rwin of 8 packets
(I really don't care what the number is), yielding four
delayed ECN-echo-ing acknowledgements, the chance of
successful ECN delivery is 1-(1/2)^4 = 15/16.  And in
the uncommon 1/16 case, the sender will still back off,
albeit with a timeout and slow start response.

I agree that ECN may never be as prompt as the best case
for source quench.  However, I don't believe that the
difference matters significantly enough to warrant the
loss in reliability.  

-neil