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

Dave Taht <dave@taht.net> Mon, 11 November 2019 01:10 UTC

Return-Path: <dave@taht.net>
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 9C5B3120120 for <tsvwg@ietfa.amsl.com>; Sun, 10 Nov 2019 17:10:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 UZYfwKKDiG6O for <tsvwg@ietfa.amsl.com>; Sun, 10 Nov 2019 17:10:03 -0800 (PST)
Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 029B112001A for <tsvwg@ietf.org>; Sun, 10 Nov 2019 17:10:02 -0800 (PST)
Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 48E3721B46; Mon, 11 Nov 2019 01:10:00 +0000 (UTC)
From: Dave Taht <dave@taht.net>
To: "Tilmans\, Olivier \(Nokia - BE\/Antwerp\)" <olivier.tilmans@nokia-bell-labs.com>
Cc: Sebastian Moeller <moeller0@gmx.de>, "tsvwg\@ietf.org" <tsvwg@ietf.org>
References: <8321f975-dfe7-694c-b5cc-09fa371b9b61@mti-systems.com> <B58A5572-510E-42C7-8181-42A0BE298393@gmail.com> <D2E12331-F504-4D5F-B8E7-A1A5E98DDF7E@cablelabs.com> <2275E6A5-C8F8-477F-A24A-3E6168917DDF@gmail.com> <55F724CD-6E74-40D9-8416-D1918C2008DD@cablelabs.com> <BBE7C7A9-0222-4D84-BF27-8D5CAE2F995E@gmail.com> <6f189711-ffa0-90f4-fd16-3464ba4df3ce@mti-systems.com> <4A706B11-3239-4DAC-BE85-0B4BFF2D8FF8@heistp.net> <8B28ECE4-FF4B-4BB2-ACBE-80B30708F97E@cablelabs.com> <AAEA9AC2-B8A1-4837-A7C9-8EEA21A7C523@gmx.de> <D5D560CB-BC47-45BE-811E-E73E2D4909E3@cablelabs.com> <3332A911-3AA0-4986-9AA9-B97266A3337F@heistp.net> <VI1PR07MB598169BE81401DF2B4FD2CF2E07B0@VI1PR07MB5981.eurprd07.prod.outlook.com> <949AF60C-EA09-44ED-8521-7C333DF326D4@gmx.de> <VI1PR07MB598167BC77A7FEFB8D220F4BE0740@VI1PR07MB5981.eurprd07.prod.outlook.com>
Date: Sun, 10 Nov 2019 17:09:48 -0800
In-Reply-To: <VI1PR07MB598167BC77A7FEFB8D220F4BE0740@VI1PR07MB5981.eurprd07.prod.outlook.com> (Olivier Tilmans's message of "Mon, 11 Nov 2019 00:38:09 +0000")
Message-ID: <871ruf1an7.fsf@taht.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/JdKPdqypkU-gxrm40HBj-eIycpA>
Subject: Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs
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, 11 Nov 2019 01:10:05 -0000

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.

looking forward to seeing that result one day soon.

"Tilmans, Olivier (Nokia - BE/Antwerp)"
<olivier.tilmans@nokia-bell-labs.com> 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)
>> <olivier.tilmans@nokia-bell-labs.com> 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
>> >> https://github.com/L4STeam/linux? 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 https://l4s.cablelabs.com/l4s-testing/README.html (link
>> > at the bottom of the page Greg linked), we ran your full set of flent
>> > tests using this tag:
>> > https://github.com/L4STeam/linux/releases/tag/testing%2F5-11-2019
>> >
>> > 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