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

Sebastian Moeller <> Mon, 11 November 2019 08:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5947F120885 for <>; Mon, 11 Nov 2019 00:48:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.349
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uPpY3Ibsoqg6 for <>; Mon, 11 Nov 2019 00:48:56 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7761712011F for <>; Mon, 11 Nov 2019 00:48:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1573462129; bh=sZiRFjdV/IZMsn/84+5qYvaT2vloUtcSRy8pIJkObbk=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=Od7sLDrHqxkT8LJ/xA5j4fLN0UKfXMYypw420SR0/gP20h8dlD1tzvd8XlSWbuLtt v/xWskN459mUs0wJ8CwTBscoy2CWUlzLmrd74vrr3+2Ynvabr94RR85k+QJ14ZNjGv B8kCqe9E8qiAWV4e6cFawIjCKC/a1VqzluHDUv40=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx104 []) with ESMTPSA (Nemesis) id 1MWAOQ-1iO68Z38Ys-00XYn5; Mon, 11 Nov 2019 09:48:49 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <>
In-Reply-To: <>
Date: Mon, 11 Nov 2019 09:48:46 +0100
Cc: "Tilmans, Olivier (Nokia - BE/Antwerp)" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Dave Taht <>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:UiuCNZaRrI+wqTc/bmXlhv+CQTEj9ZC2Yq6fI9KomOFC+aooziP WcwU4/1JeqJakhHKzz/mrdZsX9uENIkyHaYVnt3aAnp1VEc4lmiF4DqKBTzvHFKMbqWz6FL guysM3WogfDajzsnl17SfoJd6ZOw5d25lO/kxXJOnUdh+u62nAJUaO1uiD1V6dex2TvC+ut vO2DPxEWjXB/Dl5q6yBsg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:8v4JjjrZ0jE=:QrxOCGt8SwD4Vh5FW60+9i vh9Wt9JEjFpIazUUqWC/oBeHCOL2/zgMItg6Rs1vUU6g1nB6dsT4r2rekJysuoSic/8u/F4Jw 3cylHlQgE+bGfeDNT0xZ7KUughqSBQiOGVUZMQY0/yyqyAOBD9ml10z63Ab4otkjBg2joQ3pI lmkOQaaQ8GhplNWkKzTVqE519gUNUVpQY3lzNd2nlZBJJc8b+k3s8r6BaxCXtZ4uRFkRG+3nx tP0kwjvaQJdIIvxcv12opmybkNRr1Tf1WF+knZWkdyzDoFQrbzyhgIhWmOzQ34FQ6xuqYXwr1 CqtfNzy/3QpDTvskcEe8JU/otVZIKqhba/Jq8iXNZ16jeeN3knDhqIfM6rbsEGy517PiJ055u yD+DtLWKZIwmG3O/hvyL6kJlKsCQiz15YKXuBXFL+UWfqiKo9pjkrollWhyFLnxWKFz0fJZ08 O/wy1mw2Rw2NRe72bTeVQaj8vP62DRv7ss8EiAb+WJNQ7/Zbwjfu9MpwmtT8FECrFZE0rH8EK w7fEGResn5PCTrkPeA4Xr2tahF4Dw8Y5dK4zDs31LdW+pSZWrTQaY/zTXyXeEB8uvT3StFCPu hZbBb450RedIx8I+SM4oAe/JbpHz564Hy/RxdQJXsSoyJ6VEgnjgowVCVhJb6EItY4L2xHVNX WjKpA0sX1CqOsAb1O1VZfIOKYZ1wjmDfpMTmFMUy027QtXevP/EAXU+iMGZd0b9w9V/ePAZ+E OfBc3kUhzGnDx4CHmLvJin/AjOraD1mpVpkUj3iaJ67wj1ofjMNQKECs7xodkLy5ZXLPrv5sB a/x8/E9vBb1iK5XeJ0degoI+nh7R7Dn39zwm8qc6f+G9DRTVW6KSbbyxER7Rbad96d7Pgjkx1 GqEcL3hXZ93Tg37zEDGuEtglV6jb21kE1k/hAbtduA89ExviyB9/lEl2dmY3zdHX4pSvwSwtx 9SJJbtWrwnJ3UYdZXAfKUa4STD2sJ9QpYsZf6kqSIX+xRrL6S8GE2hbmFskn9fQuySR6Jzq5T GncBI4Mhk9wD/MiS8opik/+euBS1orDXOK4Az9Dc6lz0sRkMfYpYpQh6DG2OnlTpejrrCrf1V oToilGmZlG3BiH1DUViak8H1a4b3lXFQvpZZjztEieJ02NSgmroYKF30b7gm4rwyILerEUERb tPp9dER6HfWpqwKkUQVeNmrO+Z1mpam+g3b/IjKcf9gY2bv1sqQeID/7TG2LmeenemlfWeFNK okUaP6ZYqHTD0vw5zCMilJG7kqBAr9e5rJ6rBaQrsfOskwpsX1EWofrYqXIE=
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 08:48:58 -0000

Hi Dave,

> On Nov 11, 2019, at 02:09, Dave Taht <> wrote:
> As I keep sayin, a rrul test on an asymmetric network will also show
> the side-effects of the RTT path inflation any of this stuff induces.

	Back of the envelop, instead of 1ms versus 15, we would in the best case see 2ms versus 30, same ratio but double the delta, this will make the imbalance probably even worse. I wonder how this would look with codel's 5ms @100ms interval instead of the proposed 15ms for pi2. Effectively this design gives a massive bandwidth advantage to L4S flows that can only be remedied by placing the non-L4S sources >=15ms closer to the endpoint, which for close DC type of loads does not seem very realistic.
	I now would like to see tests with say 5-10 flows for both classes with different RTTs each to see how/if the bandwidth distribution differs. It is well possible that I am overly alarmists here, but that can be easily ruled-out by simple tests.

Best Regards

> looking forward to seeing that result one day soon.
> "Tilmans, Olivier (Nokia - BE/Antwerp)"
> <> writes:
>> 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...).
>> Best,
>> Olivier
>>>> 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