<div dir="ltr"><div dir="ltr">On Tue, Apr 9, 2019 at 2:31 AM Sebastian Moeller <<a href="mailto:moeller0@gmx.de">moeller0@gmx.de</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
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.<br>
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. <br>
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.<br>
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.</blockquote><div><br></div><div>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.</div><div><br></div><div>neal</div><div><br></div></div></div>