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

["Rodney W. Grimes" <[e-mail]>]

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.

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

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