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 <ncardw...@google.com>
wrote:
>On Tue, Apr 9, 2019 at 2:31 AM Sebastian Moeller <moell...@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._______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org
