Re: [tsvwg] path forward on L4S issue #16

[Sebastian Moeller <[e-mail]>]

Hi David,

> On Jun 17, 2020, at 19:25, Black, David <[e-mail]> wrote:
> 
> Ingemar,
> [posting as an individual]
> 
>> With that in mind, shouldn't it have been on the table to consider the
>> possible future existence of L4S in the different realizations of fq-codel
>> (and OpenWrt) development?
>> 
>> Issue #16 is pretty much a consequence of the above timeline, I see that
>> there was ample time to react but that reaction did not come until 2019 (or
>> late 2018?), was any assessment done as regards to how L4S could coexist
>> with fq-codel before the debate started in TSVWG?.
> 
> The question seems relevant in the other direction - shouldn't L4S have taken coexistence RFC 3168 ECN more seriously in that timeframe?
> 
> To my recollection, the overall L4S approach to this topic in that timeframe is captured by this text that is still in the l4s-id draft (Appendix B):
> 
>      1.  It is quite unusual to experience queuing at more than one
>          bottleneck on the same path (the available capacities have to
>          be identical).

	[SM] Which again is consisten with my hypothesis that L4S was really only ever intended, designed, and tested for a single use-case, short RTT, low hop-count downlink paths from content/CDNs to consumers. In that context the above assessment, while not strictly correct, is a decent fit for the common condition. 
	I have been arguing for some time now, that L4S should be tested for more realistic internet-wide conditions, BEFORE its roll-out is approved by the IETF to demonstrate its fitness for that novel use-case, it was never optimized or even properly tested for. And I am truly puzzled that the L4S camp and all the voices that supported ECT(1) as input just recently keep staying silent about that question.

Best Regards
	Sebastian



> 
> Thanks, --David
> 
>> -----Original Message-----
>> From: tsvwg <[e-mail]> On Behalf Of Ingemar Johansson S
>> Sent: Wednesday, June 17, 2020 12:27 PM
>> To: Rodney W. Grimes; Jonathan Morton; Sebastian Moeller
>> Cc: Ingemar Johansson S; [e-mail]
>> Subject: Re: [tsvwg] path forward on L4S issue #16
>> 
>> Hi
>> 
>> OK, I see that this discussion is only going in circles, nearly giving up on
>> this.
>> So far I see only one firm evidence that RFC3168 AQMs are deployed and
>> enabled and these are related to the OpenWrt project, manifested in a few
>> upgradeable devices (and some not upgradeable) that can be bought in retail
>> stores. The rest is unconfirmed.
>> 
>> This leads me to a look at the time line for L4S and how it correlates with
>> the fq-codel work and as a consequence the OpenWrt project.
>> 
>> 1) L4S was first brought up late 2013-early 2014 in TSVWG. The ECN
>> experimentation draft (now RFC8311) was a draft -00 in sept 2016 and I know
>> that this draft was preceeded by a discussion in TSVWG before that
>> 
>> 2) The FQ-codel work was finalized early 2016, not quite a perfect overlap
>> with the 00 version of the ECN experimentation work but definitely an
>> overlap with the preceeding L4S and dualQ discussions and references to the
>> RITE project which happened around 2014-2015.
>> 
>> With that in mind, shouldn't it have been on the table to consider the
>> possible future existence of L4S in the different realizations of fq-codel
>> (and OpenWrt) development?
>> 
>> Issue #16 is pretty much a consequence of the above timeline, I see that
>> there was ample time to react but that reaction did not come until 2019 (or
>> late 2018?), was any assessment done as regards to how L4S could coexist
>> with fq-codel before the debate started in TSVWG?.
>> 
>> /Ingemar
>> 
>> 
>> 
>> 
>>> -----Original Message-----
>>> From: Rodney W. Grimes <[e-mail]>
>>> Sent: den 17 juni 2020 16:19
>>> To: Jonathan Morton <[e-mail]>
>>> Cc: Ingemar Johansson S <[e-mail]>; Ingemar
>>> Johansson S <ingemar.s.johansson=[e-mail]>;
>>> [e-mail]
>>> Subject: Re: [tsvwg] path forward on L4S issue #16
>>> 
>>>>> On 17 Jun, 2020, at 4:20 pm, Ingemar Johansson S
>>> <[e-mail]> wrote:
>>>>> 
>>>>> Given all the input sofar my impression is that It is difficult to say
>> how
>>> serious issue 16 really is.
>>>>> Surely there is a possibility that L4S flows can get an potentially
>> unfair
>>> advantage over a congested node that is  RFC3168 capable (and ECN
>>> enabled). The question is here when things are deemed as unfair and when
>>> starvation is a fact, opinions differ.
>>>>> Another question is to how large extent there will be legacy RFC3168
>> ECN
>>> capable (and ECN enabled ) bottlenecks that will "never" be updated or
>>> replaced. This question is currently difficult to answer.
>>>> 
>>>> When questions such as these are "difficult to answer", the correct
>> design
>>> choice is to assume pessimistically, unless and until the question can be
>>> answered more definitively.  Therefore, the L4S design must account for
>> the
>>> possibility of RFC-3168 AQMs in the network, and actively avoid unfairness
>> in
>>> that case.
>>>> 
>>>>> Yet another aspect is how successful it will be to implement RFC3168
>>> bottleneck detection e.g. in TCP Prague, I am quite confident that these
>> will
>>> not always be successful.
>>>> 
>>>> I think we can safely say that the detection mechanism currently in TCP
>>> Prague is not successful.  David Black also pointed out that this would
>> always
>>> be a fragile mechanism, difficult to implement correctly, and thus likely
>> to be
>>> implemented wrongly by other transports even if a workable version was
>>> somehow developed.
>>>> 
>>>> With these facts established, I do not see how L4S can proceed without
>>> changing the signalling mechanism it uses.  This is something we
>> intuitively
>>> realised more than a year ago, when the SCE project was started, but now
>>> we have actual evidence to back up that intuition.
>>> 
>>> And I would like to add to that, this is evidence the L4S team itself
>> should of
>>> identified, characterized and docuemented years ago.  I see no reason that
>> it
>>> took team SCE to disect the failure modes of L4S so that they could be
>>> addressed.
>>> 
>>> IMHO the fact that L4S is years into the process and only done positive
>> test
>>> results presentations leads one to believe it is simply being pushed
>> through
>>> the process with little to no care about the actual internet community.
>>> 
>>> The proponents seem to genuily be a) unwilling to acknowledge that there a
>>> problems they should be working on, and b) presenting that L4S is ready
>> for
>>> internet deployment inlight of the fact that data showing clear and
>> present
>>> problems exist.
>>> 
>>>> - Jonathan Morton
>>> --
>>> Rod Grimes
>> [e-mail]
>