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

[Neil Spring]

On Fri, Feb 16, 2001 at 10:30:03PM +0000, Jon Crowcroft wrote:
> 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...

agreed.  I was too lazy to choose a reasonable number,
didn't want to deal with the 30% number Eric used, and it
didn't occur to me that 50% loss was catastrophic. ;)

Let's say 5% instead.  

There's 5% chance the SQ won't get through, but only a
1-(0.05)^4 = .00000625 = 0.000625% chance none of the ECN
acknowledgements will.   In 5% of SQ'd cases, the sender
won't slow down.  Even in the miniscule fraction of times
the sender doesn't 'reliably' get the explicit congestion
signal, the sender still gets an implicit congestion signal
and slows down.

Eric A. Hall wrote:
> The only scenario where ECN provides reliability is one in which
> congestion is slight, or where it is known to be pending, but which has
> not yet triggered a cwin fallback (due to late ACKs). Neither of those
> situations demand great degrees of reliability. In both of those cases it
> is reasonable to expect that SQ will not be discarded. 

Is ignoring 5% of congestion signals a reasonable price
to pay to shave a fraction of an rtt off the time
to deliver them?

-neil



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


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