Re: [tsvwg] path forward on L4S issue #16

[Sebastian Moeller <[e-mail]>]

Hi Ingemar,


> On Jun 9, 2020, at 20:58, Ingemar Johansson S <[e-mail]> wrote:
> 
> Hi
> Just for my understanding, do you seek evidence that L4S can be safely
> deployed before the experiment actually starts or is the collection of
> evidence a part of the experiment?

	[SM] That depends on what you mean with experiment. Yes, I want to see that data BEFORE L4S is awarded IETF RFC status above informational... As far as I understood Gory, the intended experiment for granting L4S experimental RFCs (first) is how to roll-out L4S safely. IMHO describing the intended behaviour for the few scenarios I outlined and then demonstrating that the actual implementation meets those goals, should be an uncontentious "conditio sine qua non", but as this whole process demonstrates this does not seem to be the consensus position.

> 
> To take 3GPP networks as an example. I don't expect that initial experiments
> will run across the entire internet. And as this experiment carries on I see
> a likelihood that RFC3168 ECN capable AQM where they may be will/can be
> upgraded to support L4S as well ? Meanwhile one will learn things from the
> experiments and will be able to refine congestion control algorithms. Does
> it sound all too unrealistic?

	[SM] No, that sounds fine, but you do not need IETF approval for such localized experiments to begin with, it is really the "across the entire internet" part in the L4S RFCs that makes it IMHO a prerequisite to demonsatrate sufficient safety before roll-out. I note that none of the conditions I outline could not be easily tested in a more or less private experiment still spanning the width of the internet, just set-up three test nodes, say, one in Frankfurt, one in Atlanta and one in Tokyo each with an L4S AQM and go wild with testing traffic between them, no RFC required for that. 
	But here we are, working hard to get IETF approval for L4S even before it is clear that L4S can actually deliver its promises under normal internet conditions. 


> 
> This boils down to the two questions that I had in another thread.
> 1) How widely are  RFC3168 ECN capable AQMs deployed _and_ enabled ?
> 2) If they are deployed _and_ enabled, can/will they be updated ?

	[SM] Just looking at the IPv4/6 "transition" the answer to the second question is, "yes" and "with glacial speed". I can understand the desire for the existing internet to follow one's own idea of optimality, but realistically the existing internet has a lot of momentum and and thing that requires a flag day, pretty much is doomed (unless as clearly beneficial to everybody as the introduction of congestion handling, but L4S' gains are rather modest in comparison).

 Best Regards
	sebastian


> 
> /Ingemar
> 
>> -----Original Message-----
>> From: Sebastian Moeller <[e-mail]>
>> Sent: den 9 juni 2020 18:25
>> To: Jonathan Morton <[e-mail]>
>> Cc: Ingemar Johansson S <[e-mail]>;
>> [e-mail]
>> Subject: Re: [tsvwg] path forward on L4S issue #16
>> 
>> Hi Jonathan,
>> 
>> 
>>> On Jun 9, 2020, at 17:01, Jonathan Morton <[e-mail]>
>> wrote:
>>> 
>>>> On 9 Jun, 2020, at 5:43 pm, Ingemar Johansson S
>> <[e-mail]> wrote:
>>>> 
>>>> Why don't you run the testing yourself to get the answers you look
> for?.
>>> 
>>> Because we are looking for cases where SCReAM (and other L4S
>> transports) fail - and we have already found sufficient such cases to
> raise
>> objections.  We don't need to look further.
>>> 
>>> The burden of proof is now on you (and the rest of the L4S proponents)
> to
>> show that these problems have been overcome.    This will require
>> *changes* to L4S, and testing of an implementation of that changed
>> specification.
>>> 
>>> Sebastian merely listed a few general scenarios where we know L4S does
>> badly.
>> 
>> 	[SM] Well, to be generous, these are important scenarios where we
>> know way too little about L4S' robustness and reliability. The recent
> testing
>> indicates that L4S has ample opportunity to improve its performance/safety
>> under these conditions.
>> 	Now, I have a hard time believing that none of the engineers and
>> companies that opted for L4S did this based purely on the obviously
> overly-
>> optimistic promises in the L4S drafts and the RITE project. So, I would
> really
>> appreciate if data that was acquired in the process of seeing whether L4S
>> was/is fit for roll-out and implementation in silicon (if that actually
> happened
>> at all) could be presented here on the list.
>> 
>> Best Regards
>> 	Sebastian
>> 
>> 
>>> Those are tests which you should run internally as part of your R&D
> cycle,
>> and then present results of, in order to give us confidence that L4S can
> safely
>> be deployed.
>> 
>> 	[SM] +1.
>> 
>> Sebastian
>> 
>> 
>>> 
>>> - Jonathan Morton
>>> 
>