From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 499163CB36; Wed, 20 Mar 2019 19:30:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1553124653; bh=qMyL6Ae5gGjzhV+hMNImTx8YANCEvF7LjmCHIsFlXIQ=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=G3bJU5B20xNotKyV4H+DvWrIa4U6Jax31kAuxGgYvTe/ywAs/o3QQvYngpBJgKoux 41Voareo7/AW2o/h4d57IJlqmSOojPYaFRUA9XBm8G4aGV6gQvvV0kPiAvaj4NTifj DvPCyKbR8me6JxYNQCF9ghPF02suFAIMNPnYJU34= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hms-beagle2.lan ([77.179.189.192]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M8NWM-1gk17v1tzu-00vyKu; Thu, 21 Mar 2019 00:30:53 +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: <5AAAE942-12C9-4D5F-B04A-36A4A61C3501@akamai.com> Date: Thu, 21 Mar 2019 00:30:51 +0100 Cc: Jonathan Morton , "ecn-sane@lists.bufferbloat.net" , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <05D67B58-BB95-461B-A9E8-F7A5DC771D05@gmx.de> 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> <5AAAE942-12C9-4D5F-B04A-36A4A61C3501@akamai.com> To: "Holland, Jake" X-Mailer: Apple Mail (2.3445.9.1) X-Provags-ID: V03:K1:G2GyXnn3Zwh/QYqtFMsOkMYpRuVMQ4v/kMkHXtohYOt7RKWaI4A /81+jXc9nkOHe1w27/aZT02trRqYGtZ4nM0uzEoYp8LJAmqu3/OpiOpYWU06AzsNMV7af0A UNFaGNvaNNDPkZk3WW71gUXepqhDD5pAm+cxils33KvxdBEcATb+/QABi9pvtGA15dMeJ9B unxtsWK3u7h/c5HHi12IA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:sFmj4ED8aJA=:aPafxu1SZGneMoNuqc/T79 j+n9PHCPmJgCujp7VOBCvya0nMAyEAeNAIvA6pPpv75V5XU+6BD2DZWGBW+ieekoH/0f6X5Hr kEg7nl2lByahXH3hrW+CbG81bOFUDRCzIZQEkQjM94CGm2AjHbu/fnRdlRo4Bxlnpwfjzpxkr DVCrmtfcGchFujbTmxR2uoe1OjXPARBPYWYaVCGaRKH4ETWyplsuV/OsL9KBY0qSLyPNWzLEX Tas4B54slq/zCnztlyUOFsdab9Ti2kzWGbAT7o75z5HAE5mQ/jsnnvzvk45mhULHHngUFRI8n si89NZ5bQBxgjVDUir97WTxVzcLxnfTqi4MQ8MmtXq7ZKn6OT31O6Ck/RiVKEeMCRf4bxzFnp EdQRc4LW71xblm9raSI523oQ/yQ63C56S6PZx+Kt6cmONsZlU8hzPzEr/U8YM+SyxQtk3eppT TcagoZUTuzr/HYgU/wySIU2YBEhq4qmqYZQtBDs+UoHRyboaQYM2qqGtQ0Fmz59uVWScJ6IaK Afhjt3xzuEHzLFKi0S0v38vgUQonLrxhNRjWHuyb5HUO09UWwlLJQjRUQMHhOoDsvfdnjsR8p nL3dT/pLm0MtTpxSMa3bBRihXLy/4uFc7iZzZsVy1WovzBO65lK0mrL6cjfCVdelcuNPmlFPq WKukXdgUoMtk83VJI2ix3p/YunEtt89z+MgBNDEBsGFIPA63umYr/xu3HruRPQ0vsyawhVNRw sgHypuSLgt7FxVRxDySA9BvfrERrmql2/LGDy/wGvgPPk4rJXLOVgWKCOY9fFQX0ciLHEH3i4 WP1rKkWWI1caVhlBOxMjfTDnnp3AsmhFiJIUeGk7XF2qJxtK8p+BQMhsBKxF0TGoPRQyz3xYU JYBBE4xL37AyJirDyl8+5udh9+HCBbPFcLpq+bBTk5M6VEas0gq0851IsZmBe5fqH2IKvA5lu wZK0dYCOkzQ== Subject: Re: [Ecn-sane] [Bloat] [tsvwg] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104 X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 23:30:58 -0000 Hi Jake, > On Mar 21, 2019, at 00:11, Holland, Jake wrote: >=20 > I think it's a fair point that even as close as the non-home side > of the access network, fq would need a lot of queues, and if you > want something in hardware it's going to be tricky. I hear > they're up to an average of ~6k homes per OLT. Except they state "In practice it would also be important to de- = ploy AQM in the residential gateway, but to minimise side-effects we = kept upstream traffic below capacity." meaning in addition to the = OLT/BNG/whatever shaper they also envision a shaper on the CPE. And I = believe there is ample evidence (in openwrt with sqm-scripts) that in = that case the downstream shaper can also be put on the CPE with = reasonable success.=20 >=20 > I don't think the default assumption here should be that they > missed something obvious, but rather that they're trying to > solve a hard problem, and something with a classifier has a > legitimate value. I agree, except ECT(1) clearly is a very approximate = "classifier" as it can not distinguish the L4S-ness of CE marked = packets, which affects both the AQM part which will treat non-L4S = traffic as false positive as well as TCP Prague endpoints that will = mistreat CE-marked packets as L4S signals even if the CE mark is from a = TCP-friendly AQM. I note that neither "=E2=80=98Data Centre to the = Home=E2=80=99: Ultra-Low Latency for All" nor "PI2: A Linearized AQM for = both Classic and Scalable TCP" seem to discuss these classification = errors and their effects on real traffic in sufficient depth. It is one thing to soak of one of the last few available "codepoints" in = the IP headers, but it is another in my book to do so and not reliably = being able to extract the encoded information. At least from my layman's = perspective I wonder why this does not seem to bother anybody here? >=20 > The question to me is about how much it breaks other things to > extract that value, and how much you get out of it in the end. That is basically the core of my question above, how much do you = get out in the end? > If you need fq and therefore the only viable place for AQM with good > results is on the home side of the router, that's got some bad > deployment problems too. As I state above, even the L4S project position seems to be that = AQM on the CPE/router is essential, so we are only haggling about how = much AQM needs to be done on the router. But from that perspective, I = would not be unhappy if my ISP would employ a lower latency AQM solution = upstream of my router than they currently do, sort of as a belt and = suspender approach to have my router's back in cases of severe packet = inrush. Best Regards Sebastian >=20 > Just my 2c. >=20 > -Jake >=20 > =EF=BB=BFOn 2019-03-20, 15:56, "Sebastian Moeller" = wrote: >=20 >=20 >=20 >> 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 >=20 > Nah, there is this GEM: >=20 >=20 > 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. >=20 > 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. >=20 >=20 > Best Regards > Sebastian >=20 > P.S.: How did the SCE-Talk go, interesting feed-back and = discussions? >=20 >=20 >=20 >>=20 >> - Jonathan Morton >>=20 >=20 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat >=20 >=20