Subject: Re: [tsvwg] plan for L4S issue #29

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 30 Sep 2020 08:35:24 +0000

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. 

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. 

Also think that it is reasonable to go for algorithms that can do detection
rather than fall back. This can be documented/referenced to in the L4S ops
draft started by Greg White, that is published later on.

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

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

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 +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]
www.ericsson.com

 Talk about a dream, try to make it real
                  Bruce Springsteen
=================================

---

From: <[email-masked]>
Date: Wed, 30 Sep 2020 09:16:08 +0000

Hi Ingemar,

One observation, I think it is mainly L4S which is discussed very
intensively by this list. My perception is:

- some discuss L4S and available features and try to improve it
- some discuss L4S and require features not available yet (but so far
provide little input in improving L4S)
- and some discuss their expectations on transport protocols using ECN
codepoints and try to help improving the TSVWG specifications discussed
and/or deployed today.

To me, controlled, careful and reasonable experimentation with a following
evaluation looks like a useful approach. That might initially be more of a
"test user" thing, not code released for the wild. A set of different
players may be useful too (e.g., I don't know whether an access router
vendor offers an L4S implementation, and availability of applications or
content expected to benefit from L4S transport certainly would be very
helpful).

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: tsvwg <[email-masked]> Im Auftrag von Ingemar Johansson S
Gesendet: Mittwoch, 30. September 2020 10:35
An: [email-masked]
Cc: [email-masked]; Ingemar Johansson S
<[email-masked]>
Betreff: Re: [tsvwg] plan for L4S issue #29

Hi

Regards
/Ingemar

Ericsson Research
RESEARCHER

---

From: Sebastian Moeller <[email-masked]>
Date: Wed, 30 Sep 2020 11:40:35 +0200

Hi Ingemar,

> On Sep 30, 2020, at 10:35, Ingemar Johansson S <[email-masked]> wrote:
> 
> Hi
> 

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

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

> 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

	[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 dont see any reasons why L4S issue #29 should

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

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

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

> 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

---

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 30 Sep 2020 10:06:37 +0000

Hi Ruediger
Please see inline

/Ingemar

> -----Original Message-----
> From: [email-masked] <[email-masked]>
> Sent: den 30 september 2020 11:16
> To: Ingemar Johansson S <[email-masked]>
> Cc: [email-masked]
> Subject: AW: Re: [tsvwg] plan for L4S issue #29
> 
> Hi Ingemar,
> 

[IJ] As I see it, this is how it will play out initially, we are talking
about gradual rollout of L4S enabled nodes. It won't happen overnight,
especially when we discuss 3GPP equipment. Also we have the chicken and egg
problem to overcome, application developers must build in L4S support in the
applications and network vendors and operators need to deploy and enable
L4S. This need to happen in parallel and requires a bit of education and
promotion. 
But somewhere one need to take the step and say , "we should go for this",
things will never happen if we decide to wait a few more years until we know
better. As I see things, the only way to learn in this context is by doing.
It will take a few years, but that is OK too as it will give time to
upgrade/replace devices that may not work with L4S.

---

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 30 Sep 2020 10:44:01 +0000

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

> From: Sebastian Moeller <[email-masked]>
> Sent: den 30 september 2020 11:41
> Cc: [email-masked]; [email-masked]; Jonathan Morton
> <[email-masked]>; Greg White <[email-masked]>; Rodney
> W. Grimes <[email-masked]>; De Schepper, Koen (Nokia -
> BE/Antwerp) <[email-masked]>; Bob Briscoe
> ([email-masked]) <[email-masked]>
> Subject: Re: [tsvwg] plan for L4S issue #29
> 
> Hi Ingemar,
> 
> 
> > On Sep 30, 2020, at 10:35, Ingemar Johansson S
> <[email-masked]> wrote:
> >
> > Hi
> >
> > 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.

---

From: Sebastian Moeller <[email-masked]>
Date: Wed, 30 Sep 2020 13:03:45 +0200

Hi Ingemar,

more below in-line.

> On Sep 30, 2020, at 12:44, Ingemar Johansson S <[email-masked]> wrote:
> 
> Hi Sebastian

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

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

>> [...]

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 30 Sep 2020 13:06:26 +0200 (CEST)

> content expected to benefit from L4S transport certainly would be very

I participated in FQ_CODEL / CAKE evaluation which was easy to do because 
it was developed using a fork of OpenWrt which had readily available 
platforms/code/compilation environment etc and it was easy to get started 
because it was already packaged. There was also tools like Flent to 
evaluate performance in different combinations. All development was done 
on github etc and it was easy to follow.

When searching for L4S patches I find https://github.com/L4STeam/linux

I don't see much activity in the past 5 months, is this really where 
development is being done?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Sebastian Moeller <[email-masked]>
Date: Wed, 30 Sep 2020 13:21:20 +0200

Hi Mikael,

these are good points, that could be actionable for team L4S, see below.

> On Sep 30, 2020, at 13:06, Mikael Abrahamsson <swmike=[email-masked]> wrote:
> 
> I participated in FQ_CODEL / CAKE evaluation which was easy to do because it was developed using a fork of OpenWrt which had readily available platforms/code/compilation environment etc and it was easy to get started because it was already packaged. There was also tools like Flent to evaluate performance in different combinations. All development was done on github etc and it was easy to follow.
> 
> I don't see much activity in the past 5 months, is this really where development is being done?

	[SM] If the repeated claim that team L4S invites everybody to help improve L4S it would be a great idea to offer a set of globally diverse distributed L4S-enabled endpoints, that sit behind well described L4S-AQM bottlenecks and that allow say something like long duration speedtests with timestamps, so that everybody can use the same set of testing endpoints to finally get to the answer of the question to what degree the current L4S design is actually going to work over the existing internet. If applying measurement endpoints is too big an ask, at least team L4S should consider to supply ready configured container/VM images for endpoint and AQM roles to expedite testing.
	Which accidentally does not require any progress for the L4S drafts, and could be tackled today. As it stands, everybody wanting to kick the tires of L4S is basically forced to establish both endpoints and the AQM themselves, which does put considerable hurdles into the path of non-full time AQM researchers. 

Best Regards
	Sebastian