Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs

"Tilmans, Olivier (Nokia - BE/Antwerp)" <> Mon, 11 November 2019 00:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F3DB12007A for <>; Sun, 10 Nov 2019 16:38:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 42NKyzMSAFUX for <>; Sun, 10 Nov 2019 16:38:14 -0800 (PST)
Received: from ( [IPv6:2a01:111:f400:fe07::709]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5170812001A for <>; Sun, 10 Nov 2019 16:38:14 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=XWY49C4aQpPnyyYv2wSYVwfz2XgULnDGIUEuoF2v0BN+kuGANvy1Qo4c+q5GooZ22mPUF1nTi3yrqFjdqJ6wD+unsDW1mkdEdYTLc7hhjVQAQmlRkxTkvDokMPyASOBKK6zbMH6QrUmtM2UIKTion/Cetsuo4sTGLTCvRlEUcDYPPEzr/xgfDJ+PEStvKHwJWUFygOKtJ1+ghtaDn+Oh8x2iuQnvT3g1nh/lJnW1s/pcgMcC0NcWoZbpJDWlZgvqgFRAd9BHSvyIVJWVId1zQdgxYiRUnq9dB1TjhXQRgQQejABqsrthoOrdCuLfzhLKiauxTjwnAIrgvDoHOeLIjA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zej4qrprk4fpK6gtT2qccbtn4KNCGxi9S07vorg4v0Q=; b=n58GX/MEnwsc0WyVIoeiDJXMlDzxeLxjqhitq7VVyp1ALqYHvudacKuqNfOlKh+hYPJX1iCueGUfE6KztGRjJ5xTPmNVG6zJSKlcpaV6jWvvZ9U1VPC0jz2ocE/+DE4TWDO463e6v5gHT15YuDw1OCXO+ifnqq2it8x9v2j+e/hv1mdZIReUqF1WfHpqYHub4dVmmW4dM6R7eLTp/UJ58wqtNFokVIqBgcvsqO2BcBWSixmcGQQnFjSQCgm9yl1Bbq29KCk/G28u9u9hj0ufKi6tb4putzNVGd/+FQFlzf0WXeVQaY1mWYxFOdjU6hHbJWhrxxdVuags5vZKipg70Q==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zej4qrprk4fpK6gtT2qccbtn4KNCGxi9S07vorg4v0Q=; b=qcXUGkCd63BfdrcgTCwt8MMdX30uxRtBbjvstf9jTblvIDy7aXLwb7BWo4VrOoxQyZnqzAqBkNcqfAne5P8lC7Yr4uYEiUWyF7rd8JqBy2yk8MOtNOtfs1yYHK/VxYD7yRfNykWmylJ2ItUjBSihEap0yTodzBJcpZz42MWzcpA=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.15; Mon, 11 Nov 2019 00:38:10 +0000
Received: from ([fe80::61e0:ae6b:e9c9:5f]) by ([fe80::61e0:ae6b:e9c9:5f%3]) with mapi id 15.20.2451.018; Mon, 11 Nov 2019 00:38:10 +0000
From: "Tilmans, Olivier (Nokia - BE/Antwerp)" <>
To: Sebastian Moeller <>
CC: Pete Heist <>, "" <>
Thread-Topic: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs
Date: Mon, 11 Nov 2019 00:38:09 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: [2a02:1811:537e:6d00:c51c:7ee2:36fe:ed51]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: cafde6ed-8f9b-4336-1354-08d7663f6d67
x-ms-traffictypediagnostic: VI1PR07MB4526:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0218A015FA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(366004)(396003)(39860400002)(376002)(189003)(199004)(14454004)(446003)(86362001)(9686003)(5660300002)(316002)(8676002)(81166006)(55016002)(6306002)(966005)(81156014)(11346002)(186003)(486006)(53546011)(6506007)(6436002)(76176011)(7696005)(6916009)(71200400001)(71190400001)(2906002)(102836004)(54906003)(52536014)(305945005)(74316002)(25786009)(4326008)(66446008)(64756008)(66556008)(66476007)(478600001)(6246003)(6116002)(7736002)(66946007)(33656002)(76116006)(256004)(8936002)(476003)(66574012)(46003)(229853002)(99286004); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB4526;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: oxvIK5O5lp0knZVp5vlcGwJs3De3rv/+EkY9KPXWdTwwDkQYXS4dHF+VntzqFWgHMq8EXa/Na5wBvhK5Y0XfXoM5A2S5kZDzxiIYJvh3uCkrvIpCuMJuKgiL6Z6poEAqIvvGTNx3vEUKf48g2zTjS/8h6HqoOoS45cSEi0uiBXZeLczstVICF35Qnf25PpF0+W1wNng8o1ykmd84u1lK4S+IjjtdLAMsL959sAsAMm2PLTItPS/Yi2H1hbPYKqUoQfU6311LFAC5ooN8GNPwFzUXPWbM8QZcl/LnyXT9ElsVyjroqoaOF+aJ5lkHIWxXPzWNp75SMD7LvtQwQVP/hW1RwU1GTEktcRbmtjpHNM/U/Ao7cMAFPdnWlE93FbsEEL4GHyjG9GJAHG2hhGP/TxubYla1561U7voJsIJY2XWMMWvOqyFBAWScpwU82lln
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: cafde6ed-8f9b-4336-1354-08d7663f6d67
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2019 00:38:09.8870 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: JPPzzLmRO/LBfjpsoCibGzXs4yq4TwHOlXHU8zB2akmR7Rih1Im40qCg0cnz4iLuLHUkQf3rdWqksMubFGu9HVcptarINZz6A+9wTlW9/QZKw4S01Nvc5tBp9qEZ2LEn
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4526
Archived-At: <>
Subject: Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Nov 2019 00:38:18 -0000

Hi Sebastian,

> I wonder how you intend to deal with scenario 1, cubic versus prague, where
> prague for short RTTs pummels cubic throughput, quite unlike what one
> naively could expect from reading the dualQ draft:
> "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."
> at 0ms RTT prague is ~10 times faster than cubic, and at 10ms this still is
> around a factor of 3, only at 80ms that gets into what I would consider
> "roughly the same rate". 

I had the same question a couple of months ago when introduced to the dualQ.
The short answer here is that both flows do not compete under similar conditions:
they operate at different RTTs, which varies depending on their propagation delays.
E.g., at 0ms base, L4S flows see 1ms on average while classic flows see 15ms; at
10ms base, L4S sees 11ms and classic 25ms.

Given that flows have different overall RTTs, but are subject to the same marking
probabilities (albeit tuned to their reponse, i.e., linear or multiplicative), you
instead need to look at their cwnd--which must be equal[1]. Unfortunately, eye-balling
this from flent graph is not super convenient--tracing it, e.g., using eBPF, is
however straightforward.

[1] The 0ms case will likely yield a smaller than expected cwnd for L4S, cause by
10% WRR protection kicking it and artificially increasing classic's cwnd (as 1ms
vs 15ms would yield a 15x throughput difference if it was reno).

