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

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

Hi Sebastian

Please see inline
/Ingemar


> -----Original Message-----
> From: Sebastian Moeller <[e-mail]>
> Sent: den 9 juni 2020 21:41
> To: Ingemar Johansson S <[e-mail]>
> Cc: Jonathan Morton <[e-mail]>; [e-mail]
> Subject: Re: [tsvwg] path forward on L4S issue #16
> 
> 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.

[IJ] That boils down to an assessment how severe the issues you point out
really are, and to some extent it boils  down to my questions #1 and #2
below. 

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

[IJ] Then one need to define the meaning of "localized experiments" but I
skip that part. I guess it is not IETFs intention to leave up to other SDO's
like 3GPP to do what they like with the ECN bits until IETF has made up its
mind. Or is it ?, this is at least not how I read the message in TSVWG.

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

[IJ] OK, I tend to use the this IPv4/6 analogy every now and then, but that
does not at all apply here. 
IPv4 is widely deployed and I don't even use IPv6. I seriously wonder how
widely RFC3168 is deployed and used in AQMs
So here my questions are (repeated):
1) How widely are  RFC3168 ECN capable AQMs deployed _and_ enabled ? 
   IPv4 and RFC3168 ECN capable AQMs seem to have very little in common when
one look at deployment and use, so how commonplace is it that nodes on the
internet have RFC3168 ECN capable AQMs deployed _and_ enabled, 1%, 10% ???? 

2) If they are deployed _and_ enabled, can/will they be updated ?
   You gave your personal view on this matter.

I guess it can be a good exercise for the opponents to the L4S to come with
verifiable answers to these two questions. It is important to know so we
don't waste a lot of energy on a problem that diminishes among all other
problems.

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