Re: [tcpPrague] A Congestion Control Independent L4S Scheduler - TCP Prague preliminary results

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Fri, 13 November 2020 07:27 UTC

Return-Path: <ingemar.s.johansson@ericsson.com>
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90C83A15EE for <tcpprague@ietfa.amsl.com>; Thu, 12 Nov 2020 23:27:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=ericsson.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 ZbWFbQdDQTjS for <tcpprague@ietfa.amsl.com>; Thu, 12 Nov 2020 23:27:17 -0800 (PST)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80051.outbound.protection.outlook.com [40.107.8.51]) (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 58DBE3A148E for <tcpprague@ietf.org>; Thu, 12 Nov 2020 23:27:17 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VkdWZVKRaWghD0Rey3AHOWRtAtZDxXE+V9P38QsQ1eK4a/e4GO6Hcyuf/uwo0mrLa4jPU9TsaZbHNz68yoc220eHPHrVw07yuahguen6Jlle4gU6t/XGsb4tXm1TpUW7WdIPpvm2WZkDJ8neWySpAehDv41d1xBFNzfS1vrpBmb1QIlVdHjPP0EqJHMQye/jtFY/vJ3PVyj47tXAsAGcmCRRJZl6wmWo5kfjQejyGl/yvV0+I0r8TL77Nm9wX/R80UOddrf+R5ocGyBn+E5OM6qv3gcAXHJ7j6qUpC4/7zLn8BOr8rnNF6sdytzW3XwzrALSNI/nDjs0SLJc2gT7+A==
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=Yu9mDd07NjE1+3rJ5gRNJD2VTX5GgXmUhRwkvshrSvw=; b=KEy2r4WiKbyGwgSEX2+oVNq7xeT83aqXoOjR/pPuWGgwNBUxjDbBWzv+qf4wFuz64b2O1WS6n1N1QYkBEXKW7zuPBKu1pUlB5SW67VPEOdgClC3UcycRg1tn3RfpuBn6XAfLTqjRwme3kSF8X5UtJwARocydp0Gaa41/nKtHDNuSziKYe233aaoMOSySySW711jbDVlQoZ6N5DWaqIC29PTGSyVCXRyVM+RW0B/yPPq/vh6FQRjegcCKz3FiWU54bqXKLPuM1e05covIsiwy+g7rx0E/Z/yk+Xb6PwsJlsXt0OcpQbPMpGJECVsIfjqxkxbY1sGGmWhSQcdyeaudHA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Yu9mDd07NjE1+3rJ5gRNJD2VTX5GgXmUhRwkvshrSvw=; b=h1Fh516tYbmE72L258JulokE1rLzaPla85db7rB2S7mSKnNLnQOoAqQ0CHPgIwWlpwL3G5p2Px7DOwB/iamHJnS2Ld2DqVmWZcURCcfyHDCzyp1P4YMaqIKojJCSZQlFd99LNPdk8JP1BK+ZaabAucPGpXjy9PLEEZGAIA8l3+M=
Received: from HE1PR0701MB2876.eurprd07.prod.outlook.com (2603:10a6:3:56::8) by HE1PR07MB4426.eurprd07.prod.outlook.com (2603:10a6:7:a1::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.7; Fri, 13 Nov 2020 07:27:09 +0000
Received: from HE1PR0701MB2876.eurprd07.prod.outlook.com ([fe80::50c8:a7da:1a:48a3]) by HE1PR0701MB2876.eurprd07.prod.outlook.com ([fe80::50c8:a7da:1a:48a3%11]) with mapi id 15.20.3564.021; Fri, 13 Nov 2020 07:27:09 +0000
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>, Szilveszter Nadas <Szilveszter.Nadas=40ericsson.com@dmarc.ietf.org>, "tcpprague@ietf.org" <tcpprague@ietf.org>
CC: Ferenc Fejes <fejes@inf.elte.hu>, Gombos Gergo <ggombos@inf.elte.hu>, LAKI Sandor <lakis@inf.elte.hu>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Thread-Topic: [tcpPrague] A Congestion Control Independent L4S Scheduler - TCP Prague preliminary results
Thread-Index: AQHWuS50oyuR9tTdP0WFyRXkVqRckKnFpaCA
Date: Fri, 13 Nov 2020 07:27:09 +0000
Message-ID: <HE1PR0701MB28763578E0297ACFDAD8F0DFC2E60@HE1PR0701MB2876.eurprd07.prod.outlook.com>
References: <AM0PR07MB39533753D400A496BD46CB588B110@AM0PR07MB3953.eurprd07.prod.outlook.com> <AM8PR07MB7476F8110C025D0F8855B960B9E70@AM8PR07MB7476.eurprd07.prod.outlook.com>
In-Reply-To: <AM8PR07MB7476F8110C025D0F8855B960B9E70@AM8PR07MB7476.eurprd07.prod.outlook.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: nokia-bell-labs.com; dkim=none (message not signed) header.d=none;nokia-bell-labs.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [83.227.122.88]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4a16de89-0659-40fd-8b09-08d887a587f4
x-ms-traffictypediagnostic: HE1PR07MB4426:
x-ld-processed: 92e84ceb-fbfd-47ab-be52-080c6b87953f,ExtAddr
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <HE1PR07MB442659581124AA93198E8392C2E60@HE1PR07MB4426.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: LBIP+Um75MYh62csqZi3094huMyrLy+u4/kvtuzSa4bY5OoXpmev7FYXJhOwAz1XsW4vU6za8rAQ30pdW0cYpQAzIQdr/v7CpqA38Eva65eqRDgW+D/hOFcVJC6o8Kslyxud37VLW/Hq3Rwjdknq5zV/5X8K7yvpAabr2mG9Y3Id4zMUHFfiWwRnpVFgk6qOQ+GmFQc79JEctdEjdOaB60N2gbwelTggp2Aw7/3gFTwbdAeCi+pD4DPekQ93DGHOV2hbbss+u7Z172hRA+dUX1vg636nUZu61hRivoskBvbb2n8yRGHWV5j55iaArRrsqm0Iu+dTHd4UdCSWqa0m8KQ6wlxAXdhPnFvn2sDB5k32nd7DflBS3ePSzzJOHewKvr9squcKafYqrTuPAFrWyjybigdVdIWlc/wDjaFp6CJR5gtWpAxMC7GDA+oCti8b/Dm9o9T8+6SLmeyzmmhxUw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB2876.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(396003)(366004)(136003)(39860400002)(66556008)(71200400001)(107886003)(316002)(99936003)(66476007)(64756008)(5660300002)(66616009)(7696005)(66446008)(33656002)(166002)(83380400001)(110136005)(54906003)(9686003)(86362001)(66946007)(6506007)(52536014)(8936002)(8676002)(76116006)(4326008)(45080400002)(26005)(2906002)(55016002)(83080400002)(478600001)(9326002)(186003)(53546011)(966005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: RAFkEJE6u5yyfGD1eiJk4ouErrDTzXA+T0r8p7biRuaQiPFJ9QG6RPPTN3a/SjvRMHSb0HaKcjuLOZTYDB+BUtn4dW2fJWOELwD/OAQdRipQXhpYTjl2nhKbmfLJ7qffjtPSL+524zuuDhv19H2WaX6cE1LdywCG0bUDitJoDsYITWa/KxXVEcYto1CXPISRFEFbUqb9vIs6edfwqqcHo5Z1NnNgpnb2UsjVJFdP3mDcrHnoe2SKIMKa0Fg1et1BcaeOXj4Zg+B+/hf8Prd2XfeF+UOH7pHcDUlmJYari63p5fq3X4s3KeyQ0QGagbQ2EnyuMlZDj1MAsfVEXguEzXCyADc7zz7ZhhxddNbAQLb9eSnsZGMgWI9lzOjZPMLE7UKBvlW052xABRXZkK9PzH+pFAK8FJjxOwuEwGcLWu++jxsA7Tz9vSyf/7UGqqfbaR2DdkhbH3BSTLnCfWiLpXx3hL1kVNctZHacKqsplPFjha+QnHz4Hmh639S2oNI7WklJQM1/XMvzI2+kcQX+VlQQG+acY7w8VRd8DOqRX9om5qJSXQK+dSIAhVs6oB8BymqXzGUfibY3RDAq/ej/U1Xel2RpkDE5rzEh7IpJuwkt/79vASgiC+nVhFFqg0a/MMt2gWnuqKA51mj11zf8iQ==
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000B_01D6B996.C58BBA30"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB2876.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4a16de89-0659-40fd-8b09-08d887a587f4
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2020 07:27:09.2029 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 4BzuUJHaGoNIc+1wp3Rs3iJNmWJwd6EPoEnXmupzrObPxfzg5X6Q80Ydj8fhlBBsX0+Bl+LlHP2iGwgb3ha6kkdkrgEICEu+hKJiglHusGNNM9i6+GSn6yfWLKRaOA9V
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4426
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpprague/vuM9A2xsey1fgcuf2LpJq7PuhBc>
Subject: Re: [tcpPrague] A Congestion Control Independent L4S Scheduler - TCP Prague preliminary results
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." <tcpprague.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpprague/>
List-Post: <mailto:tcpprague@ietf.org>
List-Help: <mailto:tcpprague-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Nov 2020 07:27:20 -0000

Hi

 

Just some food for thought. 

Hybrid Slowstart (HyStart) in Cubic is known to have the problem that it can
exit to congestion avoidance prematurely. We have in fact seen issues with
HyStart in cellular and the outcome is that it over-reacts to scheduling
jitter. This issue was mentioned in the long since expired
https://tools.ietf.org/html/draft-johansson-cc-for-4g-5g-02 (section 4) and
a presentation at ICCRG
https://datatracker.ietf.org/meeting/96/materials/slides-96-iccrg-1 

The Linux TCP stack enables HyStart with both the delay and ack train
algorithms on by default. It could be a good idea to at some stage rerun the
tests with HyStart completely disabled. I am not sure in this is the reason
but believe that it is worth to rule out the problems with HyStart .

 

/Ingemar

 

PS HyStart++ developed by Praveen and others at Microsoft  instead exits to
a limited slowstart
https://tools.ietf.org/html/draft-balasubramanian-tcpm-hystartplusplus-03. 

 

 

 

From: De Schepper, Koen (Nokia - BE/Antwerp)
<koen.de_schepper@nokia-bell-labs.com> 
Sent: den 12 november 2020 10:35
To: Szilveszter Nadas <Szilveszter.Nadas=40ericsson.com@dmarc.ietf.org>rg>;
tcpprague@ietf.org
Cc: Ferenc Fejes <fejes@inf.elte.hu>hu>; Gombos Gergo <ggombos@inf.elte.hu>hu>;
LAKI Sandor <lakis@inf.elte.hu>
Subject: Re: [tcpPrague] A Congestion Control Independent L4S Scheduler -
TCP Prague preliminary results

 

Hi Szilveszter,

 

Interesting work, thanks for sharing. There is indeed a very big difference
between how DCTCP behaves today in recent kernels, than what we used in the
original L4S work testing (Linux kernel 3.19). That original version was a
“clean” DCTCP version that matched very well the theoretical equations:
r=2/(p.RTT) for uniform stable random and r=2/(p².RTT) on/off marking. Due
to many interactions, integer range constraints, pacing/GSO interactions and
bugs, the performance really degraded in the recent Linux versions. These
issues were fixed within the Linux Prague version, so that is why Prague
should perform “better” in respect to matching the equations. It would be
interesting to get an idea of the deviation from the r=2/(p.RTT) equation in
your tests (relevant in DualPI2 as the coupling gives a smooth probability).
Collecting the average RTT (base + queuing latency), marking probability,
and rate would make it possible to evaluate this.

 

Main reasons why we saw deviations is when the probability varies a lot in
time. As you might know DCTCP’s (and Prague’s) equation becomes r=2/(p².RTT)
when it receives on/off marking episodes (on episodes in the order of 1 RTT,
off in the order of multiple RTTs). Any not so stable marking probability
results in a rate between those 2 boundaries. This is the theory, looking
forward on how your practice matches this.

 

>From a first quick look at the results it might not deviate that much, I
guess. The more aggressive part is probably due to the RTT unfairness: 1 to
5 rate ratio (with a 5ms base RTT, Classic gets a queue of 5ms+20ms target,
so about 25ms and 5 times less throughput). Did you try to use the RTT
independent version? If you set it to the f=max(15, RTT) mode, the minimum
effective RTT becomes 15ms, so the rate ratio is 3 to 5 in that case.

 

Thanks and Regards,

Koen.

 

From: tcpPrague <tcpprague-bounces@ietf.org
<mailto:tcpprague-bounces@ietf.org> > On Behalf Of Szilveszter Nadas
Sent: Tuesday, November 3, 2020 6:30 PM
To: tcpprague@ietf.org <mailto:tcpprague@ietf.org> 
Cc: Ferenc Fejes <fejes@inf.elte.hu <mailto:fejes@inf.elte.hu> >; Gombos
Gergo <ggombos@inf.elte.hu <mailto:ggombos@inf.elte.hu> >; LAKI Sandor
<lakis@inf.elte.hu <mailto:lakis@inf.elte.hu> >
Subject: [tcpPrague] A Congestion Control Independent L4S Scheduler - TCP
Prague preliminary results

 

Hi all,

 

During the review of our article “A Congestion Control Independent L4S
Scheduler” we received comments from one of the reviewers, on why we did not
also evaluate TCP Prague. So now we rerun the test cases with replacing
DCTCP to TCP Prague. 

 

The results are at the below link. We are somewhat surprised by much
increased aggressiveness of TCP Prague. Can you comment on it? The settings
and setup we used are described in the pdf (and in the original article).

Results: http://ppv.elte.hu/tcp-prague/ 

Original article (including YouTube presentation):
http://ppv.elte.hu/cc-independent-l4s/ 

 

Can you comment on the results and the settings we used?

 

Cheers,

Szilveszter