On Tue, Apr 9, 2019 at 2:31 AM Sebastian Moeller <moeller0@gmx.de> wrote:

I guess I was too subtle.... The following is in no way incompatible with what I wrote. The point I wanted to make is that redefining CE without also introducing an equivalent of 'stop hard, ASAP' is an incomplete solution. Once you introduce the missing signal the SCE proposal is a better fit than L4S.
Also both BBR and L4S both aim at basically ignoring drops as immediate signals, both for good reasons like better throughput on links with spurious drops and some reordering tolerance.
IMHO it is wonderfully absurd in that light to try to basically shoehorn a dctcp style CE-marker into the internet, which does not allow to carry as quickly a stop hard signal as tcp-friendly ECN does today. To repeat the argument is not against finer-grained load information from the bottleneck, but rather against doing only half the job and falling short of solving the problem.
The rationale below would maybe make sense if all the internet's bottlenecks would talk dctcp style ECN, but until then the rationale falls apart.

OK, I think I now understand what you are suggesting. I can see the potential value of having both a DCGCP/L4S/SCE-style signal and a RFC3168-style signal. In your previous e-mail I thought you were arguing for a pure RFC3168-style approach; but if the proposal is to have both styles, and that's what gets deployed, that sounds usable AFAICT.

neal