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

[Jon Crowcroft]

um,

if you have 50% loss, why woukld someone have waited for anything

this imples that the load moved from 100% to 200% in one RTT...

too late for anything random and early whether explicit, or source
quench...

In message <20010216134125.A5461 at cs.washington.edu>, Neil Spring typed:

 >>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

 cheers

   jon