> I now wonder what happens if you pair a short RTT
> (say 10ms) prague flow (simulating traffic from a nearby data center) with a
> cubic flow with a typical internet RTT (say 80ms). My prediction is that
> prague will dominate cubic similarly to the 0ms RTT. I guess this is coming
> from the default 1/16 scheduling weight for the normal queue, do you agree?

You can disable the WRR entirely (i.e., set it to 0%) and the results will stay
the same (except for the 0ms case...).


> > On Nov 8, 2019, at 11:41, Tilmans, Olivier (Nokia - BE/Antwerp)
> <> wrote:
> >
> >> Hi Greg, would it be possible to merge any changes you’d like to include
> in
> >> further testing into the testing (default) branch at
> >> We’ll evaluate what we can with what
> time
> >> there is, but a prerequisite to that is making sure we have the right
> >> changes you want tested. :)
> >
> > Hi Pete,
> >
> > As mentioned at (link
> > at the bottom of the page Greg linked), we ran your full set of flent
> > tests using this tag:
> >
> >
> > I doubt we'll push anything else on that repo for the moment being
> > unless someone comes out with a bug/fix/improvement.
> 	Well, I would like to see scenario 1 with unequal RTTs between the
> two flows, like prague@10ms vs. cubic@80ms, and prage@80ms vs. cubic@10ms
> (and the same for cubic vs. cubic)
> and I would like to see tests pitting 2 flows of one type versus one flow of
> the other type, like 2 cubic versus 1 prague and 2 prague vs. 1 cubic.
> Best Regards
> 	Sebastian
> >
> >
> > Best,
> > Olivier