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 521023B29D; Mon, 2 Dec 2019 02:54:40 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1575273278; bh=3txVhu3gw9lbzpMO8X7NUP+0IXhPKK7I2T4ScYx8CBc=; h=X-UI-Sender-Class:Date:In-Reply-To:References:Subject:To:CC:From; b=b5Y2wrgrI/XGu8IhIA6DDKAFO2XPSsbTmB30mBVYavhmNeIx4bo8YiwkoILxE5lE8 iMql1ElFlWw9wwcP+S5fPL4Ejd95E2nWAhLeYZ7r5imNmGT+TPSSxrUmuMv71Ai4NX bZzG+RCjj0LKqdtBpAeySltliWlBmpKOAyvkDZKs= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.11.12.9] ([134.76.241.253]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MJVHe-1iME5N48YC-00Jnlr; Mon, 02 Dec 2019 08:54:38 +0100 Date: Mon, 02 Dec 2019 08:54:30 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <87lfrvl22k.fsf@taht.net> References: <63E9C0E4-C913-4B2F-8AFC-64E12489BC65@gmail.com> <297503679.4519449.1575069001960@mail.yahoo.com> <54C976BC-DEC7-4710-9CFF-0243559D9002@gmail.com> <156EA284-C01D-4FAA-89F4-DB448795F7FC@gmx.de> <385CF47C-17AD-4A62-9924-068E1485FFD5@gmail.com> <63DE3099-443D-4ADB-84ED-B1A25AB6D80C@gmx.de> <87lfrvl22k.fsf@taht.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: Dave Taht ,Jonathan Morton CC: ECN-Sane , bloat From: Sebastian Moeller Message-ID: X-Provags-ID: V03:K1:DQLbwnyfK0qZJyH65CzhCQhnrE6YHTFu/oBxTM5Xw8MeahPFc3M w6zcHGK9ArDGSCXRc48NR1ELMb8fzhUhjGT/LBW/nDCLrBQF99i0+IYfxwAtPU7FArYLV0S X8KUB3PLiE3ZwcqsnNnvnpwXeOVdbBxCMBGAQRT4O8opELvIhoOwIHKr7zlNCbXCmHH34aW Gy0foEaEKuih9QZo0aCtQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:rFLCjL7cHts=:Bl/BhgkLMJOVx9khRt+Wz7 grp/UbtdTUlp+4UYiNNJsLdOSiB9zEsfEtp0iQBesqo/nNoKxLJKljls0DtWjcdJ2yLmXYXGJ g+mIZ8ba8eZjxeCj/x1hLOJ2X6b3eKyj6hmvYOCr7MlwfLfC/HmgRlUnaNQyaOtCdQYpeSNlB S1QAk1BbP8MfDYLv2mH1frM+BJjfsUj5vyDF8p0v5/RncpbWtTyrpm0tZQRy45xm3nFJk7vIY QZYT9n6XY03PpNjlgXGdxwDc8bW5OgCjpXA6dznDr89A/hlvwXTJE5H7zm9SWCoDPjEkPdc4L bmZwRAcu2T2J0zyG4B2sIJuP+SGxeeYSqoQy0fpqv9wjcAf+f/xfAiuQLIUkjdl7djDGaqm3z C+FhqinPQpFCFgH/hrPbCcUHoUI1aulAZGdF+jRwGLEpenyWjNHITL1YNeHMvTHx1LWG5207H ovOCha7iQbjIIR3pjGaWIOkpU442bFMC14f0qZ8ZHi7GHTiTnVOdgPC52imXEbN6xxVWvr7Ua fHY+8XYkkHoRjdGUmBHN/uTdq1MpRXV8MD8mFdrgI5z1WMrC36kMc7qqXRGp/mRqrqPc7/p7Z IFw66Mma3laB+81/pqbbbyggQCPVSCsGUSUlB5k5NU5fy741y5C4wUHgOGeYBtzlnuQ7w+eOG dgw8Nk4zVPFMd0TzAWOsBTRnTZTgQuWCpyGvv8i9Pby5uV6B2iGVufz5VLkgty/q8dWf0y8Qe ESbVkAzVSxP0N2XFU8eNCkkvtNGXV1p2v7Z2YBuDwix3XcNlWPcYnUItm12ZTIqqZVkaETmln a4t7Z3URI4hnBWPfbVFJ0+3V0qarh9GpgzfyOKK2kG9V1DIiEdvAU5WVGXVJ0H0rcvbmgoUJg /6xwPx502wTyDXNt6xlarnAVjBMssL4X4vk6nCaq9UpKJyWwmQvAM7Yv7qH45jYSyuBnPIVLk NGZMjzWdnsWDae90ULP3bEstcDi1S2gRUniMD4Dp9BaNE5Ob41BDtAG9KSl4EgdqU1GRfMp1a ONJzpSJ7PBi932uqVdnCO6ThZTE5jfmQae1z6tj2OIQPtm4IA59xU8AEBA/3WvhAY71uDkgvu WndeVqY2JSApfl79shc1WQUPy7wcl8mHytzRQYlAidWpP0u7dZbEzzz3tpQ8bQzwmKc6em8I9 4h85MPP0WAHPiStAVBAIkg3aQ+SIxhKTetarR75YxhMpEL4lJOVCip3IwLoDAgN9vLPA2d86g uiylJl+yxVgnyyUiLnMM8RTdkStNMKbQAhk8DJMgykK0MwlykFl6qCccSZ2Y= Subject: Re: [Ecn-sane] [Bloat] sce materials from ietf 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, 02 Dec 2019 07:54:40 -0000 Hi Dave, On December 2, 2019 6:38:11 AM GMT+01:00, Dave Taht wrot= e: >Jonathan Morton writes: > >>> On 30 Nov, 2019, at 5:42 pm, Sebastian Moeller >wrote: >>>=20 >>>>> I fear that they will come up with something that in reality will >>>> a) by opt-out, that is they will assume L4S-style feedback until >>>> reluctantly convinced that the bottleneck marker is >>>> rfc3160-compliant and hence will b) trigger too late c) trigger to >>>> rarely to be actually helpful in reality, but might show a good >>>> enough effort to push L4S past issue #16=2E >>>>=20 >>>> I'm sure they will, and we will of course point out these >shortcomings as they occur, so as to count them against issue #16=2E =20 >>>=20 >>> That might be bad position to be in though (if one party only >>> gives negative feed-back no matter how justified it will generate a >>> residual feeling of lack of good faith cooperation), I would have >>> preferred if the requirements would have bee discussed before=2E >>>=20 >>>> Conversely, if they do manage to make it fail-safe, it is highly >>>> likely that their scheme will give false positives on real Internet >>>> paths and fail to switch into L4S mode, impairing their performance >>>> in other ways=2E >>>=20 >>> Yes, so far they always err on the advantage of L4S, and >>> justify this with "but, latency" and if one buys the latency > >I do hate watching y'all continually concede the "latency" point and Well, they have pretty graphs to wield around hitting their PR target of ~= 1ms queueing delay=2E I had a trawl through the bake-off data but all SCE r= esults I found show noticeably larger delays (not bad by any standards, but= a much harder sell than the simple <1ms story) I might not have looked to = carefully though? >have to argue on the "chosen ground" of single or dualq about >long-running tcp flows=2E=20 > >"fq" already achieves "ultra-low latency" for nearly all flows, >especially including flows in the presence of bursts, short flows that >never get out of slow start (e=2Eg=2E most of them), simple malicious >traffic, and so on=2E > >The need for any additional marking "stuff" is lessened, particularly >as >fq enables RTT based tcps such as BBR to work better in the first >place=2E > >codel has a target of 5ms where pie is 16ms=2E=20 In the dual queue draft the reference latency sits at 15ms withou= t a good rationale, I would love to see dual queue results at short RTT wit= h a theoretically justified 5 Ms target, to see whether that counteracts th= e equitable sharing failure=2E Neither achieve these, >but both come close, but the second "classic" queue in dualq is 3x >worse >than any given queue in fq_codel=2E My take on that is: Bob must have realized early on that equal sh= aring very much is not optimal, if you know more about the relative importa= nce of the flows you can do better=2E (He ignores that as the other side of= the coin you can easily do worse, simply permute the latencies and bandwid= th of the optimal asymmetric set, but I degrees) And now he struggles in ge= tting this information in the first place and in distributing it to the hop= s that are in a position to act on this information=2E The informational Co= nEx RFC 6789 is a great example of that quixotic quest, where Bob proposes = the punish flows based on their total experienced congestion on the full pa= th=2E=20 In short FQ is not perfect, but neither is anything goes, and FQ has fewer= catastrophic failure modes, and the one it has, sensitivy to flow count ca= n a) be remedied by an appropriate flow definition (maybe just a 2-tuple fo= r backbone routers, or even by AS on peering routers, already recognised in= rfc2914) and b) anything goes is equally sensitive to the same condition= =2E I really hate the line of argument, since we can not come up with a per= fect solution, let's do nothing: that is not how evolution operates=2E > >the gross unfairness of spitting l4s marked packets through a rfc3168 >compliant link is made much worse when your flows are short=2E > >both l4s and sce both seem to have an issue in aborting slow start >too early at this point=2E > >lastly, overusage of ecn in either system can bloat up a link=2E =20 According to Koen, PIE is stricter than vodel in bringing down the = hammer on flows not reacting fast enough though, so the level of ECN bloat = might be a function of the employed AQM, no? > >I'm happy to see the two primary approaches to making that less >disasterous by seeing some code arrive for shortening the MSS or "sub >packet windows", but i'd still like to see cwnd 1 and the other >fallback >methods in rfc3168 implemented, and there are still adversaries to >deal with (see rfc3168 sec 7) > >>> justification cautiously default to rfc3168 becomes obviously >>> sub-optimal, and so far none of the chairs put down the "first, do >>> no harm" hammer (and I doubt they will)=2E > >> I got the impression that failing to close most of L4S' open issues >at >> Singapore is politically damaging to them=2E This is a substantial >list >> of problems opened at Montreal, as blockers for their WGLC on >> publishing L4S drafts as experimental RFCs=2E They had all the time in > >well, I'd like to file at least one more so we can get a real >rrul test comparison done=2E > >> the world to talk about solutions to the major showstopper problems, >> but were only able to concede a point that maybe tying RACK to the >> ECT(1) codepoint is better written as a SHOULD instead of a MUST=2E >> That lack of progress was noticed at the WG Chair level; I think they >> may have been giving them the rope to hang themselves, so to speak=2E= =20 >I >> think they had a slide up at the side session, showing massive >> unfairness between L4S and "classic" flows, for a full half-hour - >and >> they somehow thought that was *helpful* to their case! > >I think there is at least a small segment of the audience that thinks >that prioritizing the internet for data coming from the ISP's or mobile >operator's DC is a very good thing=2E But also one that can get you on the hot chair with the regulator = quickly if the ISP charges extra=2E=2E=2E=20 > >It doesn't matter how (think vpn backhauls from cell towers as one >example, or coast to coast data transfers) long term disadvantagous >RTT-unfairness may be to that mindset=2E This is why I hope for more push back from the IETF community=2E= =2E=2E=2E > >Me, I love how FQ brings true RTT fairness to the internet, offering >a shot at equal bandwidth to sites near and far, bringing the world >closer together=2E I effortlessly seems to simply doba number of things pretty well = and is conceptionally simple to understand and it's behavior is easily pred= ictable, what is not to love about it, except the apparent lack of a fast i= n silicon implementation=2E=2E=2E=2E Best Regards Sebastian > > >> I'm reasonably sure some industry attendees also noticed this - >Stuart >> Cheshire (of Apple) in particular=2E Apple have been on the front >lines >> of enabling ECN deployment in practice in recent years=2E He invited >> me, one of the ICCRG chairs, and Bob Briscoe - among others - to >> dinner, where we discussed some technical distinctions and Bob >> demonstrated a fundamental misunderstanding of control theory=2E > >I am glad y'all got through dinner alive=2E > >> And we will have more ammunition at Vancouver=2E It remains to be seen >how much progress they'll make=E2=80=A6 >> >> - Jonathan Morton >> _______________________________________________ >> Bloat mailing list >> Bloat@lists=2Ebufferbloat=2Enet >> https://lists=2Ebufferbloat=2Enet/listinfo/bloat --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E