Re: [tsvwg] plan for L4S issue #29

[Sebastian Moeller <[e-mail]>]

Hi Ingemar,

more below in-line.

> On Sep 30, 2020, at 12:44, Ingemar Johansson S <[e-mail]> wrote:
> 
> Hi Sebastian
> Please see inline, I answer where I find answers meaningful. I  skip the parts where I suspect that we will only go into a discussion that goes in circles, we've had enough of these already.

	[SM] I am somewhat disappointed that you basically choose to ignore the meat of my argument.


> 
> /Ingemar
> 
>> -----Original Message-----
>> From: Sebastian Moeller <[e-mail]>
>> Sent: den 30 september 2020 11:41
>> To: Ingemar Johansson S <[e-mail]>
>> Cc: [e-mail]; [e-mail]; Jonathan Morton
>> <[e-mail]>; Greg White <[e-mail]>; Rodney
>> W. Grimes <[e-mail]>; De Schepper, Koen (Nokia -
>> BE/Antwerp) <[e-mail]>; Bob Briscoe
>> ([e-mail]) <[e-mail]>
>> Subject: Re: [tsvwg] plan for L4S issue #29
>> 
>> Hi Ingemar,
>> 
>> 
>>> On Sep 30, 2020, at 10:35, Ingemar Johansson S
>> <[e-mail]> wrote:
>>> 
>>> Hi
>>> 
>>> I think that issue #29 can be closed and moved to ICCRG.
>>> 
>>> My impression, based on earlier discussions on this mailing list is
>>> that possible RFC3168 bottlenecks such as home gateways can be updated
>>> to support L4S alongside with other necessary updates that are done to
>> block e.g.
>>> security threats.
>> 
>> 	[SM] in theory sure, but in reality that is going to take a looooooong
>> time, just think about your typical comercial CPE, this will see updates during
>> a relative short period while it is still sold, with luck a few years out in the
>> future (but only a fraction of deployed devices will actually be updated) but
>> then these devices will continue to operate without much maintenance for
>> years. What I want to say "can be updated" might be true, but is not the right
>> frame of mind, unless you subscribe to the theory of "disruption" that it is
>> fine for a new comer to cause massive interference and that the onus is on
>> the already deployed nodes to get along with the "new order" and change.
> 
> [IJ] Depending on the definition of "long", I would say that there will be ample time to upgrade or replace devices before L4S reaches world domination. 

	[SM] Well, I know CPE that only got replaced, because they finally whee incompatible with the ISPs tech upgrade, there are still ADSL1 -only CPE in use here, that might have been updated last >> 5 years ago. So "long' effectively means never, but then that is the expected time IMHO for L4S to reach "world domination". ;)
My point is, banking upon problematic pieces of equipment being replaced naturally to make up for L4S' short-comings is not optimistic, but simply naive, or consciously ignorant, sorry.


> 
>> [...]

>>> Also I notice that SCE is still brought up even though it had very
>>> limited support in the group while L4S has quite large support. Why do
>>> we still discuss SCE here ?. We really need to move forward, now!.
>> 
>> 	[SM] The first rule of fight club is, don't talk about SCE, if you don't
>> want it to be mentioned. But I consider this remark of yours to be quite rude.
>> Different people can have different opinions on what is a decent solution for
>> a given problem, and just because a group decision goes in one or the other
>> direction, doe not make it useless to keep comparing that potential alternate
>> solutions.
> [IJ] Fine, can we then agree that SCE is not brought up until L4S is declared a failure ?

	[SM] Well, you have control over your own arguments, nobody forces you to bring up SCE. But others obviously are free to argue as they desire. 
I will also remind you on my position: I do not see L4S as a failure because it is different from SCE, but I do see L4S as a failure as it clearly fails to robustly and reliably achieve the goals set out on its own drafts. It also adds only relatively modest improvements over what is possible already today, from an end-user's side (if you wonder, try an OpenWrt router with SQM*). In other words L4S offers too little, too late, and at too high a cost (in undesirable side-effects).

Best Regards
	Sebastian


*) I do not claim that this is the state of the art, but that this is a rather easy vehicle to test how a modern AQM can improve interactivity of a link over the FIFO reference that L4S seems to use as its stawman status quo, without most of the undesirable side-effects.


> 
>> 
>> 
>>> Therefore I would encourage that the persons who are against L4S
>>> instead spend their time and energy on work to make the L4S drafts
>>> advance through WGLC and contribute to the L4S ops draft.
>> 
>> 	[SM] I would appreciate if team L4S would first take the time to make
>> sure that L4S is actually going to work over the wider-internet and actually
>> realizes enough of its promises even under less ideal conditions that so far
>> (over-)tested. Making the drafts advance to RFCs is not an end to itself and
>> IMHO rather a waste of everybody's time, if L4S can not deliver.
>> 	And honestly, given the amount of time I have been asking to be
>> shown L4S actually delivering over the internet (by now years) and the
>> amount of data presented (zero) I do believe that L4S simply only works well
>> over short RTT log-hop count paths and not at all over the wider internet.
>> Because if it would work well over the internet, it would have beed a piece of
>> cake to collect and present that data.
>> 	Again, IMHO the lack of data either demonstrates failure of L4S to
>> deliver its promises over the internet or failure of team L4S to actually test
>> under relevant conditions. Neither of which I would take as a sign thst these
>> drafts deserve to be pushed forward.
> 
>> 
>> Best Regards
>> 	Sebastian
>> 
>> 
>> 
>>> 
>>> Regards
>>> /Ingemar
>>> ================================
>>> Ingemar Johansson  M.Sc.
>>> Master Researcher
>>> 
>>> Ericsson Research
>>> RESEARCHER
>>> GFTL ER NAP NCM Netw Proto & E2E Perf
>>> Labratoriegränd 11
>>> 977 53, Luleå, Sweden
>>> Phone [phone]
>>> SMS/MMS [phone]
>>> [e-mail]
>>> www.ericsson.com
>>> 
>>> Talk about a dream, try to make it real
>>>                 Bruce Springsteen
>>> =================================
>>> 
>