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

[Sebastian Moeller <[e-mail]>]

Hi Ingemar,

more below in-line...


> On Jun 17, 2020, at 18:27, Ingemar Johansson S <[e-mail]> wrote:
> 
> 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.

	The ACM codel paper is from 2012... And fq_codel was deployed well before the matching RFC was published by the IETF. By virtue of being rdf3168 compliant deploy first standardize later was a viable way forward for codel/fq_codel. If only L4S would have selected an incrementally roll-out-able path, we would not be here right now.


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

	[SM] -ENOTIMEMACHINE, at the current time, L4S is not standardized and hence there is neither a known working implementation (tested internet wide) nor an accepted standard to work against. 

> 
> Issue #16 is pretty much a consequence of the above timeline,

	[SM] That seems wishful thinking to me. #16 is a direct consequence of L4S decision to violate precedence and redefine the meaning of CE, plain and simple. The only thing where fq_codel got involved is in being a pretty good all around qdisc for tcp-friendly traffic and hence seeing decent deployment in Linux (and as I might add in Macs as it seems). Yes, that attractiveness has increased L4S' predicament, but it is NOT the root cause, let us please not confuse this here.


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

	I note that for the longest time rfc3168 compatibility was on the todo list of L4S. Only when team L4S was trying to get that requirement dropped* instead of actually tackling the issue the topic came to the fore on the tsvwg mailing list and meetings.

Best Regards
	Sebastian


> 
> /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]