Re: [tsvwg] L4S expected sharing behavior between L4S'd two queues at longer RTT if the L4S transport protocol gains higher RTT independence

Sebastian Moeller <moeller0@gmx.de> Thu, 21 November 2019 08: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 51BB9120048 for <tsvwg@ietfa.amsl.com>; Thu, 21 Nov 2019 00:05:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Level:
X-Spam-Status: No, score=-2.349 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_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 SQXp61pwKavV for <tsvwg@ietfa.amsl.com>; Thu, 21 Nov 2019 00:05:07 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0F7912082A for <tsvwg@ietf.org>; Thu, 21 Nov 2019 00:05:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1574323504; bh=UYuGKtRoKh169ZccdHRUshJY39iV6mm0XWSHnKzSZGk=; h=X-UI-Sender-Class:From:Subject:Date:References:To:In-Reply-To; b=Rb6pfeSljHBg4vdvbm2sGaNQSw6c5CkPsiLhTjLajWe3W9oHrvkTjVtazct0vyGwE 46eBbIBX/sB/GPw1ZaAHNa8DH7y441Q694IebmQDcMDfP/v2/U+xT6+W0VDsmkTb2E +hb637gEaNPJJmr7nCLBtjDO5XPmf9XEvB/0B2QU=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.11.12.33] ([134.76.241.253]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MMXUN-1iEeoG0lpn-00Jdce; Thu, 21 Nov 2019 08:58:51 +0100
From: Sebastian Moeller <moeller0@gmx.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 21 Nov 2019 08:58:48 +0100
References: <HE1PR07MB44250F3C4E6A744DDCC3DAFCC24C0@HE1PR07MB4425.eurprd07.prod.outlook.com> <ad7b763e-b3dd-36cf-a9c5-7de99476babb@mti-systems.com> <12ED7632-5E3E-4EB9-B65E-8A8324067C9A@akamai.com> <5DD4BB25.3060700@erg.abdn.ac.uk> <5658232C-07D5-4C89-B16A-58A928332FC6@gmx.de> <HE1PR07MB4425D989D4A266C73331FFA5C24F0@HE1PR07MB4425.eurprd07.prod.outlook.com> <CAJU8_nUK5cZLFE-0UBzf0a7T0hC7C+CpCsUy_+ZU_p4oxW9BmQ@mail.gmail.com> <HE1PR07MB442560D0715BC921AB9B7FE3C24F0@HE1PR07MB4425.eurprd07.prod.outlook.com> <AM4PR07MB345968E8C665304DFBD5B11FB94F0@AM4PR07MB3459.eurprd07.prod.outlook.com> <228d061d-f25e-b350-4a6e-2aea827a590c@kit.edu> <e5a7ed0e-90cb-10a9-c55f-0ba8d2144ecd@bobbriscoe.net> <2AFFF85C-E66F-4CF4-AA62-6F7249A16959@heistp.net> <357abfd2-2d93-b4cf-355a-71a2def32b15@gmx.at> <E175102C-CD01-40B3-9807-3DE0C2DB8277@heistp.net> <9d6c1ce4-d192-d016-8418-c26a09e25517@gmx.at> <716AA405-6C3D-4AF5-9C7A-FEEC8A988CF4@cablelabs.com> <6803E804-6F4F-4811-97CE-3DA058896AE0@gmx.de>
To: tsvwg IETF list <tsvwg@ietf.org>, "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>, "Tilmans, Olivier (Nokia - BE/Antwerp)" <olivier.tilmans@nokia-bell-labs.com>, Bob Briscoe <ietf@bobbriscoe.net>, Greg White <g.white@CableLabs.com>
In-Reply-To: <6803E804-6F4F-4811-97CE-3DA058896AE0@gmx.de>
Message-Id: <0128318D-6AE2-4FF2-B38B-94D247F54B68@gmx.de>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:cBMA+HD7ucvmAWoGnzmPWczxAq/J1VWJJ5kVN8OnD/eaikOWeeg uvcY/Ue4PuT6ZESJUj3HZfV76PZ4x9PRSf1GMiQJ/khTSRnISzVZWPuVYMAq8l2vgnSNRUg yB6qDiUEJFjmNQ5R5hJ1uvbSdzjHwX3JTs+FFkE7Mqo2hypGuH+qGJQ/Ja4c2PyvzeAvATA LnXN25CvQ4c2QFjnCTnyw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:dnHPXkx4ED8=:j9w9Dg/edHGbKs7KQi0TZB wJnPIhz+v6or+I8xd336xCDe8Hl9o+445XQexho2gyRaqGbSDAG1jiUSQzE0cicbJvJ6R/uz7 LhMqiBmmx+FnYKJ7psOq/5ZGC/vZBECwbOTMJAx+fJR3pV0gwqIxd/HEeP/KVk4pGLpKHWuZ0 Vdbie4GLdMFYPBSXEIPIZojJOl2JPcxm2suMoiU5cHLvbU7jSPcaXn86891pmboWzsFOEUSYz /Li00N3+Z3o8ALjbSb+fwwCvT2rgNkLDQLDja2iiocvS7OXQ0Hz6qY/HTm6TWlVtKoH5b23pj 9PLxE/Sk783C+lU4wbVDTmhmKQ6YaYTpCuu4XYih7vHJ/gh/RcRKvFPsHRl+AMrEDVPE/UdjR 7TvcDfg/FirujbiUUGPS2GNDqUOT1jK6/qGWcB0tqrOOw6mQvXx2+9JAFdbMFWyhxSVfGByUg sacA9VlW0LbIs6y1tBrLbQweFvFLefU3chK9+LhBkmmgvWb878wienNUQlv6F5R1S/K/k3D0Y jrkDYXeYSJ0nmF1M1uGUoz7PtnCuA5El/d38HnN5CyrFQng8eAk1GGKH6XFmwT9Ry0MWocB34 LiACyzErj16GbuOpw0ULy3pGI/ySYEH05a7lUiOlE7NjzSx1kRGkHpDC88mEGe+KoUhom6vi3 Y6XSL+p0YOr32/XkaiIqgxLzlXyR43D3Ar5TUC4NcL1+GylAKCswRedEwHduCi0s/LFWGvMiv zPp2nWHfn949Rdf7HYluZtVnDG1jzlVhisY0jKBf4p/X2MKDT0QPe01do8j7g4Kee72G39y43 cYUXajw6Q2fGeVIVMkkRfSQKVYtdaGzIFIIU1x+Oauad4n26MCjIXdA3RE8nPcttxAhRWmrCL IG4qiyeO+kKD7goz5p5C7G9r77m6IKzCpdwEWEjGp7M7B1DzwW8FVOjRnB6qA3VRkuXwqzGOz KeZPIlkeQJW5rhmaN4qC5on3KYzKZrLfCohrxgoGM/nKndjTuADO6HNYlllSU6yRp73kLbAMw 5TxAZhTde8XOcRcyGsy4PzsEgtC/K5cHzn3aJtYWEmSb0kGIcPu9ZzupUDka3FHHJXMJnpChN /kisruqGTvpQIUU0skDTpYCVRDDOeD9mY6QRuxn8Lwc5avYnCtIh83OXSpuQN4tXzdhiS08Xo TkFHVCgn5+vIQcZCsGWuqIY5rNF2/gALD9B4Y/oW3z936vIURumrWqWmpGO6/vaPPAyZgAWSw uakobUznDjrgMhtzRsoeLLbjqbYnVRbMIpfx6pw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/vK9Zja3UHNpbeyXBWqiCD6nfLuE>
Subject: Re: [tsvwg] L4S expected sharing behavior between L4S'd two queues at longer RTT if the L4S transport protocol gains higher RTT independence
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: Thu, 21 Nov 2019 08:05:09 -0000

Dear All,

I have a question I want to pose about interactions between the dual queue coupled AQM's sharing behavior.

We currently see an RTT dependent bandwidth bias to the advantage of the LL queue from ~5:1 at short RTTs to ~3:1 at ~10 ms RTT to mostly equitable sharing at 80ms RTT.
Some of us including me are uneasy with introducing such a sharing system in the wild, but overlall, people on this list do not seem overly concerned about this behavior, supposedly because short RTTs are not that common for the expected roll-out? (I disagree with that view, given how many important traffic sources have been moving closer and closer to the endusers, like CDNs and the talk about moving even computational services closer to the edge ("mini datacenter in the base station" not sure whether that is more than a phantasy)).
But one of L4S's goals is also to reduce the bandwidth dependence on RTT for L4S flows, so that L4S flows compete more evenly for bandwidth with each other in the LL queue in spite of differing RTTs.

So here is my question, what is going to be the effect of such decreased RTT-dependence of L4S flows in regards to sharing behavior with flows in non-LL queue at higher RTTs?
Put differently, will decreased RTT-dependence of L4S flows make the sharing between the two queues more or less unequal at short and long RTTs?

My hypothesis is, that if a long RTT L4S flow can better compete with short RTT L4S flows, it will also do so against equal RTT non-L4S flows, so I expect that unless RTT-dependence is reduced for all flows independent of class, this otherwise positive change to L4S's recommended CC behavior will cause even more interference with the existing internet. I hope I am wrong, and would like to ask what the L4S' teams assessement of that issue is, and that there might even be data demonstrating that my concerns are unfounded.

Thanks
	Sebastian