Re: [tsvwg] L4S, the endless discussion

[Sebastian Moeller <[e-mail]>]

Hi Ingemar,

"figment of the imagination" is veering into personal insults territory, I do not think this is where this discussion should to go if the goal is to actually improve the drafts. 


> On Mar 24, 2021, at 08:49, Ingemar Johansson S <ingemar.s.johansson=[e-mail]> wrote:
> 
> Hi
>  
> In email threads I read about "Team L4S" and "somebody else's experiment" like it is just a figment of the imagination in just a few peoples’ mind. Note that L4S got wide support from the industry at the interim a year ago. 

	[SM] Sorry, wasn't the question back "ECT(1): input or output"? The question was not L4S or something else, so I consider it to be bad style to post-hoc interpret that decision as a "vote" pro L4S. 

>  
> Still, the whole process seems continue to stall and has done so the last ~2 years. How long can we continue with this ?. 

	[SM] Well, if team L4S continues to not make any fixes/changes to the design and implementation that have been shown by real data to be deficient, we hopefully will carry on not ratifying this until it is fixed? Just getting ratified for sheer persistence will set a bad precedence.


> There are entire email threads started by a few opponents around all things that can go in the shitter when the L4S experiment starts, but so far I have seen nothing, nada, zero…. discussion by the opponents around “what can _we_, the opponents do to remedy these potential issues on our side?”. 

	[SM] Sorry, there have been proposals how to make L4S less of a safety problem for the existing internet, as well as how ot fix the deficient core design and implementation, what has not been volunteered are fixed implementations, but that is hardly the job for someone showing that a design is unfit for purpose? Tyically the onus to fix, would e on those who want a technique/design/implementation to become a standard.


> Instead all I see is that the burden of proof is put on "Team L4S".

	[SM] And rightly so, you want something quie soecial and precious, the right to redefine an already deployed signaling mechanism with known and accepted negative side-effects, so asking you to make sure that these side-effects are minimized is not a "burden" or a request for different rocks...


> I can understand that this situation is the normal in the initial phase but now we are soon into a 2 year long infected debate that does not seem to show any evidence to end. 

	[SM] Because in these two years the L4S design and implementation has not been changes to make the objections pointless/invalid. This conscious inaction of tem L4S is hardly a reason for the WG to now rubber stamp the same designs and implementations that where identified as deficient years ago.


> To me all this just look like a very long filibuster. I mean, at some stage we need to move on, or ?.  

	[SM] If you had taken the objections in good faith and actually attempted to address them properly, you would be in much better shape. But calling objections based on real data "filibustering" indicates, that you never actually accepted these objections as real and hence never attempted to fix the underlaying problems, but only show enough activity to muster a "addressed objections" standard. Case in point the RTT-bias clown show, in which you a) mis characterize the root cause1) of RTT-bias, b) based in that flawed assumption designed a flawed "solution"20, and c) only implemented enough of that solution to tackle on of Pete's specific measurement points3)...

	In short, these drafts should move on when they are ready, and not simply because time has passed, as you seem to argue.

	

Best Regards
	Sebastian

1) RTT-bias is not caused by end-points alone, but is a result of the diifferent dynamics od different RTT flows inside the bottleneck's buffer
2) Since RTT-bias is not caused by end-points alone trying to fix it in the end-points/the protocols is a fools errand, it needs at least support from the bottleneck buffer management, but the L$S AQM makes the problem worsse instead of ameliorating it.
3) the magic number 20ms, in TCP Pragues RTT-independence mode, I believe comes from the faxt that 20ms is one of Pete's testing points, at least there was no rationale how this number was divined. But that kind of test-hacking reveals a desire to pass a test, and not a desire to actually solve the problem.




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