Re: [tcpPrague] [aqm] L4S status update

Ingemar Johansson S <> Tue, 22 November 2016 14:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE543129A31; Tue, 22 Nov 2016 06:35:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0hCvR9R4Aa6X; Tue, 22 Nov 2016 06:35:10 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D3666129A32; Tue, 22 Nov 2016 06:35:08 -0800 (PST)
X-AuditID: c1b4fb2d-0bbff70000000994-3d-5834579a78fc
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 2B.25.02452.A9754385; Tue, 22 Nov 2016 15:35:07 +0100 (CET)
Received: from ( by ( 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;; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1JSHM/0OUFhHIn5RGOnp/Kg57Lkxpn9QEhr1rxGpBHc=; b=glHPGBWAUAIijOAoorT9dOIIFXuUwyyNuSpIjsfYeYuCsAc8zughLWCroYACjZfvH+sNtl8I03Tv0JXRJNHw72MERxtq2GolkN7eQZ50bDDTVEqHKgQPX0msj508XyYuPIIWl8jpncUbymTFDXUwSF9RfqACvwYhkuQEDqn6tMg=
Received: from ( by ( 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 ([]) by ([]) with mapi id 15.01.0747.006; Tue, 22 Nov 2016 14:35:05 +0000
From: Ingemar Johansson S <>
To: "Bless, Roland (TM)" <>, Bob Briscoe <>, tsvwg IETF list <>, TCP Prague List <>, AQM IETF list <>, tcpm IETF list <>
Thread-Topic: [tcpPrague] [aqm] L4S status update
Thread-Index: AQHSRDIMrBiIIyXAnkeCaadJdlnwcqDlDZUg
Date: Tue, 22 Nov 2016 14:35:05 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: sv-SE, en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
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: <>
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;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( 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-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: <>
Subject: Re: [tcpPrague] [aqm] L4S status update
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


> -----Original Message-----
> From: Bless, Roland (TM) []
> Sent: den 21 november 2016 15:28
> To: Bob Briscoe <>; tsvwg IETF list <>;
> TCP Prague List <>; AQM IETF list <>; tcpm
> IETF list <>
> 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 <>
> > [*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