<html><head></head><body>Sorry for being to vague the first time around. I note, as Jonathan did, that the SCE RFC has basically the desired properties, it still uses CE with the generally accepted meaning, and basically uses the ECT(1) codepoint the same way as current dctcp uses the CE mark, that way it has the backward compatibility with old AQMs that only use CE as drop equivalent, the desired fiber grained pulse-modulated load signal from the bottleneck, and the "stop harder" signal that I am advocating for here.<br>Basically the only thing that the L4S approach adds is some incomplete isolation between tcp-friendly and L4S flows. Incomplete as ECT(1) only can differentiate non-marked packets (all CE-marked packets look the same in regards to the two but ECN field); which has two consequences, L4S will treat all CE marked packets as belonging to an L4S flow (which is probably a) benign and b) L4S's problem) and it will not respond timely enough if the marking AQM is not of the AQM kind. I note that with L4S approaching experimental status, basically no AQM in the wider internet will be L4S-friendly, so the latter incompleteness seems IMHO rather hostile...<br><br>Best Regards<br> Sebastian<br><br><div class="gmail_quote">On April 9, 2019 4:33:55 PM GMT+02:00, Neal Cardwell <ncardwell@google.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<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>
</blockquote></div><br>-- <br>Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>