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

[Sebastian Moeller <[e-mail]>]

Hi Ingemar,

more below in-line.

> On Jun 10, 2020, at 19:15, Ingemar Johansson S <[e-mail]> wrote:
> 
> 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 ?

	[SM] Caveat: I am not involved in the Linux kernel and hence can not predict with any certainty dualQ's likelihood of getting included. BUT as you know I am arguing for some time now, that there is a discrepancy between the dualQ claims and its actual performance. In other words it is not done, and given the responses from the L4S team to this issue (like the 15ms hack in TCP Prague's CC response) I am more and more of the opinion, that this is not simply a case of dualQ just not being finished, but rather that the current dualQ design simply can not meet its promises and someone would need to go back to the drawing board. 

> 
> Also, do you have any comments to my three other questions, please refer to
> earlier email in the thread for the context.

	[SM] I snipped these out of my reply since I had nothing meaningful to add to those.


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

	[SM] I do not know where Jonathan's numbers come from. But https://datatracker.ietf.org/meeting/98/materials/slides-98-maprg-tcp-ecn-experience-with-enabling-ecn-on-the-internet-padma-bhooma-00 has some numbers from Apple, I believe Bob cited these numbers multiple times in the past.
Given the fact that 3gpp contains quite a lot of large carriers maybe that would be a forum to ask for numbers?


> 2) Which foras are the vendors that manufacture CPEs active in (if any) ?.

	[SM] I believe that OpenWrt certainly supports rfc3168 behaviour, and there are CPE that run on modified OpenWrt, so the OpenWrt forum might be a decent starting point?

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

	[SM] Well, it is these end-points that are going to suffer, when L4S gets it wrong (when, not if). So these numbers give you an estimate of the potential fall-out area.

Best Regards
	Sebastian


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