Re: [tsvwg] L4S vs SCE

"De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com> Wed, 20 November 2019 16:17 UTC

Return-Path: <koen.de_schepper@nokia-bell-labs.com>
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 3932712086F; Wed, 20 Nov 2019 08:17:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
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 DPr8ryBvqHxM; Wed, 20 Nov 2019 08:17:02 -0800 (PST)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40097.outbound.protection.outlook.com [40.107.4.97]) (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 E26C812084B; Wed, 20 Nov 2019 08:17:01 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RUeoAOoFcZmc2M+b7y99Vz+ggRj75wJHqfY3SmdHaGb2oZHHdgfc5+iUl/2obaMGFunyyXwwW83wWG0iB8TWAWLvQWtMfR1Nb+98IFPKGchAYkFHEkX0ZxZM6MufZ2AvGaR8H58lmIlnKHiUeAB/u5mElCQLBf4pVzKUI5bzcYI/aaop3E8mFWDln8s67uN9DU1cgTkC4qT4s0HYeNcedzcvcsJEajeljzjag5BlnxVOQ5Vbybwbyl+U0c5EO5wOcaNHkXuFk9+qZObPAbFBjfg18rMx1PTmqOMOBhdruGlCT5rKw+N2cvSoY76OT3Bx+UI5dps1uWsfBOZ7CjfOGw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Rb+ICpPvoAo0JfCNbow4WckXUtswWipFH01pkLAM9r4=; b=MExa+wMGeYq1umqR/BlfoteYrdORWVrmv35TFmBlvLa5yjXJou5FnfDEkvSGGjDR474ALWCghTkIo5tSAWynT6mE701xtehmYlUWOtGsLQMYDLqMMqgGi5aGKoazB06bs54xGpVQxS7rBgU51jx97e9ejlrr1q/h4AFRCT5Bw/Tnwe7XN/wGuBgsb5zQj/CAUrcL+96fkASnr3QkoefuUg8VypdJdjg60E7c0R202+AOPYa+eiCTFb7R/1kKC3VxLmJReFIl/nfoh+wv6xQa6ckWS5mRBkU7kTL2ScR0A9jdD0pQ+DISy79uopJijsINUh+6FiwjWphxURcFSoqxMw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia-bell-labs.com; dmarc=pass action=none header.from=nokia-bell-labs.com; dkim=pass header.d=nokia-bell-labs.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Rb+ICpPvoAo0JfCNbow4WckXUtswWipFH01pkLAM9r4=; b=KRQu2FuOifbGirOF7Prm66RAo242JOzsXfy+DzEaP5jTGrS5NcMnTc3Gdsg60jogAaKtVglqqlv5B7XOEFpTOAhiJvtSb7MdT8EMCP1r0/VvXphXkdqWDk86ddN+Re6zlOyOXg/5syYFjk16engAAwTXrjtGbqg2RObqr+wO6sY=
Received: from AM4PR07MB3459.eurprd07.prod.outlook.com (10.171.191.155) by AM4PR07MB3249.eurprd07.prod.outlook.com (10.171.191.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.9; Wed, 20 Nov 2019 16:16:59 +0000
Received: from AM4PR07MB3459.eurprd07.prod.outlook.com ([fe80::512e:fea6:b569:32b0]) by AM4PR07MB3459.eurprd07.prod.outlook.com ([fe80::512e:fea6:b569:32b0%6]) with mapi id 15.20.2474.015; Wed, 20 Nov 2019 16:16:59 +0000
From: "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>
To: Jonathan Morton <chromatix99@gmail.com>, Sebastian Moeller <moeller0@gmx.de>
CC: G Fairhurst <gorry@erg.abdn.ac.uk>, "4bone@gndrsh.dnsmgr.net" <4bone@gndrsh.dnsmgr.net>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] L4S vs SCE
Thread-Index: AdWe0nrRkrzku9jhQamw6kS06HsgqgAK7DuAABW78QAAAJnugAAJXScAAAJlnjAAASgZgAAAux5gAANtw+AABGZ8gAABfOCAAAI5mVA=
Date: Wed, 20 Nov 2019 16:16:59 +0000
Message-ID: <AM4PR07MB345936C1A50D058D7F6F5CB6B94F0@AM4PR07MB3459.eurprd07.prod.outlook.com>
References: <HE1PR07MB44250F3C4E6A744DDCC3DAFCC24C0@HE1PR07MB4425.eurprd07.prod.outlook.com> <ad7b763e-b3dd-36cf-a9c5-7de99476babb@mti-systems.com> <12ED7632-5E3E-4EB9-B65E-8A8324067C9A@akamai.com> <5DD4BB25.3060700@erg.abdn.ac.uk> <5658232C-07D5-4C89-B16A-58A928332FC6@gmx.de> <HE1PR07MB4425D989D4A266C73331FFA5C24F0@HE1PR07MB4425.eurprd07.prod.outlook.com> <CAJU8_nUK5cZLFE-0UBzf0a7T0hC7C+CpCsUy_+ZU_p4oxW9BmQ@mail.gmail.com> <HE1PR07MB442560D0715BC921AB9B7FE3C24F0@HE1PR07MB4425.eurprd07.prod.outlook.com> <AM4PR07MB345968E8C665304DFBD5B11FB94F0@AM4PR07MB3459.eurprd07.prod.outlook.com> <AAC23B5C-447F-428D-956F-850653A561F7@gmx.de> <3FACB748-4EBA-4A78-B73F-3CF390F9A52C@gmail.com>
In-Reply-To: <3FACB748-4EBA-4A78-B73F-3CF390F9A52C@gmail.com>
Accept-Language: nl-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=koen.de_schepper@nokia-bell-labs.com;
x-originating-ip: [81.82.56.234]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 61fe1c31-1316-4a75-27bf-08d76dd511fd
x-ms-traffictypediagnostic: AM4PR07MB3249:
x-microsoft-antispam-prvs: <AM4PR07MB3249783B9433BF0B85003942B94F0@AM4PR07MB3249.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02272225C5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(39860400002)(396003)(346002)(376002)(13464003)(51444003)(199004)(189003)(446003)(25786009)(71200400001)(229853002)(71190400001)(86362001)(4326008)(110136005)(54906003)(305945005)(2906002)(33656002)(6116002)(3846002)(7736002)(476003)(76116006)(6436002)(6246003)(9686003)(256004)(52536014)(486006)(66066001)(5660300002)(102836004)(55016002)(26005)(74316002)(99286004)(316002)(8936002)(478600001)(6506007)(66574012)(53546011)(186003)(14454004)(76176011)(7696005)(11346002)(81156014)(81166006)(66946007)(8676002)(66446008)(64756008)(66556008)(66476007); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB3249; H:AM4PR07MB3459.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1;
received-spf: None (protection.outlook.com: nokia-bell-labs.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Pfqxoc3Vwa5yy7SbIr2+xDng8Q+/hg1sJ2uHuX4XUKYLCSwFjLoFydM0+/ONZ/JRrMegcrLauIr5ILc2ogTuJQYpS3IskgOwtnJOxNVqtp8rrLUKh5zkNovF+DpnF7/lfH5PrRUlclrrI6SyJHgji2CJSx7WlP/Z6Hw6PxPQaoIjZwhdGH9N7tppkx4rCfSAlVRz8DWfvdpbV2Jb1b4UYTOORRpaFKdUnoZt7+GCsFJUtRZWNwkXkHjmMyIhCmZ69xunjdld+ASTbHKNxqQjC66c9wovXdcT8aT8cgD+g1tX+ro0u1fOZk7nxaVY41btVYtQgGr/YWFLXXzVUFzVs3hbdtoYcQ2VEuRzzrKhbcEznzq1xJvJeokFmUus/hOVZTw+bpTe8uVneZTrb238ty64C3cfOxBXSZF4mC1eMxsJ1Rn1VZ2wsxHXM1MbgZ0d
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia-bell-labs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 61fe1c31-1316-4a75-27bf-08d76dd511fd
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2019 16:16:59.2720 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: rBiobhi83t8xAiR6yQyfqXs1P4fk58DbsFlccOLVdE4LLffFNwWid6smQBnkH3FwAddZI+bv6zubpH9h2y3dOMLP+HJ26wfywGiDBqGDSEjuGLfOkmVw78FGJwcNuX5J
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3249
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/YRxuEOLNsQTnwxcTYCB8xPvCGGk>
Subject: Re: [tsvwg] L4S vs SCE
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: Wed, 20 Nov 2019 16:17:04 -0000

It should be fairly simple for an explicit and very frequent congestion signal, isn't it? This is basic stuff, where you can find a lot of information and papers on already...

Agreed that for delay based CCs this is another issue... but this is not the case here at all.

Koen.

-----Original Message-----
From: Jonathan Morton <chromatix99@gmail.com> 
Sent: Wednesday, November 20, 2019 4:01 PM
To: Sebastian Moeller <moeller0@gmx.de>
Cc: De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com>om>; G Fairhurst <gorry@erg.abdn.ac.uk>uk>; 4bone@gndrsh.dnsmgr.net; Ingemar Johansson S <ingemar.s.johansson@ericsson.com>om>; tsvwg-chairs@ietf.org; tsvwg@ietf.org
Subject: Re: [tsvwg] L4S vs SCE

> On 20 Nov, 2019, at 10:18 pm, Sebastian Moeller <moeller0@gmx.de> wrote:
> 
>> One of these opportunities here is to make L4S_TCP less RTT dependent. There have been many working implementations for less RTT-dependent CCs in the past. One that is widely deployed is Cubic, which is doing this for getting more throughput for longer RTTs. The only reason why it didn’t fly for lower RTTs on the current Internet is that they would hurt themselves (get lower throughput, competing with Reno).
> 
> 	[SM] Looking at the pfifo_fast results in Høiland-Jørgensen T, Hurtig P, Brunstrom A (2015) The Good, the Bad and the WiFi: Modern AQMs in a residential setting. Computer Networks 89:90–106. For Cubic/pfifo_fast (linux former default combination), I fail to see a strong indicator that cubic is RTT invariant or getting more thoughput at longer RTTs (except for the 10ms versus 50ms "hump"). What paper/data should I be looking at instead?

CUBIC is more RTT-invariant than Reno is, and achieves more throughput on high-BDP paths than Reno does, which I think was the meaning here.

Examining the formulae for calculating steady-state average cwnd from marking probability, and converting to throughput by dividing cwnd by RTT, it's clear that any CC algo that depends only on marking probability for cwnd evolution will converge to an RTT-invariant cwnd and will thus have the same RTT-fairness of throughput with itself as Reno does.  This is in fact true for TCP Prague and all of SCE's response functions thus far.

But CUBIC includes an RTT term in its steady-state formula which partially compensates for the conversion to throughput, such that CUBIC's self-competitive throughput in its high-BDP regime is proportional to the reciprocal quartic root of RTT, rather than to the plain reciprocal.

So I think that to meet Prague Requirement #5 - reducing RTT dependence - one must first achieve at least as good performance as plain old CUBIC in this respect.  Is there work towards this in progress within L4S?

 - Jonathan Morton