[Ecn-sane] [Flent-users] [bbr-dev] duplicating the BBRv2 tests at iccrg in flent?

[Sebastian Moeller]

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.
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...

Best Regards
        Sebastian

On April 9, 2019 4:33:55 PM GMT+02:00, Neal Cardwell <ncardwell at google.com> wrote:
>On Tue, Apr 9, 2019 at 2:31 AM Sebastian Moeller <moeller0 at 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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/ecn-sane/attachments/20190409/3ab5a317/attachment.html>