Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs

[Sebastian Moeller <[e-mail]>]

More below....

On November 7, 2019 6:00:38 PM GMT+01:00, Jonathan Morton <[e-mail]> wrote:
>> On 7 Nov, 2019, at 6:47 pm, Sebastian Moeller <[e-mail]>
>wrote:
>> 
>> [SM] I guess it is worth repeating that the obvious solution to all
>of these challenges would be to fix the actual root cause of the issue,
>instead of trying to paper over the symptoms. If L4S would not try to
>make the ECT(1) and the CE codepoint do the work that would require 2
>independent bits neither issue 16 nor 17 would exist in the first
>place. I wonder how, after having eloquently argued for the requirement
>of strict isolation/separation between tcp-friendly and dctcp-style
>traffic, one could have converged on this clearly sub-optimal approach.
>
>
>> I have read the discussion of the alternatives in the L4S draft and
>while clearly none of the options is perfect, most have less
>undesirable side effects on normal traffic than the admittedly clever
>'overload ECN codepoints' variant that currently is being pushed.
>
>I'm reasonably sure that most if not all of L4S' purported goals can be
>met, without the need for these complex workarounds, by switching to
>SCE-type signalling.  If it is then still desired to implement a
>distinct traffic class for L4S traffic, that can be done by defining a
>PHB and assigning a DSCP to it.
>
>This isn't exactly rocket surgery; the KISS principle applies.
>
> - Jonathan Morton


Yes, not redefining what CE is supposed to mean, and using a new effectively unambiguous  method to signal a milder slow down command to interested listeners elegantly will remove the L4S side effects on normal traffic. At Wich point the requirement for strict isolation moves from essential to nice to have for L4S to achieve it's goals. I am sure there are workable solutions for L4S that are good enough to still merits the experiment for interested parties. IMHO the value of L4S will not be generically end 2 end anyway but will mostly consist in allowing to build dedicated low latency routes between paying parties and in that deployment model PHB/dscps should be genuinely feasible. I have high hopes that the IETF will in the end make the right decision that will reliably allow the L4S experiment to be performed in the open internet without putting normal traffic into potential risk, after all the E in IETF stands for engineering not experiments...

Sebastian