Re: [tcpPrague] [aqm] L4S status update

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Tue, 22 November 2016 14:35 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 CE543129A31; Tue, 22 Nov 2016 06:35:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 0hCvR9R4Aa6X; Tue, 22 Nov 2016 06:35:10 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 D3666129A32; Tue, 22 Nov 2016 06:35:08 -0800 (PST)
X-AuditID: c1b4fb2d-0bbff70000000994-3d-5834579a78fc
Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by (Symantec Mail Security) with SMTP id 2B.25.02452.A9754385; Tue, 22 Nov 2016 15:35:07 +0100 (CET)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.87) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 22 Nov 2016 15:35:06 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1JSHM/0OUFhHIn5RGOnp/Kg57Lkxpn9QEhr1rxGpBHc=; b=glHPGBWAUAIijOAoorT9dOIIFXuUwyyNuSpIjsfYeYuCsAc8zughLWCroYACjZfvH+sNtl8I03Tv0JXRJNHw72MERxtq2GolkN7eQZ50bDDTVEqHKgQPX0msj508XyYuPIIWl8jpncUbymTFDXUwSF9RfqACvwYhkuQEDqn6tMg=
Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.5; Tue, 22 Nov 2016 14:35:05 +0000
Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.0747.006; Tue, 22 Nov 2016 14:35:05 +0000
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: "Bless, Roland (TM)" <roland.bless@kit.edu>, Bob Briscoe <ietf@bobbriscoe.net>, tsvwg IETF list <tsvwg@ietf.org>, TCP Prague List <tcpPrague@ietf.org>, AQM IETF list <aqm@ietf.org>, tcpm IETF list <tcpm@ietf.org>
Thread-Topic: [tcpPrague] [aqm] L4S status update
Thread-Index: AQHSRDIMrBiIIyXAnkeCaadJdlnwcqDlDZUg
Date: Tue, 22 Nov 2016 14:35:05 +0000
Message-ID: <DB4PR07MB34816BE4EBF717E026A67ABC2B40@DB4PR07MB348.eurprd07.prod.outlook.com>
References: <be67928d-e1f7-2495-147d-1d42d6783cc8@bobbriscoe.net> <f6b89407-14d8-b532-b793-7490cb5a2117@kit.edu>
In-Reply-To: <f6b89407-14d8-b532-b793-7490cb5a2117@kit.edu>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com;
x-originating-ip: [192.176.1.89]
x-ms-office365-filtering-correlation-id: 62566d1f-6b6e-4083-9074-08d412e4c093
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DB4PR07MB348;
x-microsoft-exchange-diagnostics: 1; DB4PR07MB348; 7:6yJcwqJnmZQ9ndDPm4o1Q4nSqtQmLg+a7XDcw7Ixf7GtXwjLgYor9ipjwZAe/FzcgcGKyGS6bbiXnD+/KE9XF+g3BomcG2plWUnuP92oT3Kc9Avzf0+woQk0/GIRt5NGUigCw2KRwISUNYcsXTBJmz/jHNF0eb1mV/VEjn1/Eunoj8cYam0v4/32S2IhHfPO4WIwGJYVtg1JTN5Yt3FSixOhQ5u4TyropBQa63VnUcfa40YbbcKD/aMjn0xAwcjzbbf60bzaQ3DWPapF5zhJycUgNVzf78ifC9hKwFIlK1N33+BHhkcDJscxsxgCzFvYxNHZKXhg5+zQ1r22HAShKadQfK5sC2nvesLeffirGmqw+NiyCQjKmAui5ZeOY+C/CZXiL0ttDAaCn2chqauhs6hf/3UJT3q7iNMk0dqAMNFvNzvcnHTbh23KsjcGTu1NHr92hmj8Bk+kWyYlGncOLg==
x-microsoft-antispam-prvs: <DB4PR07MB3487A339B7B953256F0B7DEC2B40@DB4PR07MB348.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(166708455590820);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(6040307)(6045199)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6061324)(6041248); SRVR:DB4PR07MB348; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB348;
x-forefront-prvs: 0134AD334F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(13464003)(189002)(5001770100001)(97736004)(3846002)(68736007)(15650500001)(8676002)(3660700001)(229853002)(106356001)(6116002)(106116001)(92566002)(105586002)(561944003)(101416001)(107886002)(102836003)(189998001)(76176999)(50986999)(7736002)(33656002)(74316002)(2950100002)(7846002)(8936002)(305945005)(2906002)(54356999)(2900100001)(76576001)(7696004)(2171001)(81156014)(6506003)(3280700002)(38730400001)(122556002)(66066001)(5660300001)(86362001)(77096005)(81166006)(9686002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB348; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2016 14:35:05.7240 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB348
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTURjHOXsvex1OTkvxcZnUyKBS81atFFEQEqkwi7YkqKFvupwX9pqk 9EFKA29llJWGOctMNzMcZlZe560huiQlMy9kZl4KQYJllub2GvTtd87v/5yH5+EwhKSMkjLq 5DRWm6zSyGgRWaJ8ofC+rwhU+g5+wfLaVjd59ycdJV8qukvJG83lAnlxVgcp7/k2TofSEfOT b6mIysplQYSuoomIImJEwXGsRp3OaveGnBMlGGazyVS99NKPgd9kFrrukoccGMCB8Ef/ks5D IkaC6xD0DjZT/OENgvlsi92QuJCA/Kl2oa1EgosF0HYlmk/1IKhYsVA2QeNgqDFZkU044wkE Y/nDhE1sxr4wUTBL29gZ+4F+7bWQZ3/In+izZ0jsCUN3bpI2FuMYqO0uWH+IWe+ghWrDeRs6 4CCY78+0JRDeCpPWCXuawK4wOl0u4MfBUNlsIXh2gbnPqxSfj4WlD4UUf78Nequ/0zwfhZaq 3I38EVjMrrYPDDifhKuNA0JeqGG1v2+jIAh0OUaCD40i6DG2Il64Q4mpc0PUU2C1dAr4dbHw 5GkO4hchhfGh3A12h9mxFqoI7Sr9bwqefWCk+DbN8x6oqlggSu172QTmkmlSh0g9cuFYjkuK 9w/wYbXqWI5LSfZJZtOMaP3TdDSseDchw0KYCWEGyRzFvuEBSgmlSucykkwIGELmLB6KDFRK xHGqjExWm3JWe1HDcia0hSFlruL9NZMKCY5XpbGJLJvKav9ZAeMgzUK39GvPux6cDk+ifkmj ew1Rha11D6eE1uLl2huvjksPqcvi2ttiHT0F7EzcA2TNTAw7DEFOHl4/RW1zc8eEl0NO3Htc YfqaoukMLZPNDAd3Pao/czJgu+vigUjjKT9zptrsRD/7GDPTOezutmPExePavoaIg15tRo8L O9/1livC3stILkHlt5vQcqq//orvVDADAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpprague/H-ZWCL57DkHtlhIboMlDFR0w6cs>
Subject: Re: [tcpPrague] [aqm] L4S status update
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 22 Nov 2016 14:35:13 -0000

Hi Roland + others.

As regards to comments around other new congestion control algorithms and that they may need adapted dropping likelihood relation between a classic queue and L4S queue.
I have not tried out but I suspect that BBR may get an unfair treatment, at the same time it is possible that other delay based CCs may suffer. 

They question however if this is a major problem?, one may as well see this as an incentive to switch over to scalable congestion controls and L4S ? There is after all no requirement to stick to a particular congestion control no matter what. ?

The question whether or not endpoint dependency should be built into the networks is of course  a valid question but given that the state of the art congestion controls like Reno and Cubic rely on a 1/sqrt(p) function then that is perhaps OK ?. 
There will for a foreseeable time come updated endpoint based congestion control algorithms that are optimized  for one thing or the other (I am guilty too :-). However if one can distinguish between two classes (classic and L4S) where classic belong to the 1/sqrt(p) family then I believe that it is possible to solve the problem. If we try find a solution where classic = "all sorts of non-scalable non-L4S dependent congestion controls" then I believe that we easily end up in big problems.

/Ingemar

> -----Original Message-----
> From: Bless, Roland (TM) [mailto:roland.bless@kit.edu]
> Sent: den 21 november 2016 15:28
> To: Bob Briscoe <ietf@bobbriscoe.net>; tsvwg IETF list <tsvwg@ietf.org>;
> TCP Prague List <tcpPrague@ietf.org>; AQM IETF list <aqm@ietf.org>; tcpm
> IETF list <tcpm@ietf.org>
> Subject: Re: [tcpPrague] [aqm] L4S status update
> 
> Hi Bob and all,
> 
> see below.
> 
> Am 01.11.2016 um 01:02 schrieb Bob Briscoe:
> > A few people have been working away to specify and document all the
> > aspects of the new Low Latency, Low Loss, Scalable throughput (L4S)
> > service, which held a successful BoF in Berlin. As the decision was to
> > try to work across multiple WGs, I thought it would be useful to give ...
> 
> Thanks for putting this together.
> 
> >   * Dual Queue Coupled AQM
> >       o With Curvy RED for Linux (access available shortly)
> >       o With PI2 for Linux <https://github.com/olgabo/dualpi2>
> > [*UPDATED*]
> 
> I'll repeat my concerns that I already expressed at the L4S BOF in Berlin:
> 
> While I agree that we probably need to separate low-delay congestion
> control schemes from traditional "queue-filling" congestion schemes, I
> strongly suggest to avoid putting a congestion control-specific coupling
> scheme into the network (a classic case for applying the "end-to-end
> arguments in system design").
> The current Dual queue coupled AQM proposal has got a coupling based on a
> congestion control specific dropping law p_C=(p_L/2)². So if congestion
> control schemes change then this coupling needs to be adapted. For
> example, the currently proposed scheme may fail if that vast majority of TCP
> traffic is using BBR other some other forthcoming CC scheme instead of
> Cubic, Reno, Compound etc. The same applies to draft-briscoe-tsvwg-ecn-
> l4s-id, section 2.5, where the dropping likelihood is defined.
> 
> Regards,
>  Roland
>