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

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

Hi Rodney 
Please see inline
/Ingemar

> -----Original Message-----
> From: Rodney W. Grimes <[e-mail]>
> Sent: den 10 juni 2020 22:00
> To: Ingemar Johansson S
> <ingemar.s.johansson=[e-mail]>
> Cc: Sebastian Moeller <[e-mail]>; Ingemar Johansson S
> <[e-mail]>; [e-mail]
> Subject: Re: [tsvwg] path forward on L4S issue #16
> 
> Hello Ingmar,
> Inlinde below
> 
> Regards,
> Rod
> > Hi
> >
> > As regards to dualQ (below), do you see any specific reason why it
> > would not be possible to upstream (complexity/memory whatever) it or
> > is your argument that it is just not done yet ?
> 
> It would be a mistake to upstream something into Linux, or FreeBSD or any
> other publically distributed software that has not been accepted as a
solution
> by the IETF, *unless* that code was disabled with #ifdef that would
require a
> custom compilation.  To do anything less to protect the internet from
> potentially harmful software would be irresposible.

[IJ] I guess a lot of things are upstreamed to the Linux kernel without the
blessing from the IETF, the TCP stack is one example which is ahead of IETF
standardization

> 
> > Also, do you have any comments to my three other questions, please
> > refer to earlier email in the thread for the context.
> > 1) Do you have any public sources that confirm the numbers you quote
> > below ?. I tried to look up data on this but it surely is not easy.
> > 2) Which foras are the vendors that manufacture CPEs active in (if any)
?.
> > 3) As regards to endpoints implementing RFC3168, do you refer to
> > servers and clients or something else?. My interpretation is servers
> > and clients and I don't believe that they are central  to this
> > discussion, or do I miss something ?.
> 
> I do not actually believe your 2, or now 3 questions are actually the
right
> questions to be asking.  The fact is that RFC3168 and handful of other AQM
> RFC's are infact the accepted standards for internet operation today, and
> though you can go declare them "non deployed", you can not declare them
> non standard, and until you do so one should considered them deployed.
> 
> If you want to base L4S forward progress on the lack of RFC3168 AQM's then
> you *MUST* first get the IETF to revoke the standard status of
> RFC3168 and all related AQM's.
> 
> 5 years ago when L4S started that might of been possible, but given the
push
> in the last 5 years of people actively deploying
> RFC3168 and new AQM's based on it that possibility is most likely no
longer
> possible.  And even if it was I suspect the long tail would put you 10
years
> down the road.

[IJ] My intention with this was to first and foremost get a feeling about
the severity of the problem stated in issue #16. Given what this gives in
hand it is perhaps possible to move forward (or not). 
But we somehow need to see the numbers and hard facts on the table,
otherwise we are stuck in this discussion forever.

> 
> > /Ingemar
> >
> >
> > > -----Original Message-----
> > > From: Sebastian Moeller <[e-mail]>
> > > Sent: den 10 juni 2020 16:35
> > > To: Ingemar Johansson S <[e-mail]>
> > > Cc: Jonathan Morton <[e-mail]>; [e-mail]
> > > Subject: Re: [tsvwg] path forward on L4S issue #16
> > >
> > > Hi Ingemar,
> > >
> > > to gently push back on some details.
> > >
> > > > On Jun 10, 2020, at 15:59, Ingemar Johansson S
> > > <[e-mail]> wrote:
> > > >
> > > > [...]I understand that traffic shaping on outgoing interfaces can
> > > > be applied in a Linux host but don't see why they become a problem
> > > > especially as there are qdiscs that support dualQ.
> > > > [...]
> > >
> > > 	There seems to be a single out-of-the-mainline-Linux-tree
> > > repository
> > > (https://protect2.fireeye.com/v1/url?k=e33cc533-bd9c7f5d-e33c85a8-
> > > 869a14f4b08c-0ec6a27e7722e722&q=1&e=29721776-06f8-43e4-a1e6-
> > > 67f0d2c15283&u=https%3A%2F%2Fgithub.com%2FL4STeam%2Flinux) for
> both
> > > the dual queue coupled AQM and TCP Prague.
> > > 	I would not call that prrof of sufficient existence of "qdiscs that
> > > support dualQ" to allow Linux system admins to switch over to
> > > dualqand I
> > do
> > > not see how even inclusion into the mainline kernel* would this
> > > solves the issue for currently deployed Linux machines, which often
> > > use vendor
> > kernels
> > > which do not necessarily track mainline closely, especially for
> > > server distributions.
> > > 	I would respectfully argue that for safety considerations one
> > > should look at the current state of the internet and not potential
> > > less
> > problematic
> > > states one would like to find the internet in...
> > >
> > > Best Regards
> > > 	Sebastian
> > >
> > >
> > > *) As far as I can tell there have been no attempts at upstreaming
> > > the
> > dual
> > > queue coupled AQM yet, so it is not clear what/if survives the
> > > contact
> > with
> > > the linux kernel maintainers.
> 
> --
> Rod Grimes
[e-mail]