From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id AAA853CB36; Wed, 20 Mar 2019 18:56:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1553122602; bh=1M3DLQAMJSTaWhTQDg5sRgXhpOqTsHZVZc1FmwOACvI=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=eDg8Z6WHrGcEyZK4gDvITdJCR9pPRVC235EmiWCmIaxrYS9ojZ8eV13B8WrV9xPT/ 5lcG+8C1OH+y1THuSgLQsVkQRRUYQZqX2VTksFwI19uJbeGThCOIBvR4KNwprMpQJe PGBgi5mZtXujixewUuCAXzNMTN9iywaiAAfjRhnM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hms-beagle2.lan ([77.179.189.192]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MOw4N-1h3BN70WZT-006KP1; Wed, 20 Mar 2019 23:56:42 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sebastian Moeller In-Reply-To: <06379263-6C0E-4EC1-9537-DE4C5F61846C@gmail.com> Date: Wed, 20 Mar 2019 23:56:40 +0100 Cc: ecn-sane@lists.bufferbloat.net, bloat Content-Transfer-Encoding: quoted-printable Message-Id: References: <1E80578D-A589-4CA0-9015-B03B63042355@gmx.de> <27FA673A-2C4C-4652-943F-33FAA1CF1E83@gmx.de> <1552669283.555112988@apps.rackspace.com> <7029DA80-8B83-4775-8261-A4ADD2CF34C7@akamai.com> <1552846034.909628287@apps.rackspace.com> <5458c216-07b9-5b06-a381-326de49b53e0@bobbriscoe.net> <5C9296E1.4010703@erg.abdn.ac.uk> <06379263-6C0E-4EC1-9537-DE4C5F61846C@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.3445.9.1) X-Provags-ID: V03:K1:hQ3p2c2U1twc1AaGnXVUDemztnIG2BJJ+RqCXj8mU+jPnd4NX/H p7+2kgkwVxOzT+rbbAA6XHmkKixMNf8Tc98Lxx79t3xtHRz0wX9NaMEId5wF/mmNuuGDXjF WuyM1tuPoj+CpmKTZQB9hIT2+9rhEPuT0oZpe5Yev6Bqq5Dw9hCROg3BHTMKBksWideAtaq w+HCfQW8YtGp+LCYzADrA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:cd3Lj7TPfRA=:11UM4TMcv78H/bH/slB36g UfsM8kVeBOTCryuGaj0iHeDscSYnk5saH/XJY9BhmnIrOu/msakIhvE3kNXnuQCayIdro8wq+ vDd7Zgkmp9pG6Vv5GrIyiOJjZuRtzIelFdVTi9hrCUiWG4gs7az8M/SMeFA25AdXkNkgqTr9e szq43i/zUlF/XPniXQvDIN8RIXsW5ZzWacAkoAI2eSQfsOwID6XLKb5o85y+scmBTPH0bC3TC rHaVon3cokDLS1FHtF+/rjeYmO7pKTp82utXmP3Yxk/V9FDIkI3O725WuPhCuIttlxQBbdfl9 beG/vq/IhO/Z5xbH56a0I3d42UCEaM+1zjxduE9XyRi7o4sd6vdlJyRVdrZ/oxpwgByhyp5AI KhSXdP1AAAIVkuzJp9yDW1pi/bUA9I8mUnXM0O9iJSbXaa/zE4Azz3Q3LfsQkmCHSBaYEzLvB S61/oI8mxHTKp8c0dcQt6AORpJXigS/9PJtBKjvVyc6ukYZ4u37ZTOtTprICzlLG2CSxUSf0/ OEBIpYRWsCLMAwMXFaHZ9Dtrcw2MPyz4jcera+v/lraDjx/3Pbz0ZYtpgEFlRMfBQxUuR+WmO /VZxxkIPMp8IAD5XYRmQ7sUQvhy/EssMDrISUG+gW1mywiB/SEFYNAZFP2OXzTz6DtB0Y2oc/ yYC/2QI9Pdr/NCrCjSuEhEjTNKTRVABOaT30giM9m+9+01HQte7ier8X3nsZxvb/CjEWNFc59 fBys9mUN8zaQzafHvPo0/htumJgI7tANo8aLHeU/OQ8NGIbOUIhP/JrTrJEYI4+de6Zl+0WWb M5qe4Lfno6lEAxL+tQGVecZY0czzs/Mi7OLD/IuS1p8qPqWcl9hVzpajh9vxKSqo3EzwNFYpa QqVPOX6ZrRzXZeGw1xRrqdvavqUIA3LG/lcmfMkrGR2sFStIX3GI34jEMew4MPwO3LlFQCqZd a0aEmZjZv4A== Subject: Re: [Bloat] [tsvwg] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104 X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 22:56:44 -0000 > On Mar 20, 2019, at 23:31, Jonathan Morton = wrote: >=20 >> On 21 Mar, 2019, at 12:12 am, Sebastian Moeller = wrote: >>=20 >> they see 20ms queue delay with a 7ms base link delay @ 40 Mbps >=20 > At 40Mbps you might as well be running Cake, and thereby getting 1ms = inter-flow induced delay; an order of magnitude better. And we achieved = that o a shoestring budget while they were submarining for a patent = application. >=20 > If we're supposed to be impressed=E2=80=A6 Nah, there is this GEM: Comparing Experiments 5, 7 with 6, 8, we can again conclude that our = DualQ AQM very much approximates the fq CoDel AQM without the need for = flow identi- fication and more complex processing. The main ad- vantage = is DualQ=E2=80=99s lower queuing delay for L4S traffic. So for normal traffic is is worse than fq_codel and better for traffic = that does behave TCP-friendly, for which it was bespoke made. So at = least they shoud have pimped fq_codel/cake to emit their required CE = marking regime and do a test against that, if the goal is to compare = apples and apples. I note that they do come into this with a grudge = against fq "Per-flow queuing: Similarly per-flow queuing is not = incompatible with the L4S approach. However, one queue for every flow = can be thought of as overkill compared to the minimum of two queues for=20= all traffic needed for the L4S approach. The overkill of per-flow = queuing has side-effects:" followed by a list of 4 more or less = straw-man arguments. Heck these might be actually reasonable arguments = at their core, but the short description in the RFC is fishy. I believe the coupling between the two queues to be clever and elegant, = but the whole premise seems odd to me. What they should have done, IMHO = is teach their AQM something like SCE so it can easily react to CE and = drops in a standard compliant TCP-friendly fashion, and only do the = clever window/rate adjustments if the AQM signals ECT(1), add fair = queueing to separate the different TCP variants behavior from each = other, and bang no classification bit needed. And no patent (assuming = the patent covers the coupling between the two queues)... I am sure I am = missing something here, it can not be that simple. Best Regards Sebastian P.S.: How did the SCE-Talk go, interesting feed-back and discussions? >=20 > - Jonathan Morton >=20