From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 133E23B29E for ; Sun, 21 Jul 2019 11:34:37 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1563723230; bh=ZuONLnHNvH6BCuR+WqGZfqlLjsc/W55yxuJUvTW+ngU=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=gFCYuZ7bxZEobMOCH/aQjDPKqlHdXWPQeo3EgWXqMRtAO03wyn1n9qEJQW9CHqpQn lPpi8KUPwYpPIFh4l4mVMGiohFCqcz/uGpzw231AKYAg/Cv4AW0XWlXL3aTFEi3Sos MR24APi0J0G/FvHhJ09QyJdzJYAZa8JTcfcd6AuM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hms-beagle2.lan ([77.185.149.150]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M6BKc-1ieKM024r4-00y7r7; Sun, 21 Jul 2019 17:33:50 +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: <22af0671-fdd0-0953-fc96-55b34beb0be9@bobbriscoe.net> Date: Sun, 21 Jul 2019 17:33:47 +0200 Cc: Jonathan Morton , "De Schepper, Koen (Nokia - BE/Antwerp)" , "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: Bob Briscoe X-Mailer: Apple Mail (2.3445.104.11) X-Provags-ID: V03:K1:09x1Ki53hS17FPICJADDnDVowghmpytJYFWJcUOrRRL/fMv+lq+ 3EXthY0KANwP9Zc2tbaTm9UHvZa2AHB2UWrXSYPi6hZ7vMrwnGYBvc9qsJqZSYrfIpC8Iu0 eqBcpm3saRd1i0hO0sifdxAdeY3ONaWxOaZWtCY91A8MFu/2FUVY8SXmhbAl0ADdo/qBC+p KeMEjpzMz3CrqRHCDORVw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:9g+H9FSrNF4=:Y6/WmSQHwNdktWZxMJbCh6 LgbDnxdBSk4v9Ikqi8LpvTQWcBD1IsRYCtwzUg2qdAZso5q4L/MtgIZW6XOY8HZrseXbM056L p1AJ7/Jcnx27/ztGJPhsn2Hb6Ec/HTEH7v2s1icPy0NxRMpOE3+ioi2sUCWm8SgpE4A7khDeE heCbvY9tVdYiEgW9losWNM6uSUulWUMlIWAAzy5jNf+MslAUGFCKKV0lHwfIpJdzaWbIwOjbS YdZtrczn/k7fyn4Or2C8AKFF4YhwBVlUVwLl7dqnMFWX+ZLK3I/pGR58T1Z2ngHcchnDDq+E9 QI8BmEWjGQbdypXZToZtbrMQQqIcf0tXAxP6pGIasHGUOlY4V80cnbltpCHcoz0LcLO6cWZhj 1Dzn+yNb1ReP8rIBgv7doi+RWMQ64UGI11yEaRevcsTU0Xlvj7ryOg9bxrKjvcoy9gWU4IRlq hCFzXXsgQSwx5SqNapBWGSaxj2JFBAhp/D5p4Q/n4ZFsfVujDzJOA0NxxbIJGAbL1ZsJbjrSI 6ReoZHZ73EljSmXhI53zTgIPxkUQpEJFp2DPtnCfcrKO/jRw07Cy0Uy8D4z0qwlXUMW7bFpi1 I8t86kbtJVros7jWVVJrf4HqQGdqEcQUN/P0Q9RJBQLMExEMX9q8tblMHodN7mtaO83JpBj/g 2+vbdZiAxm/yzI9MJPL84zAw2jw77vbQFI0fn8w5D2ZdR80hZDtWKvXDVGH0ZsJVHrY3L3/3y Lq0UDxbtzYheVnuCeWWsmquqIpDEG7FUZT0K18Wkv7P0mf+rwkb70soOL/jfC71Gjq6V6pofj ssq1Px8DMN2FRCwjVpcueRsOyBNEpMSF768/nb6ai82dABI9dZx0v/eOXppEpbv0YGnYF6xJG cQQcE5YuHBP853G58Sy68xdOHs+YV5UCHd+pyqmhasYkzH0W55ab1jsN0xVuWvY5d3SaQb7uM Hx96EhbRiyAHcGoGimqY+0YgAnY5IzQvx/WL++bAtUn1+dzEsnu6o5Vi6BXYOHOlXP5vQ9RtW t++6LWA8qP+Lwlb7pAoEKggnm/odMMHV6K93yhU5AVUXFCrpCFYdRsxk5VYApcAIoMCmY7xst 0kQ1FZBtnS51Hw= 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: Sun, 21 Jul 2019 15:34:38 -0000 Hi Bob, I hope you had an enjoyable holiday. > On Jul 21, 2019, at 13:53, Bob Briscoe wrote: >=20 > Sebastian, >=20 > On 19/07/2019 23:03, Sebastian Moeller wrote: >> Hi Jonathan, >>=20 >>=20 >>=20 >>> On Jul 19, 2019, at 22:44, Jonathan Morton = wrote: >>> So I'm pleased to hear that the L4S team will be at the hackathon = with a demo setup. Hopefully we will be able to obtain comparative test = results, using the same test scripts as we use on SCE, and also insert = an RFC-3168 single queue AQM into their network to demonstrate what = actually happens in that case. I think that the results will be = illuminating for all concerned. >> What I really would like to see, how L4S endpoints will deal = with post-bottleneck ingress shaping by an RFC3168 -compliant FQ-AQM. I = know the experts here deems this not even a theoretical concern, but I = really really want to see data, that L4S flows will not crowd out the = more reactive RFC3168 flows in that situation. This is the set-up quite = a number of latency sensitive end-users actually use to "debloat" the = internet and it would be nice to have real data showing that this is not = a concern. > 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. Great! >=20 > Nonetheless, altho it's included in the tests, I don't see the = particular concern with this 'Cake' scenario. This is not a "cake" scenario, but rather an sqm-scripts = scenario; for a number of years we have directed latency sensitive users = to use ingress and egress traffic shaping to keep latency under load = increase in check. To make things easy we offer an exemplary set of = scripts under the name sqm-scripts, see = https://github.com/tohojo/sqm-scripts, that make it easy to create and = test this approach (we also integrated it nicely into OpenWrt to make it = eve simpler to get decent de-bufferblat configured for home networks). = We implanted the general approach of an FQ-AQM as post-bottleneck = shaper, with HFSC+fq_codel (since retired), HTB+fq_codel and also with = cake, but the whole approach proceeds cake existence. Now, cake takes = most of these ideas to a new level (e.g. operating as ingress shaper to = actually shape the ingress rate instead of the shaper's egress rate), = but it is not that this approach requires cake. > 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. I have heard this repeatedly, but I want to see hard data = instead of theoretic considerations, please. Especially since nobody = bothered to think about post-bottleneck ingress shaping before I brought = it up, this certainly was not considered during the design of L4S; so if = it is not a problem, just demonstrate this to shut me up ;). So to be clear the scenario I want tested is something like the = following: 1) Internet: the test servers connected with say 10 times the true = bottleneck rate 2) "true bottleneck": say 100 Mbps / 40 Mbps (using a relative dump = over-buffered traffic shaper, like most ISPs seem to do, so at least = buffering for >=3D300ms per direction) 3) post-bottleneck ingress&egress flow-fair shaping: say 90/36 Mbps. What I want to see is that with that set-up bi-directional saturating = traffic with both RFC3168 and L4S flows that each flow still sees = roughly its fair share of the bandwidth. I fear that L4S with its linear = CE-response will react slower to AQM signals and hence will successively = eat a bit of the RFC3168-flow's bandwidth share that throttle back due = to receiving a CE mark. I hope my fears are over blown, but at the = current state it was not easy enough to actually test that myself. >=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 believe I have been clear that my concern is the effect of = under-responsive L4S-flows on the flow fairness with a post-bottleneck = ingress FQ-AQM system. So no compatibility with a "RFC3168-compliant = /single-queue/ AQM" is not the only concern. Especially since I know = that there is a community out there using post-bottleneck ingress FQ-AQM = to keep latency under load increase under control, who would be less = than impressed if L4S would destroy the effectiveness of their = "solution". Really, I wonder why the L4S project did not reach out to = this community during the design phase, since there users could be your = natural supporters assuming your solution scratches their itches = sufficiently well. Best Regards Sebastian >=20 >=20 >=20 > Bob >=20 >>=20 >> Best Regards >> Sebastian >>=20 >>=20 >>=20 >>> - Jonathan Morton >>> _______________________________________________ >>> Ecn-sane mailing list >>> Ecn-sane@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/ecn-sane >> _______________________________________________ >> Ecn-sane mailing list >> Ecn-sane@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/ecn-sane >=20 > --=20 > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ >=20