[tsvwg] [tsvw] regarding L4S issue #22 new defect Deployment feasibility

Sebastian Moeller <moeller0@gmx.de> Mon, 02 December 2019 21:07 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 96206120018 for <tsvwg@ietfa.amsl.com>; Mon, 2 Dec 2019 13:07:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.722
X-Spam-Level:
X-Spam-Status: No, score=-1.722 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_MSPIKE_H2=-0.073, SPF_HELO_NONE=0.001, SPF_PASS=-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 fDRfxOGJmbIS for <tsvwg@ietfa.amsl.com>; Mon, 2 Dec 2019 13:07:09 -0800 (PST)
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 ietfa.amsl.com (Postfix) with ESMTPS id CFD2512008C for <tsvwg@ietf.org>; Mon, 2 Dec 2019 13:07:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1575320825; bh=U4QmRp3IJ62QAvFS+dwmLnBaHG5U1hDhRUt4mVrJdko=; h=X-UI-Sender-Class:From:Subject:Date:To; b=MlC4F+absFKz6vqPRRAByBWtSQweGe1DvinfhTxUjcz9Y/3QyH5xoi/aliLW0gi68 wuxMYt3FjV/cq2yrp2O74j8czdZGdFmvXGVBf1bs1dqJ8/9Ui5dyAEy5ecrhluVzyX +WklWsjrRzZIydpWd4H/XW/uwlir+NLEOvrlax/E=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([95.112.137.37]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MKsjH-1iL2EW03ob-00LB2c for <tsvwg@ietf.org>; Mon, 02 Dec 2019 22:02:01 +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\))
Message-Id: <D01A1781-1436-463D-A348-71CCBBB6984C@gmx.de>
Date: Mon, 2 Dec 2019 22:01:59 +0100
To: tsvwg IETF list <tsvwg@ietf.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:ygzBwh3GHAxc/Ctm7ILDKfLOLRGbomFt5pV1O6wYPLJpvRijRRy h35fhDNQMSOnXMFu1S0jfJPX9PXdFS7AE/T6iS8jmPQ4F7cUNr7cq1mnEgQv/YP0qlCY8Sn Duulqu7dXgx37jmxT7YFFyMKSk+UAzhkyTohXE+U8fAdy+P+TYscEurMxU25WUzbZYKZHMx GUEtK3P2sksVo9sDhLFsQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:SXOYD+He53w=:yyjSc7jJIuFZz5uVf4AYkL Bw/VkDq4Ja9l8PQsbEMP7kO+k973VFrkkKUn3sYEhodT/FFI8WYpeaSn5luAr8WBgWwh7QxbM TpPSO1R9nxPxytL6FlCufiouptRNxh0/K6b+HRc1c5QwM8ClpPnHQC03ACKGrvehZ+SaDjJix Q+RQvkrOBDE6TuGm9E4aoRbOw8dcYk22iDTXljmaiqMU5Qc0yoEAiOPKDRLxMoiwNwUktOkLx XI1ULaE3GLB0hb0J7+Qacre332mNG9HQ+z9IIfP75Sdf5MkFprVp2Cv6cRRrDwqcfeTGh6Wul MYkI9d7+gLZUDafjKkS4iBLvIh3oqrr2Xn+8nyR+54p5W36yvNf5F8x1oSeF6BVMgpBgdbUG6 6hkCCabO/RxBRfUj+zpPx+DgHbohAJg6GrXe12WFsrkKRSlk1PCho86PxHDL4Ly/jrFtt/9+E bzxSLgVxTdESfGHxiblCqqx+ahJhTc8UKS5urm8PjpKVqr16Pf6REFdpmElXTJd30TVUvTdQy AjvBJRmt+b4YApMfaHCOi35GEB5axd535d6TCxoMLWHl3Vit/6jjIrovbXBTVYB4kc0QftCs0 vQ16LYlG/RQkftGtROYD7iAvtHkjW8t8mf3UcIZ2BEm7SmWquyw+G4a0+NJkTpLbpPa6PTTd8 ZQm9Z1kMjP36QjCJuhG8xmg1TNawonEiEYDYMgzMn/e6Ii6aJ67YPI/L37liyAHKhxeuM+oOP /eoSgL/Vx/EsdEcLpxP6yqPvTCjZsqRaNQP2T5eZvpCod+0iW68HRDTCwcDz3WE+S64jBvCwi qGfGu7cJRni8MfA8wmH5L6aHz/QMUjSmn7wRjpyeePsPNAajezu1GICj7NCiMu+5/AqhnZtPb VrVLcf6EPSb9qIECEHZ9u1YBP1Rede97U5WXFmozbuHMwpPu3uyM4sab67la7oGBHgzOjktjI iNp3O1tz+z1eHxhAQoE/UXaRUVyrGW0izvuc8KBiSTftiw3f1rLRBckInVpW1+qV5bs7qZU5d tvmHwrSHRGrkjLZK0PP1H+EWtrTgRcc8SMyMP5vog1/hJegfQGq7Afs5OP8BQZZhd2LA2ujHH S1zc/i7qiX1PBh1R8ySsN1NEjhEv2inP92LyeFQPtgomJF7KVs/hECXCy4jqXfFXERzFWP8rM dF2gC7dsPxiDrTUbRygdFfADRLRYGyqrtGEiQI9M921BeaOx2RR3MSL8NHCxXux4w9Z0K+HR+ YNpOiXcXwOxdQc5rvGuTlNoGX5uTmWD2gP7i7N9J8Nn3/qgpPlT1Pv4a8uzo=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/RA0_cBOzRzSGb6rYsDJBxcVWz3A>
Subject: [tsvwg] [tsvw] regarding L4S issue #22 new defect Deployment feasibility
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: Mon, 02 Dec 2019 21:07:10 -0000

Hi all,

I just had a look at the issue tracker and for L4S issue #22 I see the following text:

"Issue #16 is the only identified incremental deployment issue. "

And I am not convinced that is true. The fact that L4S's designated sharing mechanism the dual queue coupled AQM does not robustly and reliably share bandwidth equitably between the L4S and the standard queue looks like a relevant deployment issue.

I am pretty sure none of the end-users exposed to L4S will expect that (short) RTT L4S flows will basically throttle all other standard (internet-size-RTT) flows. A naive reading of the L4S and dual queue RFCs gives the reader the idea of equitable sharing between both traffic types, which already seems rather generous to the new comer L4S. Essentially with that prima facie reading, a single L4S flow might take the same 50% of the bandwidth as an arbitrarily sized flock of flows in the standard queue, giving L4S a noticeable boost given the relative likelihood to encounter L4S versus standard compliant traffic sources on the existing internet. 
But the truth of the matter is, the L4S reference scheduler does not even manage to guarantee that equal sharing robustly, as testing of both the L4S and the SCE team confirmed. This issue is especially relevant with the internet wide scope of the desired dual queue AQM roll-out, and can hence not be solved by affected end-users by imply not using L4S/ETC(1) flows unilaterally, and the fact that end-user to CDN RTTs are getting shorter and shorter.


I would like to kindly request this issue "failure of equitable sharing between L4S's two queues" to be added to the issue tracker and also being addressed in the L4S arch and the dualq drafts, please.


Best Regards
	Sebastian