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

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

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 ?

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

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