Re: [LOOPS] How important is congestion detection

[Michael Welzl <[e-mail]>]

> On Jul 22, 2019, at 6:17 PM, Carsten Bormann <[e-mail]> wrote:
> 
> Sorry for typing a message from a heated BOF where I was representing a WG that needs a specific outcome…
> 
>>> Bob pointed out that some end host implementations today interpret CE as definite congestion events, while applying congestion detection to loss signals, so this conversion might be counterproductive.
>> 
>> The last sentence - I don't understand it (“interpret CE as definite… while applying detection to loss” - huh?). What does it mean? Or, maybe: what’s the issue here?
> 
> What I think Bob meant: An end-host noticing a loss might make its own determination (a.k.a. congestion detection) whether that is a reason to slow down or not.
> An end-host getting a CE might simply assume this is indeed congestion, and always slow down.  So, CE > loss, and a simple replacement of loss by CE worsens throughput.

Ok, thanks!  now I understand that the statement is indeed what I thought, but it still makes zero sense to me. See below:


>> I thought the whole point is to signal CE *as a replacement* for the loss that LOOPS repairs. So, then… ?
> 
> If CE > loss, replacing loss by CE is not enough, we need to vet the losses via a LOOPS-side congestion detection that is as good as the one as the end-host would do, or (preferably) better.

RFC 3168 says CE = loss. RFC 8311 finally allows us to diverge from this rule, which we used in RFC to state: “CE < loss”.
L4S of course also does “CE < loss”, albeit in much more elaborate ways.

However: "CE > loss” is truly weird to me - perhaps this IS now allowed by RFC 8311  :-D    but if it’s spec’ed then it must be an April 1 RFC.

What am I missing, Bob?

Cheers,
Michael