[tsvwg] [https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-10] Question about guarantees between sharing of the two queues

Sebastian Moeller <moeller0@gmx.de> Sat, 09 November 2019 22:37 UTC

Return-Path: <moeller0@gmx.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 71E03120116 for <tsvwg@ietfa.amsl.com>; Sat, 9 Nov 2019 14:37:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Status: No, score=-1.649 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_NONE=-0.0001, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id RY-O4eB_z5xO for <tsvwg@ietfa.amsl.com>; Sat, 9 Nov 2019 14:37:27 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net []) (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 92B22120090 for <tsvwg@ietf.org>; Sat, 9 Nov 2019 14:37:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573339041; bh=nhF+RDBzrqExHrgTybXhK4CqAVRsRJ/Ix2wpcHD+as0=; h=X-UI-Sender-Class:From:Subject:Date:To; b=KJC7uFJMg5otVApHsZIVrUdHMicchJtSWAqgjle+CtjrElRq/1GDv7kmQN/b1D0FO Ku+qiZ0TuzItFvo1mgqTtMkOBfMGoNmRaUi9rrp9O9ATo59VQ07SE8kkpNZAoFHXEM pBlqwC1UTwJKT67SkAsQjdhM7HFoeq6MboPhj0gI=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([]) by mail.gmx.com (mrgmx004 []) with ESMTPSA (Nemesis) id 1MA7GS-1idyKK34oM-00Beji for <tsvwg@ietf.org>; Sat, 09 Nov 2019 23:32:14 +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: <742142FB-6233-4048-931B-EE2DD9024454@gmx.de>
Date: Sat, 9 Nov 2019 23:32:09 +0100
To: tsvwg IETF list <tsvwg@ietf.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:O2QQEwN0HEAaiBGhzUirn50SEBNZJrpNrDCXWj8+YzAAFZUQtdl isNeklwjUi3aotZIKxuxBPQakY1xP9ORtFIZ6UQAoJRU9p6YsuYcjpJcdghS017iKkGBJCT 5rsBq7LjmahDgFGEfLk8sgb2Urrzu9Lb7ONumM92W4Fh3gG3rMtTVboHdMRtl2W4xHMEX3M kurlqAkPg3aP9Ok73G5jQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:sgj6C2NY87s=:RR85HK98mjP0CYypUueXXd qhxYPw7WQDxGVZWSYkcRs+3UZwae+7GRJ3FkOiVbxGoBgsPIOsY5YAcFPG8rl5ISX/ks0V4nO rEd2GGnd4vmP2a5DOjE0e0kBNMYkVnD6SV3opLZGEVub97blRNcl01y7aeoBuIqhL5kK5pGHR ax5MJof2VvnpcoHicwZfg42puUspjv6dP7AScChFrkyCyE8iW4Q6Z/+speCfIKyQ2+R8AjiwM bALm7NI/yRu53kg8iw/feLUiR2EmapINupuzCAcsLmPhDPZZSt3H4wqIPnF+u14hZOue8gfi4 Mx8CAg0LmTYQzr3uK7FGJXyDwgrd96aWTh9dnp66VaO7kkC2rT1vMgyIsON/x+AFGa6VkdT9u QS+b/5qVM9My2kUCOOEynHnwJ6/fSRHgaoevkWxikQhn/EnvEvlje4N52NRVFrelupB/oQotT 3oS8BLMLoLZSaEIh3tLnsvF7LsWwijVBWSFE1j8IumFNNlilOKjychsV+88E7Zs5leshCJMlT 9W+lcrauc6IE0/FFxYItDBDp6U1O0ps199HOViEq7b3qFGD5xCm+N4xaYd6jWsqFT5Lo6oliI HdOh9gzrdYRflaa4ekcixZAX3cl9Xxplze3tTL5kdp7dUsSUhHN/1zhiaoDYRsSyAuf+cbVct ntcmCgX08ayUkDVOwU+SrTMbAAnCj0AES6rJt5ai035doaGYYhU4cpYWlRpRg2FeJ/cFdXFYi fleIbFFKd3o1qs6OQeZX47m1A1gbkONhr/J6KHLOVLYZJezTf9zgLibUvMkp2/Fb4kI+Pj4oO 8HcwfBhvRKOIrPo5lbrCIJgZqJIF4MYQ7yAwmH5yqN0J1F2xB1+8+JEOB/hNPs+ZdDm7ftAQh z7rXiPcKM9IHM6EaorlvXg1egTFCCaSSJ/qgz3UQoxSfQ9qNGU4hPCgL5xC2QjT/RWBF/VUPE er9XSgJJtKIj3Q25nmGTWMy5ky/cwYFWXN9aK9qVT6IeZcI53f02OsO0ndbC+8pRmyhyP8wgT YKvozHQUtny/79iKhj6+ea2dactCGLNEup5YEmjiV2hq3LlaY2onEHYkpkVtDuH2T7oTLBwon ow+kBdTQY/t1JUOH37yhXr0GuPELwIAjpqaSAusXWkonvT5NSqQXxSSGJJpjBmEMmf8jf9UXI H2V8LPHponTH9M1t6yNLykiWubhLXESDi4OLMfb6CMqm0TyUV+Lyh4MVwuHW6rb/8GHw7BUCh vwmDAYGQLgGvg1F57ecVu1HFBWJjctiMUvUsTdTQj5Ue1Io2bvhB/OUz+NTs=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/LN-pMPXG3OsmIr50-98gO6hAf0I>
Subject: [tsvwg] [https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-10] Question about guarantees between sharing of the two queues
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: Sat, 09 Nov 2019 22:37:29 -0000

Sear All,

re-reading https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-10 I notice

"Analytical study and implementation testing of the Coupled AQM have
   shown that Scalable and Classic flows competing under similar
   conditions run at roughly the same rate."

And later:

"4.1.1.  Avoiding Classic Starvation: Sacrifice L4S Throughput or Delay?
   Priority of L4S is required to be conditional to avoid total
   starvation of Classic by heavy L4S traffic.  This raises the question
   of whether to sacrifice L4S throughput or L4S delay (or some other
   policy) to mitigate starvation of Classic:

Sacrifice L4S throughput:   By using weighted round robin as the
      conditional priority scheduler, the L4S service can sacrifice some
      throughput during overload.  This can either be thought of as
      guaranteeing a minimum throughput service for Classic traffic, or
      as guaranteeing a maximum delay for a packet at the head of the
      Classic queue.
      The scheduling weight of the Classic queue should be small (e.g.
      1/16).  Then, in most traffic scenarios the scheduler will not
      interfere and it will not need to - the coupling mechanism and the
      end-systems will share out the capacity across both queues as if
      it were a single pool.  However, because the congestion coupling
      only applies in one direction (from C to L), if L4S traffic is
      over-aggressive or unresponsive, the scheduler weight for Classic
      traffic will at least be large enough to ensure it does not

Recent testing has shown that such starvation is not a theoretical consideration, but for short RTTs rather seems the normal case. This brings me to me question:

Question: How to fix this obvious discrepancy between the claim of "run at roughly the same rate" and basically only implementing an anti-starvation backstop? Either the claim needs to be adjusted to Scalable traffic does not fully starve classic traffic, dualQ needs to be fixed and the "backstop" needs to be changed so that under saturating load, both traffic types truly get ~50% of the egress capacity.

 As it stands IMHO the observed sharing behavior seems insufficient to recommend using dualQ on the wider internet, see https://l4s.cablelabs.com/l4s-testing/key_plots/batch-l4s-s1-2-cubic-vs-prague-50Mbit-0ms_var.png for how  dualQ fails to properly share capacity between a single TCP Prague flow (1/p) and a single TCP Cubic flow (1/sqrt(p)) at a short RTT, unless approximately 9:1 is considered the proper share between L4S-style and normal TCP traffic.

Best Regards

P.S.: I have brought up this point repeatedly, because I consider this to be important to address ASAP, and did not get any feed-back yet.