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

Sebastian Moeller <moeller0@gmx.de> Wed, 10 June 2020 20:05 UTC

Return-Path: <moeller0@gmx.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61693A106F for <tsvwg@ietfa.amsl.com>; Wed, 10 Jun 2020 13:05:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTQAb8AWaPQn for <tsvwg@ietfa.amsl.com>; Wed, 10 Jun 2020 13:05:10 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D11833A1123 for <tsvwg@ietf.org>; Wed, 10 Jun 2020 13:04:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1591819483; bh=N6IQWzr/gmJS5QqUgimlLTHeAsvGjSk/OgbCabtupbY=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=ZIRQVS1hccPpZfBOcrJw9diZdLp/y4N2PhE2xebwKwzIuKM/dHnr8eKjNMWZd4IJT jLQo34cztvfTenCDgMcfD2iH4BbDK6JbyFLncBiX2154c6+wQfGXjjmxwL5tgHZIQC XwUwhs09h5bwaHGHwYkScMw+hw7NhpETLSUwj5J8=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([77.1.245.122]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MybKf-1izupK2SlR-00ywpv; Wed, 10 Jun 2020 22:04:43 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <HE1PR0701MB287670627208FB1075F78F6DC2830@HE1PR0701MB2876.eurprd07.prod.outlook.com>
Date: Wed, 10 Jun 2020 22:04:41 +0200
Cc: Jonathan Morton <chromatix99@gmail.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E127BDE9-0249-47CD-ACBD-1C4296258B08@gmx.de>
References: <HE1PR0701MB2876AA3CBBA215B9FB895B0AC2820@HE1PR0701MB2876.eurprd07.prod.outlook.com> <3637517F-63A0-4862-9885-AB5EA7E6C273@gmail.com> <VI1PR0701MB2877E21B7F406C3DFCFF08BCC2820@VI1PR0701MB2877.eurprd07.prod.outlook.com> <92525827-39B6-4E88-B453-660F8FE22523@gmx.de> <VI1PR0701MB287768D465C37DC46A459C12C2820@VI1PR0701MB2877.eurprd07.prod.outlook.com> <57D7632A-594E-47BC-B6B0-5FBC22AAFE37@gmail.com> <DF67B660-DE2B-4EB8-AD77-5FECF27D1BAC@gmx.de> <HE1PR0701MB287679D1842F15FCDAC6223EC2820@HE1PR0701MB2876.eurprd07.prod.outlook.com> <7EEF7075-396F-4565-89C6-674CBB1E6CB8@gmx.de> <HE1PR0701MB28767A1E570A705EBC65EFC4C2830@HE1PR0701MB2876.eurprd07.prod.outlook.com> <5ADEBD56-1A2C-4C34-9132-E50A4A7A4A42@gmx.de> <HE1PR0701MB287695F2245A480A43DB5F9BC2830@HE1PR0701MB2876.eurprd07.prod.outlook.com> <EEB9B5D1-5F06-4BA6-A078-BE9C26D0EAD6@gmail.com> <HE1PR0701MB2876726FC67BD2850B5D39FAC2830@HE1PR0701MB2876.eurprd07.prod.outlook.com> <E17FCDCD-6D2D-4773-98AA-44EB54A79F62@gmx.de> <HE1PR0701MB287670627208FB1075F78F6DC2830@HE1PR0701MB2876.eurprd07.prod.outlook.com>
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
X-Mailer: Apple Mail (2.3445.104.14)
X-Provags-ID: V03:K1:rV/3CRzARmkIBVpKVxUPmYPnvLNCmavUD1Q34nEj1xYBVu0t01H +RhR5YWF9LwTe0uUxrLhMZjgocxIkvu9VxBlhCohZvBXya0icAK9SV7gcBa2ak17EvoET70 85HAIFl6Y6Lx+VuoZ9Xx8m+XAv4M9VRqWd64leN+42Mdxl5y6Vw6nL7ErDswCT69ajf3svn jPTV3JcdaPM5EzJkklhgw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:3vJ+nOfdpkI=:3MSdHctrv+aM+uGX+cCaqZ XAdAvpZsd9Tez7OEsannN4rHju7qIVkLLYAltd2FDC6/u/LSx5RFvOwdsjQMHhyV5xmvKeCe/ CQa+kPCt6Z6M49Q9igSFCGPpeeUu611r/dGsYO+4/JiuZyW8s45N0BkWIvgWdq4zm294gzcdz XKhl63uzJ8I2lF6o3sh6Y/0uJs19WbjdTAADb5JPqp2sMZ+gEnoIOVT8P5ueNLWmnsrRG3szq Ee12t+GYi30F2R8TbFqENCjm4jP9FOcCNWbZDo7x00RiATeUHI4sLdp3Htn4/4ESj0R1ktoNp mDEs5g4vxuXR1LCq3+IFrWMCWcUzvGh+Vj04nBPh+x5OinnJTk519A4GVSEqxTGQZL8RxGhcL hkW39xGVvjKoDzapXW/KUCT3ee9ByTWi35nEsPZb1x/9SYo/gQU885wRnfmouzoTFQpx875fF ExmPJxaxsMEM1ipvsXYhRmHlBz1UGkHZ5S2Pt5mSfzwVkOrzR8mSH0+rD8uIM+Vgi8YCYdiid hGZ8IbfQeh84WyGzKgKhDvC9WWMjFOjmDmz0kDVob35GRerlBwHo0M0J/q4l/CVZyls6P423v rbkujqmn2Tnh8+iXXaGCHeGODDmc+3miiwL1OFuol1TkZSuOkiye/SknBc4q/1chfZaVv0y51 qjkFroKtS/9vhpDWUNQnzvj1LEawoo2IdirV+wu0yohKVLhtQ3f30jr6fcfb+C3UEDKxuxJDw 2um4FkdNnbYOBk4SxeuO9QJHEcu8Q7zLREGydWP7Fo5hsJUePBbQbfYei0kIaKIDiJ3p5f3XW vrQtv4Z1y0YMEKJAVmx2VSxjh/q+PhowWlaxTYv81s/9JwURiOi3qO4JVOTF6sll02MJ58Jh1 o4CNlDYQkLYc1cdPDWbO01NELB1mnG1LWo8N086Sc8BAth1DYz7XiBxPbwJkEceehy9wnzMxm ZuDMRBXoTlNOFb9VUSftMpBpg/G4atsjiN49zLQREK8PSesrNiEwrBhjVkjRdkkGGxc5f2Faw j+woPJ/+vGwQ5Ixr2YtZqXR+gpUnqXdqfCMIbNZHBwWq2io8EXCfNRE2L6W3Zk7pyoOZnxphQ FactMJs1CZ/D3J2m1qNdUHsVKJNcQR0WStSH87unPzSPCTjIeYAZSDgHmLvhnmTvXECWCGgMl w0BxqlrjMMHCTS3lVjJAuReDe1uuNkIpcAaC1964PugIKp8hRnJHC2ybQEoRJf14L7Yq38Cqi Hx9ki3xo34loN+v+ZfJxu+4nQi/iuUfbt6SBfZ5UlzrS3I68Pl4dHvclX4Rn+TqkKhFDQFMOC /iGz8ZdI1X8j7vRgHjkZxEcGlO7XgCVU+WSBcoJB3PPoaSIp1j/l3FLQq6UKV/bnvFtZCp6h
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/JfGCvBv53_YShFPE2ktzCSjAoyg>
Subject: Re: [tsvwg] path forward on L4S issue #16
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jun 2020 20:05:12 -0000

Hi Ingemar,

more below in-line.

> On Jun 10, 2020, at 19:15, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> 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 <moeller0@gmx.de>
>> Sent: den 10 juni 2020 16:35
>> To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
>> Cc: Jonathan Morton <chromatix99@gmail.com>om>; tsvwg@ietf.org
>> 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
>> <ingemar.s.johansson@ericsson.com> 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.