From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 5A7D73CB3E for ; Tue, 23 Jul 2019 06:33:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1563877988; bh=lIHwbYIb76wtenit+K/CZtcQFdZx1D4FvUhVvuktILM=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=Fg7MHnZl9afbuW40ZtNtBtOI+/pJN6bNC0ss465ITPfXPIir+slVGMs+3IJgUkbAo yul9hS16x5qqEyQC3KJIkXMDvtoJ7KI7yflFVfbEwU4SWUkyi7fghhH9V+nQvzjv45 rqJExX90aNH73YZUFXWsbsaUtGPZZeZ8fxAEOUaY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hms-beagle2.lan ([77.185.124.97]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MF4eJ-1heaUx2Sr5-00GIqQ; Tue, 23 Jul 2019 12:33:08 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sebastian Moeller In-Reply-To: Date: Tue, 23 Jul 2019 12:33:06 +0200 Cc: Jonathan Morton , Bob Briscoe , "Black, David" , "ecn-sane@lists.bufferbloat.net" , "tsvwg@ietf.org" , Dave Taht Content-Transfer-Encoding: quoted-printable 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> To: "De Schepper, Koen (Nokia - BE/Antwerp)" X-Mailer: Apple Mail (2.3445.104.11) X-Provags-ID: V03:K1:Nfn1zlINeCaaV4c536HBCMHbcHqs67IBRDZcQA9pL+m4ooG33M0 3QQlk3+KDVN3aVV0Rxcfu7zBgqGpj5quiPIg40FdG358dlSHA5hCylc97BKp1shdytn3LCf FXWrFA12qMwt132hXzooZ2uiGyB0L3QiMZ8f0nBg936vGBu75gEi7lxBW94mfTE0fGiQM8G GOX/GiEntiTkavdTybyow== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:pgeBJLhI/UY=:F85iyAaJbDeR+YfYy9Jzx1 QrRzrTjAUWm/U83+7MsRtKixJzWz0//2pyroHbXO+BqgvMYD/cmvA1d+VH7GeDkv9BzO0Hh7y +bYGDdBFsGTYYPi/DXtlfyfb4J0TSEMrKHcdd+7Zjj3iX23mPMPVTtFsYHRanGQtybyGyzfhf 8amDlnTTLAM03MwKpPhCUqeiAhcRqpTXJkTPTYaM/XCC91ExNgJMZhD9904sTWxsDIYEVrgvO BlTBXQop998KE1K7u9odLRXBMQjvCkVp1jzKxY46E1wQES/33Ur5dydvD0Y4oHlkJkntGC2eM K22eB6X+QGzhauBvMSN04hYncD/C1yXeLYMKYe+oDqoyhwDbgybX6PlB8n9fiQEIbOD+mDCpm 7Nh+zgEjZ2M3FgL99tL+9ulIVjLBakW1VwQL6aYm/wtQ0UkmK6EZpxMsI+Cp+4PfYKX5VLm9u baWN0eeLf5J1wY7KkaYHz1AE9cbm878droU7gxl1050cDsMtfznNgrfFOJBh8t432r5QWq+GE k3EeinXB2L7XkxvET3yVQLtwbpNaA2VdKIgjY4lHfibRhin93DaAkH2QllVNsydNf2RtnDBYX i31teyM+L42nrzYugY36C8QIgEBV/hQKRuFcP+HXxe12FtKNz5BQdSmugU51dpNzmv6pS9lXC tsPg/fOf10JTLjzUscQZo7WrKuSFNTON1nOSW08f6pdccvh1VbptQ/PC/oNmtlTxU5VZ0UQEP Er6RG9OIELmMm331UQuH3VV2FXFwFBZjCuaXOxum4cW5jhOENmL413BDOrLI+bX8nZguYL8o3 vYYt50Wzw43Fd3cQmLY8lew9JdDV2O+WCGos8eH2SjxC0qHdVqhES59Y1QzIdObOjM7qUQt+4 ylip1LBWqFTNonPyEPpY1sP0ABiUGxzRUZ2zfKyidbdvDwOJMd3XukN+CiJnp1v7L1MUqnxng O6cpwC9ri3WpBYOLabyByMF3lKWiIpKnBC2UK/ISVgEhzd5sOV5fj8+jJdafthxPV+E31YmR9 E8HhwYuvsMox4Y7ODZ6E1MizIAYq0A25WIx6q4VVzf3wgRL3dMzzIC17DntyDXzmADkM5KkU3 BFWt6FzhC+zjug= 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: Tue, 23 Jul 2019 10:33:56 -0000 Hi Koen, > On Jul 22, 2019, at 20:15, De Schepper, Koen (Nokia - BE/Antwerp) = wrote: >=20 > Jonathan, >=20 > I'm a bit surprised to read what I read here... I had the impression = that we were on a much better level of understanding during the = hackathon and that : >=20 > - we both agreed that the latest updates in the Linux kernels had = quite some impact on DCTCP's performance (burstyness) that both you and = we are working 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 use 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 DCTCP's law of 1/p, because it is DCTCP with some = simple pacing tweaks you did. I thought we agreed that there is no = difference in the congestion control 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 2013. 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 equipment and software that is still the same as we use today. > - the testbed I brought (5 laptops and a switch that got broken during = travel and I had to replace in the nearest shop), I had to install = during the hackathon from scratch from our public GitHub (I arrived only = at 14:00 on Saturday) which we made immediately available for you guys = to put the flent testing tools on. > - related to the flent testing, you might have expected to find big = differences, but both measurements showed exactly the same results. I = understood you need to extent your tools to get more measurement = parameters included which were missing compared to ours. > - we planned to complete your test list during this week and maybe = best that we jointly report on the outcome of those to avoid different = interpretations again. > - anybody who had interest in L4S could have evaluated it since we = made our DUALPI2 code available in 2015 (actually many did). `Well, at IETF 104 there was a promise on the lists of VMs with = both endpoints for a L4S system, which as far as I can tell never = materialized, which made me refrain from testing... And I believe I did = ask/propose the VM thing on this very list and got no response. > (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.) >=20 > Maybe some good news too, we also had a (first time right) successful = accurate ECN interop test between our Linux TCP-Prague and FreeBSD Reno = (acc-ecn implementation provided by Richard Scheffenegger). >=20 > I hope these accusations of incompetence can stop now, and that we get = to the point of finally getting a future looking low latency Internet = deployed. ??? sorry to be so negative, but the "getting [...] deployed" = part is out of our control.=20 > Anybody else who doubts on the performance/robustness of L4S, let me = know and we arrange a test session this week. Not that it counts for much, but I am neither convinced of L4S = reaching its stated performance or robustness goals under adversarial = conditions and long RTTs. I am looking forward to the outcome of this = weeks testing (and hope my concerns will have been unfounded). Best Regards Sebastian >=20 > Koen. >=20 >=20 > -----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/Antwerp) ; Black, David = ; ecn-sane@lists.bufferbloat.net; tsvwg@ietf.org; = Dave Taht > Subject: Re: [Ecn-sane] [tsvwg] Comments on L4S drafts >=20 >> 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 need 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 reactive RFC3168 flows" in "an RFC3168-compliant FQ-AQM". = Whenever it would be happening, 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. >=20 > 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. >=20 >=20 > 1: L4S sender -> L4S middlebox (bottleneck) -> L4S receiver. >=20 > 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. >=20 >=20 > 2: L4S sender -> FQ-AQM middlebox (bottleneck) -> L4S middlebox -> L4S = receiver. >=20 > 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. >=20 >=20 > 3: L4S sender -> single-AQM middlebox (bottleneck) -> L4S middlebox -> = L4S receiver. >=20 > This is the topology of most concern, and is obtained from topology 2 = by simply changing a parameter on our middlebox. >=20 >=20 > 4: L4S sender -> ECT(1) mangler -> L4S middlebox (bottleneck) -> L4S = receiver. >=20 > 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. >=20 >=20 > 5: L4S sender -> L4S middlebox (bottleneck 1) -> Dumb FIFO (bottleneck = 2) -> FQ-AQM middlebox (bottleneck 3) -> L4S receiver. >=20 > 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. >=20 >=20 > 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. >=20 > - Jonathan Morton