From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150111.outbound.protection.outlook.com [40.107.15.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 850853CB47 for ; Mon, 22 Jul 2019 14:15:28 -0400 (EDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QcLws8Hb/ZgKVyrEJrMI16n5oWiKWQacMGyPMzX5PHhsYqrxRs/bcCtQPBV1PPNu1JR3squeX7OE6cqOgjQzweSWiGIoXSvjq0qugVCW1yo1LaRFhZH7lYaLjvhZt5GfwAGydaULuCR5MnT8tTRS/RBuh/7Ea4qBrUS117YU8PWv10qBfu/TqR59952D4OzmC+RvnFOvzI281SL6ouUrFdzmBBEknBBK1qvyPoS1J8SSpkc30Qyt7E7Rxi5o+qALwX8KL4Q0yH2jWawPWkW+jOhsnTjg074PYCaHj2PtjDUBjy29XVYD94AJYF/ZIth7coqVUqTaonal3ybXEzp+KA== 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=Ra91XhdnOoxcInjIVkfsPtIMYvB5sCdraI3uK6SKCyw=; b=lQF8+UIv0r6pI77LArpztb9KTXhyfm7n9uZNQq0HaL29J6CplVGZB4F5HHWPiw3Ubjk7+n8kpe/+cUNWCMYsQVDN/5Q3BUrM1JTk8huEjHSnj8YgrTKRnINkTjlC028/RE0FtofBR/mbCNFuq0jBGxU0PWHPxzI/oU8ErBLoZXMhwxSxM4ttAxGpYi9qO5rB3Oc7kyJ6CwUGJbIlEsAwM02EvsEH8W4QFavx+A3rPKDNgKr7Ng4nPdAS+GcafoCqM7D/JP9vjDUh5xorsKmSAQ9nwL5N+dd2H/R6tkTIyj5CFZoQpuioEVz8ecz7FtEVKoXDx/iMI1zwWX3ly8Bcaw== 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=Ra91XhdnOoxcInjIVkfsPtIMYvB5sCdraI3uK6SKCyw=; b=zTtxG3DGD2Sfkn6NrrX8PIChA1xuW9MPFK0KjrJpxJKvHNZCGj5EEu8gr5xb/htxT5K+OsPKzXLnWjsncn1/UKMJviA8Mke1O7htIVVF9SZrr9qp8NWYXQ+PF+ZNQOTz5w3NxCblR2qyLm5gVUFRqrdlwGJuMxAkaat5m8FGOm8= Received: from VI1PR07MB3470.eurprd07.prod.outlook.com (10.175.244.148) by VI1PR07MB3118.eurprd07.prod.outlook.com (10.175.242.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.9; Mon, 22 Jul 2019 18:15:26 +0000 Received: from VI1PR07MB3470.eurprd07.prod.outlook.com ([fe80::3883:e74d:b7b2:56db]) by VI1PR07MB3470.eurprd07.prod.outlook.com ([fe80::3883:e74d:b7b2:56db%7]) with mapi id 15.20.2094.009; Mon, 22 Jul 2019 18:15:26 +0000 From: "De Schepper, Koen (Nokia - BE/Antwerp)" To: Jonathan Morton , Bob Briscoe CC: Sebastian Moeller , "Black, David" , "ecn-sane@lists.bufferbloat.net" , "tsvwg@ietf.org" , Dave Taht Thread-Topic: [Ecn-sane] [tsvwg] Comments on L4S drafts Thread-Index: AQHVP7r6M/DSnkkmG0a3KdLMJK0gSqbVO2AAgAGfyYA= Date: Mon, 22 Jul 2019 18:15:26 +0000 Message-ID: References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> <1238A446-6E05-4A55-8B3B-878C8F39FC75@gmail.com> <17B33B39-D25A-432C-9037-3A4835CCC0E1@gmail.com> <52F85CFC-B7CF-4C7A-88B8-AE0879B3CCFE@gmail.com> <87ef2myqzv.fsf@taht.net> <803D9CA8-220E-4F98-9B8E-6CE2916C3100@gmail.com> <0079BC6B-4792-48ED-90D3-D9A69407F316@gmx.de> <22af0671-fdd0-0953-fc96-55b34beb0be9@bobbriscoe.net> In-Reply-To: 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: [2001:67c:1232:144:e0f7:8312:cb27:159f] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 090eb66a-08bb-451e-04f9-08d70ed0926d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:VI1PR07MB3118; x-ms-traffictypediagnostic: VI1PR07MB3118: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01068D0A20 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(396003)(39860400002)(346002)(376002)(366004)(199004)(189003)(52294003)(13464003)(316002)(54906003)(7736002)(74316002)(6436002)(2906002)(110136005)(256004)(102836004)(229853002)(76176011)(478600001)(305945005)(86362001)(6506007)(486006)(186003)(99286004)(53546011)(476003)(25786009)(33656002)(11346002)(446003)(66574012)(14444005)(6116002)(46003)(7696005)(8676002)(66446008)(64756008)(14454004)(66476007)(8936002)(4326008)(52536014)(66556008)(66946007)(81166006)(81156014)(76116006)(5660300002)(53936002)(68736007)(71200400001)(6246003)(71190400001)(9686003)(55016002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB3118; H:VI1PR07MB3470.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-message-info: cJHXrpszf1vZbJpqLFh2VEXEb5Bv5eO7R57yPP6isB+AgP4s/q0y0szxJJdE4AvYzoWiss92reT7p5DCBBtpJK6KomLGSYtjBkaMn6Z+S40GdZnE3m6rWk3YfkYsrRPGNGreKkv67r+CCbRWUqhJy/Oc+nRiZxrvKN2hbMAagoVJNnT9t54EIXdNMT/X76aUPLytvYTg1ukpexCdpN6/kkXxzx5Up+35ettDCCmhw4dKG0NtpaVUJGPHVBSg0FGkmQ0Oa7B4gjnyYWXTjyMZfb7Gy+k9E44jmS9WlQijVbFfbvnPjwSw7KWWdLPlvziN61dZDA5ZaTtoh7DK/cFT2AfJxfy9ncBYyGrd2jl4x9HWo4W4K4M9CWVO//3R4EEaL8FgTWtt69o0vEBNySlzFRm6kmhzb0en0AROEPwQjkw= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-Network-Message-Id: 090eb66a-08bb-451e-04f9-08d70ed0926d X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2019 18:15:26.7869 (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: koen.de_schepper@nokia-bell-labs.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3118 Subject: Re: [Ecn-sane] [tsvwg] Comments on L4S drafts X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 18:15:28 -0000 Jonathan, I'm a bit surprised to read what I read here... I had the impression that w= e were on a much better level of understanding during the hackathon and tha= t : - we both agreed that the latest updates in the Linux kernels had quite som= e impact on DCTCP's performance (burstyness) that both you and we are worki= ng on. As also our testbed showed it had the same impact on DualPI2 and FQ-= Codel (yes we do understand FQ_Codel and did extensively compare DualQ with= it since the beginning of L4S). - the current TCP-Prague we have in the public GitHub, which is DCTCP using= accurate ECN and ect(1) and is drop compliant with Reno, is what SCE can u= se as well, and whatever you called SCE-TCP can be used for L4S, as (what I= showed you mathematically) it is actually perfectly working according to D= CTCP's law of 1/p, because it is DCTCP with some simple pacing tweaks you d= id. I thought we agreed that there is no difference in the congestion contr= ol part, and we want the same thing, and the only difference is how to use = the code-point. - related to the testbed setups, we have several running, the first since 2= 013. We support all kernel versions since 3.19 up to the latest 5.2-rc5. We= have demonstrated L4S since 2015 in IETF93 and the L4S BoF with real equip= ment and software that is still the same as we use today. - the testbed I brought (5 laptops and a switch that got broken during trav= el and I had to replace in the nearest shop), I had to install during the h= ackathon from scratch from our public GitHub (I arrived only at 14:00 on Sa= turday) which we made immediately available for you guys to put the flent t= esting tools on. - related to the flent testing, you might have expected to find big differe= nces, but both measurements showed exactly the same results. I understood y= ou need to extent your tools to get more measurement parameters included wh= ich were missing compared to ours. - we planned to complete your test list during this week and maybe best tha= t we jointly report on the outcome of those to avoid different interpretati= ons again. - anybody who had interest in L4S could have evaluated it since we made our= DUALPI2 code available in 2015 (actually many did). (To Dave That: if you = wanted to evaluate DualPI2 you had plenty of opportunity, 4 years by now. I= find it weird that suddenly you were not able to install a qdisc in Linux.= Even if you wanted us to setup a testbed for you, you could have asked us.= ) Maybe some good news too, we also had a (first time right) successful accur= ate ECN interop test between our Linux TCP-Prague and FreeBSD Reno (acc-ecn= implementation provided by Richard Scheffenegger). I hope these accusations of incompetence can stop now, and that we get to t= he point of finally getting a future looking low latency Internet deployed.= Anybody else who doubts on the performance/robustness of L4S, let me know = and we arrange a test session this week. Koen. -----Original Message----- From: Jonathan Morton =20 Sent: Sunday, July 21, 2019 6:01 PM To: Bob Briscoe Cc: Sebastian Moeller ; De Schepper, Koen (Nokia - BE/Antw= erp) ; Black, David ; ecn-sane@lists.bufferbloat.net; tsvwg@ietf.org; Dave Taht Subject: Re: [Ecn-sane] [tsvwg] Comments on L4S drafts > On 21 Jul, 2019, at 7:53 am, Bob Briscoe wrote: >=20 > Both teams brought their testbeds, and as of yesterday evening, Koen and = Pete Heist had put the two together and started the tests Jonathan proposed= . Usual problems: latest Linux kernel being used has introduced a bug, so n= eed to wind back. But progressing. >=20 > Nonetheless, altho it's included in the tests, I don't see the particular= concern with this 'Cake' scenario. How can "L4S flows crowd out more react= ive RFC3168 flows" in "an RFC3168-compliant FQ-AQM". Whenever it would be h= appening, FQ would prevent it. >=20 > To ensure we're not continually being blown into the weeds, I thought the= /only/ concern was about RFC3168-compliant /single-queue/ AQMs. I drew up a list of five network topologies to test, each with the SCE set = of tests and tools, but using mostly L4S network components and focused on = L4S performance and robustness. 1: L4S sender -> L4S middlebox (bottleneck) -> L4S receiver. This is simply a sanity check to make sure the tools worked. Actually we f= ell over even at this stage yesterday, because we discovered problems in th= e system Bob and Koen had brought along to demo. These may or may not be i= mproved today; we'll see. 2: L4S sender -> FQ-AQM middlebox (bottleneck) -> L4S middlebox -> L4S rece= iver. This is the most favourable-to-L4S topology that incorporates a non-L4S com= ponent that we could easily come up with, and therefore . Apparently the L= 4S folks are also relatively unfamiliar with Codel, which is now the most w= idely deployed AQM in the world, and this would help to validate that L4S t= ransports respond reasonably to it. 3: L4S sender -> single-AQM middlebox (bottleneck) -> L4S middlebox -> L4S = receiver. This is the topology of most concern, and is obtained from topology 2 by si= mply changing a parameter on our middlebox. 4: L4S sender -> ECT(1) mangler -> L4S middlebox (bottleneck) -> L4S receiv= er. Exploring what happens if an adversary tries to game the system. We could = also try an ECT(0) mangler or a Not-ECT mangler, in the same spirit. 5: L4S sender -> L4S middlebox (bottleneck 1) -> Dumb FIFO (bottleneck 2) -= > FQ-AQM middlebox (bottleneck 3) -> L4S receiver. This is Sebastian's scenario. We did have some discussion yesterday about = the propensity of existing senders to produce line-rate bursts occasionally= , and the way these bursts could collect in *all* of the queues at successi= vely decreasing bottlenecks. This is a test which explores that scenario a= nd measures its effects, and is highly relevant to best consumer practice o= n today's Internet. Naturally, we have tried the equivalent of most of the above scenarios on o= ur SCE testbed already. The only one we haven't explicitly tried out is #5= ; I think we'd need to use all of Pete's APUs plus at least one of my machi= nes to set it up, and we were too tired for that last night. - Jonathan Morton