Re: [tsvwg] plan for L4S issue #29

[Sebastian Moeller <[e-mail]>]

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.


> 
> In addition, this discussion is a non-issue for 4G/5G access as RFC3168 ECN
> is AFAIK not at all implemented or publicly available in 4G/5G. 

	[SM] Are you planning to roll out L4S equipped tunnels over the 4g/5G links that decapsulate to non-L4S for the internet part of the path? Or are you proposing to use L4S AQM only on the ingress/download side? The problem is that the bottleneck of any path can move between any hop at any time, just because the 4G/5G side of the path might be guaranteed to not use rfc3168, how can you guarantee that for the rest of the path?

> 
> Also think that it is reasonable to go for algorithms that can do detection
> rather than fall back.

	[SM] Please explain your nomenclature. The way i understand it, detection is the first required step if one wants to implement a method to allow peaceful coexistence, and fall-back to rfc3168 sematics for L4S on paths with rfc3168 bottlenecks is one such method.
Doing detection without trying to coexists seems useless busy work, especially since the currently proposed detector is going to be not-perfect, so without proper verification and analysis a report of detection likelihood or some-such will be next to useless.


> This can be documented/referenced to in the L4S ops
> draft started by Greg White, that is published later on.

	[SM] This seems unhelpful to split important operational guidance into different documents unless they will be at least as string and binding as the RFCs they refer to, IMHO putting the operational guidance into informational RFC is sub-optimal if the referred RFCs are experimental or standards track.

> 
> The important thing is that I don’t see any reasons why L4S issue #29 should
> block WGLC for the L4S drafts.

	[SM] I agree, it is the lack of data demonstrating that L4S actually works over normal internet paths that should block the WGLC for the L4S drafts, or the lack of sections explicitly elaborating on criteria when to abort the experiments and methods how to do so with minimal but explicitly enumerated predicted side-effects. But blocked they should be at the current time.

> 
> What worries me deeply is that this activity tend to get stalled in endless
> discussions and deep analysis what people may or may not have said and that
> sucks energy from the group. 

	[SM] I take offense in that. If the RFCs seem seem blocked then because team L4S decided to outwait critics and instead of delivering data to support their hypotheses that L4Ss is suitable for internet-wide deployment and data that shows that it keeps its promises even in "normal" situations. 


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


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