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

Sebastian Moeller <moeller0@gmx.de> Mon, 11 November 2019 09:48 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 C8F1412080C for <tsvwg@ietfa.amsl.com>; Mon, 11 Nov 2019 01:48:51 -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 Ex7glJkuO2ZD for <tsvwg@ietfa.amsl.com>; Mon, 11 Nov 2019 01:48:49 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 B5EDC12080B for <tsvwg@ietf.org>; Mon, 11 Nov 2019 01:48:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573465718; bh=l4f3ihqAE+89ho+V17o++XjUwAqnYbWh2732MyR4MXA=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=dEx+oRyyiztW29ytbfLkqqhuqU5Q7SNvCiRG5QC8IGW5KT5szbN/QwvPOBFKP6VOB 7Fh8D5A6xJNfmL6R22F4r6vPtBHfT73ENG2KhbwO8vrA3neLWem3TVi+T7jQC7H5zl vGBgMhrBxnheethDsGwzvogrMa5v/T9+8E61dDxg=
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 1MlNtP-1i2Q3f0awH-00loS6; Mon, 11 Nov 2019 10:48:38 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <b0924e04-6278-8c21-4b39-297dd31d669c@kit.edu>
Date: Mon, 11 Nov 2019 10:48:36 +0100
Cc: "Tilmans, Olivier (Nokia - BE/Antwerp)" <olivier.tilmans@nokia-bell-labs.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <689A14E9-3C10-4200-8C61-9FD03ECC446F@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> <949AF60C-EA09-44ED-8521-7C333DF326D4@gmx.de> <VI1PR07MB598167BC77A7FEFB8D220F4BE0740@VI1PR07MB5981.eurprd07.prod.outlook.com> <b0924e04-6278-8c21-4b39-297dd31d669c@kit.edu>
To: "Bless, Roland (TM)" <roland.bless@kit.edu>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:BGkBskn1tESQ16bUsckIL9qfugZUSbKS/Kx6RIkZ3fJPRfTKfcA mlQV95TBPbf1fyv8EB2HUIDybN+E462qpWL7gGQ9s4FW0o12w4lxA6nAFEZo3DVtr06S4lY U3iG9fb5EdMn6ImFp4C/cOE6Zt6VuMLl5VuwWVpws+0FPfxTkfyCgDVfaTUpY637hs71QRn YyvjGIX1pCeefaWgLqpIQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:MkKyMhqBVdk=:IESXCBraJEPOprFn+shiPV Vn39zpxUGmo1yRERQPj//o2SaCXKbgpsvePwZgdKBMGcEbTDjTyiopTA8TV0I7IXAmnWFqUG1 bj8/0NleFlAJmXC4T5OIk04b5mFUeulkpvQ0E40b5TpKaDiAfEn0SVObIfNVvE6hp/00x9vdA /9us7FgMOT4YUEay3Q0qT8ZCI/Q2c4rs2p4A5QJvLVMPpGpCOXVDoH4G7dZGhUmbl/ZEGXC8Y pMnEUlDPVn1DOTAcTDHnkvIycA5nmDfFuQe5roPZUMbOr6GS3R9Likd7Qj2ip7ZhlioDkhczE AYuk3peobG4tYV+Z7NhmMor3rZu43S58G7CrH/zNtSHfIGkqXfeFXR6zq25Ubpx+APMVaZ4AH OD0XbKmmDfBbs25JQw2P0KaxtUTVTtjAG3sQrMCqRKWpurD88pxTNMkiShxSEfnYoHaI2SOrC wnuc8elZi+9JI9Lvf4qxcQOOlwT5Y6/UbpiJxCB1AeQ17goQ/zeLbWam1tJUfyifZmWj2fH5q WMWWq6dA7WFiWvFdG+o7rSEIfUvH5ineNAX4KCCSD7+a767a3f6JQvtaXwT1sMXsyEMDZgUHt BfA0Zf0chtbj7PaSRTZxoa40pHFc/k7apZfBr9RMhzpwQKZVulx4XvDOCPap87jKX9Jjic8x8 lSQk01IU4eRFrILS0BRbgJs0DrvTRvQ2+xioEPvo9NOOm4xEIdYoyBeuG4mw6ZvaJo/GAeDwE gVzjgOCX5GY0GGiC89WMeN/PlEn9B7UJXWFjzKpjj0TPn8ibA8MmylI161UD5ZiGlcUjpDcKV r4zZPoNBNLUg6misseNVpbBk3yb0eghDyLhnWrkH/apjMc3fMjhmJd/9HpqHBCDyMMm3Rbe/X WhVtCe704yWd9FcavbYW3zn8IyQVVhus+Nc5WENuHe5RKWiEhxES6r8FHn0yGCMqa0JDrTbMf 63SJuQyCo3WTWkUramOThIif9ccY3yrU5t0rqhG339Bpo/OzQzjQD+v22esEcxiPuIJYm/6T7 t70yl59fIqmfRVq7x/gi6fXz58+FzT2gm9nCyTb8kW2HK1wUzzPfOdrx7J3RO1+2Rl6GYYU6z 0rLupHdgZELLTocIwHeE4Q53JILne0Ve3osYiDyi9+dJkmQXsas6HsyzPbdKdujl/fwrZkGT/ jFZQAAsoXKyU8i2Sts3HV15sgbWMhW+FC/97U8mxcotpRa5G4tk1z54MO4rbWd5EPQ4d14YAt 2akXfqbSv9NQGk0kAk/mQQmZW++4fuBJQ8N0RGA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/80RdIJ9IyRiVB93TZoMknfR09yU>
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 09:48:52 -0000

Hi Roland,



> On Nov 11, 2019, at 10:34, Bless, Roland (TM) <roland.bless@kit.edu> wrote:
> 
> Hi Olivier,
> 
> Am 11.11.19 um 01:38 schrieb Tilmans, Olivier (Nokia - BE/Antwerp):
>> 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
> 
> Not sure that I understand what you mean here. Flows with different RTTs
> typically need different CWnds to achieve sufficient throughput, but
> their share of queued data at the bottleneck needs to be the same in
> case you want flow rate fairness between them. This is, however,
> different from requiring their CWnds to be equal...

	The Issue seems to be that, the language in the introduction not withstanding, DualQ/L4S effectively only guarantees to not completely starve non-L4S flows; as designed L4S traffic will outcompete non-L4S-traffic at any reference RTT, the shorter the base RTT the more pronounced this issue is going to be. Lets look at https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-10:

"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."

"Similar conditions" here according to Oliver is intended to denote RTT under load (wonder how this would look with codel's 5ms target @ 100ms instead of pi2's 15ms?). This might be working as intended, but I am still not convinced that that is as safe a design as claimed:

"However, until now, Scalable congestion controls
   did not co-exist with existing TCP Reno/Cubic traffic --- Scalable
   controls are so aggressive that 'Classic' TCP algorithms drive
   themselves to a small capacity share."

As fas as I can see this paragraph is still true for the currently implemented DualQ AQM TC Prague versions.

For what it is worth:

"Therefore, until now, L4S
   controls could only be deployed where a clean-slate environment could
   be arranged, such as in private data centres (hence the name DCTCP).
   This specification defines `DualQ Coupled Active Queue Management
   (AQM)', which enables these Scalable congestion controls to safely
   co-exist with Classic Internet traffic."

Effectively also seems counter to the data, as especially traffic from close by data centers will show the base RTT dependent imbalance. IMHO this effectively renders all the lofty words about decoupling latency under load from bandwidth moot.

Best Regards
	Sebastian



>> 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...).
> 
> Regards,
> Roland
>