Re: [tsvwg] [Ecn-sane] Comments on L4S drafts

Sebastian Moeller <moeller0@gmx.de> Sun, 21 July 2019 16:13 UTC

Return-Path: <moeller0@gmx.de>
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 78E69120098 for <tsvwg@ietfa.amsl.com>; Sun, 21 Jul 2019 09:13:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Level:
X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 oyHQAlLdUtG9 for <tsvwg@ietfa.amsl.com>; Sun, 21 Jul 2019 09:13:14 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E41D120075 for <tsvwg@ietf.org>; Sun, 21 Jul 2019 09:13:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1563725542; bh=i1TewBtxvYpvcByNEzJ3PE1jbQPQTp90One9amQFrMk=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=aoAUTmHz3+OvWmIFT8lQuny77Z3kQavsI4d/2CB78cS8SSgZVhCSGSlqDuNWwo8CD 1sl2aT4ntWolXmxv8Nm9+ZTQ9Zy54uqA4S1UT/mRJEurkjrSxV7GkRBbsaSti4qOx+ zwT26l9CPH9FXGwvuvQKpE8+ImpX23x8IjBmDps0=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([77.185.149.150]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MhU9j-1iKjW11NY3-00ecqj; Sun, 21 Jul 2019 18:12:22 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <AC3C0A74-43C7-4351-B4FA-33AD2066B479@gmail.com>
Date: Sun, 21 Jul 2019 18:12:20 +0200
Cc: Bob Briscoe <in@bobbriscoe.net>, "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>, "Black, David" <David.Black@dell.com>, "ecn-sane@lists.bufferbloat.net" <ecn-sane@lists.bufferbloat.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>, Dave Taht <dave@taht.net>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C2EFEAA7-9829-42D9-9155-49C9DC958FDC@gmx.de>
References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> <1238A446-6E05-4A55-8B3B-878C8F39FC75@gmail.com> <AM4PR07MB3459B1173917DAFBCEB25511B9FA0@AM4PR07MB3459.eurprd07.prod.outlook.com> <17B33B39-D25A-432C-9037-3A4835CCC0E1@gmail.com> <AM4PR07MB345956F52D92759F24FFAA13B9F50@AM4PR07MB3459.eurprd07.prod.outlook.com> <52F85CFC-B7CF-4C7A-88B8-AE0879B3CCFE@gmail.com> <AM4PR07MB3459B471C4D7ADAE4CF713F3B9F60@AM4PR07MB3459.eurprd07.prod.outlook.com> <D231681B-1E57-44E1-992A-E8CC423926B6@akamai.com> <AM4PR07MB34592A10E2625C2C32B9893EB9F00@AM4PR07MB3459.eurprd07.prod.outlook.com> <A6F05DD3-D276-4893-9B15-F48E3018A129@gmx.de> <AM4PR07MB3459487C8A79B1152E132CE1B9CB0@AM4PR07MB3459.eurprd07.prod.outlook.com> <87ef2myqzv.fsf@taht.net> <a85d38ba-98ac-e43e-7610-658f4d03e0f4@mti-systems.com> <CE03DB3D7B45C245BCA0D243277949363062879C@MX307CL04.corp.emc.com> <803D9CA8-220E-4F98-9B8E-6CE2916C3100@gmail.com> <0079BC6B-4792-48ED-90D3-D9A69407F316@gmx.de> <22af0671-fdd0-0953-fc96-55b34beb0be9@bobbriscoe.net> <AC3C0A74-43C7-4351-B4FA-33AD2066B479@gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:gRqczlIqh/RMUYkZ3cy1NzC0ntK9xw2vRBhVGn8JbxSItCaATBP P9PTXzPQVXjH8TI4FSg+Gx1PTdLD4JU3WLCErko0ayTL3h0IMwPc9xZ24XjdqXgrOfTs07/ 3vLdqIPotDomewdqw2aWtZrUJaqETxgiD6gARQ0JZ3vWlaZl2OK5ZM7U/MLUen8Wx9V+IdG UUwZXSxJVWR5IzB4t6iHg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:1q9mTFDKcwY=:WCMzOOa2+d71NpgLreCT8f NLYi79e2yNGI9Sdr0v5OyUvcEIONkhhmBIsUR2SH6fdRf4unxTjXIRCCTwP54S+OQpRxCr4v+ Wjf27Y7PkGuLs0GckD+WJF/lMN4Q4VQQwXZg7IkTmEquGiErZ13VqEpwhGZL30UVt5ccOcg4j 74srXd7R9hX8yrPAx9sI2US+rWOnCVox48A8ZYmwlxkgritFOpdtzu+3O8yjwBsWaQWRP0GQ8 zdrCEA8AoDVrC6Qx2lXnda9Haz99DjxLDz1cD335/JTvCQyEytMloYJsWnRzLmc73nu2RJ4Jl m03sKKpHN7VAbbRLPCCBkvTkIlcg/MoBHknq9vPug0ikZDBvQA5tJQfY1WakO6zt1fFpV4kxy wnzwwqpzlVPQopYZZN99N7pU/gS/NAAhmBkxTeRETeO+sY5GTYP1bc5cDUcWRyKiT8Z/srN0b wO3Bg5QSBhD2Ugpy7JKvUkHAl7QfkKawW8VEFL+kKxaIhlIoqR8vmouj5bgUMxDo5FNBgf3Ff GdiSzS40RS1HzvvDaYyla/jZmtVqw/Gph/l1cw+I4ZwdcuQi8vw+BT2hmjh9L1kjTq1Fti2G7 oAaOqD61o26+nusZdd/nm2SH8aEvI42t4XiyhMo5fWjBLHJddtT00teQ8xxx8f+Cb+0MzgeCK 0nTiS21gt/lvf3uvdnxQg40E4ENfFk354fMax3pAHzvnDzz1jx1jnh6ncmhYWyo19eNkBh5Oj kfBCYfsROBrhrBnbA3ROd5Hbg34pu7Jsd2qu/fhJg4fKj2i5F9PXVdCs+V5jDD/qcTdKQjycG HTZFKA9VWOoZXd/7WDFmuxA6IhHrAkiZOwzSh2y57Xx3bXDOPczcagOA+ctqfJmAwXuKtjcne 0XBUHpesuMHw8BKbfC8OjVDtcM1wJrzI5p5Dd7X/OwvtMi8t7zBh7aGhq6imp0ONO25oL9z9S coMxdgsYeITURhHbxQtoz9fgWqfJUf/GmH272kZKtFbG1B1mZz+F5YDnfCxiu80xa1jNRLkSm 7982p7rEJOCMIvGHNq++gcPeAtOggVZQPYJwEOeVHg37DrVa6ScQ7yjzw/uRBrkyMNcKs6s+h 48FvwPvS0q7Y7Y=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/_3-1LZxTBZc6WJ798WGKsVpwZbA>
Subject: Re: [tsvwg] [Ecn-sane] Comments on L4S drafts
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: Sun, 21 Jul 2019 16:13:17 -0000

Dear Jonathan,

many thanks, these are exactly the tests I am curious about. Excellent work, now I am super curious about the results!



> On Jul 21, 2019, at 18:00, Jonathan Morton <chromatix99@gmail.com> wrote:
> 
>> On 21 Jul, 2019, at 7:53 am, Bob Briscoe <in@bobbriscoe.net> wrote:
>> 
>> 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 need to wind back. But progressing.
>> 
>> 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 reactive RFC3168 flows" in "an RFC3168-compliant FQ-AQM". Whenever it would be happening, FQ would prevent it.
>> 
>> 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 fell over even at this stage yesterday, because we discovered problems in the system Bob and Koen had brought along to demo.  These may or may not be improved today; we'll see.
> 
> 
> 2: L4S sender -> FQ-AQM middlebox (bottleneck) -> L4S middlebox -> L4S receiver.
> 
> This is the most favourable-to-L4S topology that incorporates a non-L4S component that we could easily come up with, and therefore .  Apparently the L4S folks are also relatively unfamiliar with Codel, which is now the most widely deployed AQM in the world, and this would help to validate that L4S transports 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 simply changing a parameter on our middlebox.
> 
> 
> 4: L4S sender -> ECT(1) mangler -> L4S middlebox (bottleneck) -> L4S receiver.
> 
> 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 successively decreasing bottlenecks.  This is a test which explores that scenario and measures its effects, and is highly relevant to best consumer practice on today's Internet.

	double plus!



> 
> 
> Naturally, we have tried the equivalent of most of the above scenarios on our 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 machines to set it up, and we were too tired for that last night.

	Thanks for doing this!

Best Regards
	Sebastian


> 
> - Jonathan Morton