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

Sebastian Moeller <moeller0@gmx.de> Fri, 08 November 2019 11:24 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 3D2BD1200F7 for <tsvwg@ietfa.amsl.com>; Fri, 8 Nov 2019 03:24:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxpgrUSr6rex for <tsvwg@ietfa.amsl.com>; Fri, 8 Nov 2019 03:24:09 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 516C61200B6 for <tsvwg@ietf.org>; Fri, 8 Nov 2019 03:24:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573212245; bh=wjWkUoYsrFCdtFMFrEP2zKihL1wlHus0Yi41aPq5hI8=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=EkBTS1iYBhtJ7IP1fbe/uI50uGSGuqzddNW9bSNP/6MN15oZ+/rpjQenvkQddCHQB 5amnWdxjmHAmx9ZPsUzJ3WrOn8mLNDSmrAHbf+kIHOpn2t1BfA7c51bRLPXDyV4XFU z8JKyY6hBbp8Q0Q2T8ATzPDv+PQHQp1KDGPVKoJk=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.11.12.33] ([134.76.241.253]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MbirE-1hvbx41E1W-00dFrC; Fri, 08 Nov 2019 12:19:00 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <VI1PR07MB598169BE81401DF2B4FD2CF2E07B0@VI1PR07MB5981.eurprd07.prod.outlook.com>
Date: Fri, 8 Nov 2019 12:18:58 +0100
Cc: Pete Heist <pete@heistp.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <949AF60C-EA09-44ED-8521-7C333DF326D4@gmx.de>
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>
To: "Tilmans, Olivier (Nokia - BE/Antwerp)" <olivier.tilmans@nokia-bell-labs.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:A0Pb9FSesATnpStzyTBw4pfMt9DeOAGLaThKPkmw02d/G39YzPd 2lOUd5Kn1igkCdnQegi/E3VDB94+sI8XN77QK2qaIsV2oHDTNcSfNeoW/CyWXMj9tfaU4Oj ZHOrNKG9aAuQdEbj4LmM7gStbO1OfqZHwhTFlCYtCP/MouVxAeZqHJ9ej75sNmT4ujUilRr C2iLD4uc9TqZbqAqobPzQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:BPeYmlGXoKI=:M4dcZAj5yy2k7/yM1iQww0 S32M04zyRfUaL+Ez40nOxCT2EitYqj5LSwkzQ2WetX4njlClsWzB0Z/KsaHt7tVB8rSkCtuUX YJ1ZEuP+sclR/szz20eVqs3R6ACPx8f+0m59eaoV7HunS/WDcP+TdNdajdMqicOmjvFxKwAn2 EM1y6V5EZKbNj5ncdcZNoMy6wUzCRsDhAyk3wnn9prIFWG+esLKPpOoJFH+0UExpXxzEHKD4y vK6ObuK6bn3Zq2IB9XZhtR+P3WoW+Ri7lBEPS4BFVHZHI+tpAs+6SMcwX4KbErJLhzgWnAMtv yuBzFrIJapHoesWIOTGj7QDZrLPpvPNgQ8BUU8xcFuH8mNZf8m8qddFtWhvlogSJLVpdS34kz 7bnR1jbU2Z4/xzfwrFufA5BK+OdXiVFE8xmE52XiwAs2C0jff1dAMBcNqEDY4hIeGOmTClryY BMhfeYqEwnHy+PuXQPSbg9eVRpZ0lxRaerfA127fSMFt7Kun0ZVjryXBzhnU0b2ACj07FnIlL USp7HwSOmV3axFRy7FKgr3Y+jk1is+sOa1UcPF2hyqN6a33tgXULMfTzweQl04b7B7auWdONT k0nnaeGaHYBk6QzMD8LGQt4/OefpESy5c7qegGeUbd9+gsQuNxpOWKuQSzdZfx/aLTwJT2J1A l6kqDOjioJpXeTVuB4mV98eBEVQdRG/3KHkyz0c168k98XSqQiRQRVBmpoySgcif3AzOpnffO 81/e8pd1MDDpYagtYVwP+d0drLYnzYHPaja1Y4AsoH1gKIUkUID/TxEuCDj2vIkYBAgejWMnL qs5RlOPNAnUNDCPDSsT3X0r1Ai/4NLJZxlWODFEWflQ5BO6rFMPEFshHV9LmyfdwxGNqXwSDd GFVFXEd5U3igBJ0BoqroedVxF/9Oz9vh7cHkWUkE8Yxb7pWfcJFKwspMsxZKJtOZwd7LjAKw1 yW39/xXPEqVFD9lAcFwoQHjlXyRSF8hvK/o6yjTb7MjdY1iaZ6+eIB7R1e+fkmKA3v3EM19Hm 6gkPUOvoZyLpdBPMWLJxT5uISolch28tkgjfNW+i6I0MGH/uBJgNsy3m6dPa5AvOX1YgEilk3 QEUlWGDGnENXPRt5vOk+k7FeKvAYNT6q8LuXEqdRWizMSFSjA5mEESFZ78AcLiaLpQg2YumcE qldDf3W7263fnzQKc0SdQjdYGRdX+i37jO/2UST/hDFbk2KTc8HkQ/lAR3ECBsSN0jWHJ3EtB HIaLyXECciZ4EM0CqvwUWqv+AM2+MPjgtPl8sAq0Vt1ANODfSk3zxZEnFis8=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/gZeMb3DbCIgxpSkJ8vNXLjOwTks>
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: Fri, 08 Nov 2019 11:24:12 -0000

Hi Oliver,

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 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? 




> 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