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