[iccrg] Following up with (r)LEDBAT(++) presentations

Kuhn Nicolas <Nicolas.Kuhn@cnes.fr> Tue, 23 July 2019 22:14 UTC

Return-Path: <Nicolas.Kuhn@cnes.fr>
X-Original-To: iccrg@ietfa.amsl.com
Delivered-To: iccrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383A41209DE for <iccrg@ietfa.amsl.com>; Tue, 23 Jul 2019 15:14:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 V5JPpW3lRWBB for <iccrg@ietfa.amsl.com>; Tue, 23 Jul 2019 15:14:41 -0700 (PDT)
Received: from mx1.cnes.fr (mx1.cnes.fr [194.199.174.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDE5D1209D2 for <iccrg@irtf.org>; Tue, 23 Jul 2019 15:14:40 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.64,300,1559520000"; d="scan'208,217";a="9432007"
X-IPAS-Result: A2EjBgA1hjdd/wIBeApmgy5YgQMUgS4KmTaRfYYXgWcJAQEBAQEBAQEBGxAMAQGEQAKCcjgTAQMBAQEEAQEBAQQBAQIChU45AQuFUC87IwEVFVYmAQQbgxuBHXysKxqEHAOFfwaBNIFjjBKBEUaBTkmDVAIBgS0BEgEhgzuCJgSTcn6HbY4GBwKBMmkDghySCHOMWAOKPI01mV9MPXEzGieDOIFKgh4BB4dXhT9yAY0JgSKBIQEB
X-URL-LookUp-ScanningError: 1
From: Kuhn Nicolas <Nicolas.Kuhn@cnes.fr>
To: "iccrg@irtf.org" <iccrg@irtf.org>
Thread-Topic: Following up with (r)LEDBAT(++) presentations
Thread-Index: AdVBoRtOiBYn2SLUTXKZEtZhVHp42w==
Date: Tue, 23 Jul 2019 22:13:38 +0000
Deferred-Delivery: Tue, 23 Jul 2019 22:14:37 +0000
Message-ID: <F3B0A07CFD358240926B78A680E166FF1EC2505B@TW-MBX-P03.cnesnet.ad.cnes.fr>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tm-as-product-ver: SMEX-11.0.0.4255-8.100.1062-24792.000
x-tm-as-result: No--20.937500-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_F3B0A07CFD358240926B78A680E166FF1EC2505BTWMBXP03cnesnet_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/iccrg/P_nRAQOi0_Y-5Q2tp0hsM2wJcTE>
Subject: [iccrg] Following up with (r)LEDBAT(++) presentations
X-BeenThere: iccrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" <iccrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/iccrg>, <mailto:iccrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iccrg/>
List-Post: <mailto:iccrg@irtf.org>
List-Help: <mailto:iccrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/iccrg>, <mailto:iccrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jul 2019 22:14:51 -0000

Hi,

Thanks for the presentations on LEDBAT-related work.
I think that further evaluations of the proposals are required to better assess their relevance and their parameters.

Most of the content of this email was sent after the first presentation of LEDBAT++ but the points that are mentioned there seems still valid.
I hope this helps.

- Multiple LEDBAT-like protocols
There are multiple "lower than best effort" protocols in the wild that seems relevant (e.g. CDG [1][2], FLOWER [3]) since they consider LEDBAT's issues in their state-of-the art.  Moreover, it is worth pointing out that CDG is in the Linux kernel and has a "lower than best effort" option. You may want to consider them in your evaluations.

- Interactions between LBE and AQM
Authors of [4] and [5] showed that there can be important issues when LBE schemes cohabit with AQM mechanisms. It may be worth considering AQM in your evaluations.

- On the rationale of using fixed target delays
Using 'fixed' target delays does not seem to be a good option if protocols are to somehow be 'network independent' - unless the selected timers are relevant for data-centers and satellite corner cases ?
It may be worth considering various deployment scenarios in the assessment of the proposal.

[1] David A. Hayes, Grenville Armitage (May 2011). Revisiting TCP congestion control using delay gradients. 10th International IFIP TC 6 Networking Conference (NETWORKING 2011)
[2] Tangenes, Tor Christian, David A. Hayes, Andreas Petlund and David Ros. "Evaluating CAIA Delay Gradient as a Candidate for Deadline-Aware Less-than-Best-Effort Transport." (2017).
[3] Trang, Si Quoc Viet and Lochin, Emmanuel and Baudoin, Cédric and Dubois, Emmanuel and Gelard, Patrick FLOWER - Fuzzy Lower-than-Best-Effort Transport Protocol (2015) In: The 40th IEEE Conference on Local Computer Networks (LCN), 26 October 2015 - 29 October 2015
[4] Y. Gong, D. Rossi, C. Testa, S. Valenti and M. D. Täht, "Fighting the bufferbloat: On the coexistence of AQM and low priority congestion control," 2013 Proceedings IEEE INFOCOM, Turin, 2013, pp. 3291-3296.
[5] https://www.ietf.org/proceedings/93/slides/slides-93-iccrg-2.pdf

Cheers,

Nico