Re: [tsvwg] plan for L4S issue #29

[Ingemar Johansson S <[e-mail]>]

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.

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

> 
> >
> > 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.
[IJ] Fine, can we then agree that SCE is not brought up until L4S is declared a failure ?

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