From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 927BA3B29E for ; Sun, 25 Aug 2019 13:26:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1566753964; bh=m6IS7NrhWswjqws04J01zhGCRuNRSeC+rHEMxX4M7Es=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=K7b7HIAPPbv3+dllmWsguWaMiKEoJSU0LLern6E9D7uCWzXRdHb/+sepahbduojgk cnVIIJ+hE5mHWoAa4bPFFyHjDvISSER07zjMdGOAbZGqZTSxitB947Ng2xcNEu82wg qkx032tnyxfJGyVtfLUF2kOiDqSRz0YCPWw7xQ7Q= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hms-beagle2.lan ([77.185.78.199]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MMYZG-1i97133EnW-008IWl; Sun, 25 Aug 2019 19:26:04 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sebastian Moeller In-Reply-To: Date: Sun, 25 Aug 2019 19:26:02 +0200 Cc: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, ECN-Sane , Dave Taht Content-Transfer-Encoding: quoted-printable Message-Id: References: <201908241627.x7OGR0ia068613@gndrsh.dnsmgr.net> <3534C5ED-2F1F-4785-AAE2-7FC1E7DFB02F@gmx.de> To: =?utf-8?Q?Dave_T=C3=A4ht?= X-Mailer: Apple Mail (2.3445.104.11) X-Provags-ID: V03:K1:Ht35zp99EiKfkGhjY67Cfft+cWuWdVpiEeMLko0yiigb18MFLTi bfjEyCKllGUtMNgSA8nGfl/MAED8V83kSqh9qnFx0mlKVd5sQa+9iY4niKHO9JcMlvFhnLx CXnwp55dwcOHHRloVF+oUV6LlwXYugHsHSpde/p2O6LspgCur91vK23/L1vsEXE1/tRz3rp 18lOGNHWjG75K4LMeK2pA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:0Qn8FrFQhL8=:lM8UuAOOlDmtKe4BM2L0hl tMVSyqrOPHuMg0RWWMcydc6mKsqFqt0Ldt+zg64qwjFKlqPX3Kmvzs9SkDspnHNjQJtmuTh7D HmgGY8uEttyvaHBHK2DWd8PpQljF5J625q1ggm3RJ1N2CkhxDkieHY5aMFocr3lkL7E0Owf+E W3WtxESByJpwhXdb0LW+vBIiAn3Xc2YygE8ePG3XOgPW/MFFIo07Ow8WW93N6cGMunhYLXbp0 uKNAfSLzLu0MET5aWCNRdrVP0/P6KzohS66A0K7RyEhhVYoEQP8hdopQhmQC7eDcUnaIcSPo4 xHKcMQvB37SR4S+299gsB1+Yz3wwgw9xVjXRmJ20BdVMqVbQSERwuNLB2w7psTT1t90BsDozK v4VHdtiDDOjgrNCzxrYNEssFp+ZV5psjWjFXysoHSHo5SI3Elt1Cz6EF0Xy+RpqgOdb6F/O0E 1eWLZ6jG1L81wAXg7XYI7OSuvn1Ot/vRdM9IJI9pGetT4LFtZv3T/7tmpa72g+E8KZBVfVuch vqv14V0cOi5OgfOkMM83Y6hUVDPqwhAC/ZOK3KBf4+D+Vb/p47WIkL5O1PrWp1jz9806aLp1l 8bg0I+Q8XxjovpLUeUuzDBsi3XmrRbRBVUMJcg7/J7Cir5m7szJpelLKjEIW+CoeDMnkS68bZ ydu8BdMEwuRL4FbCj4XqDXpegj8226lCS/IVtEEYUVrUrpjFs7zPwPzTOinEX5Jqo99F06j37 GpbkL37XuUC3Vf3D67piAzuFs5c/d+JcSbGbna4x8y2JAUv2rZHazW5SC3eC3TbQnBOaL3Hoe TvjIR75EhQF9QWc7dAce9w47na5IQxbiw7b8QPVxNDS0Ks0OASPttBX0JL8nIqlP5Kcv59deS RAx6Q103OuHjynXfj8RgL8RKjGNGu58+yT3eVpBR/22pzc0sIbYC/i/IXoIRqsu87kj8OBLMf nCnO1PL4gQMMvJy+lh+Eg1BRcm8hDlTUxF93dIEllBrDFa1vp0WlAuEDdZzHZD0/bpInKcm6I vRWFnnLDEFm1vsT1F3ah6QztXgKIhNUuF8vfsYByVy0NY1CECK2Bijozpw5qAwda8y9M+OnnJ zpgci4S0iPHq6M15ZHyQ5700S1WfrbGICwizCte5YddU955NbLbyrEfkrO7JCUvZgY8ffxz3W x0TQAQe4WGxUBOqjCcbrOlFJIsVeyhA41KnpN02gkA5cHljg== Subject: Re: [Ecn-sane] non queue building flows ietf draft review. 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, 25 Aug 2019 17:26:06 -0000 Hi Dave, > On Aug 25, 2019, at 01:32, Dave Taht wrote: >=20 > Just for the record, the reason why I did not cross post my comments > to ecn-sane as well as tsvwg, was in the hope > that by putting the commentary on the draft there, and the venting, > here, was that it might cut down on the noise and pain level this time > around as we ramp up for another tense debate in singapore. Oops, sorry I included bloat without much thinking, never a good = idea. >=20 > Certainly it's helpful to co-ordinate a good open discussion here and > official responses, there. I fully concur, especially since I often misunderstand things = intially, so having a friendly venue where I can query calmer mor = experienced heads is certainly a good idea. > And maybe the cc > thing between lists is the right idea? I don't know to what extent the > whole bloat list really cares about these issues? - Goos question, probably not much. >=20 > btw: there's 440+ people (or bots?) on bloat and 50 or so on > ecn-sane) Funny, I came for the de-bloat and stayed for the ECN ;) > and since g+ died, don't know of a way to give a short > "heads up" on anything. So it's my hope now that anybody caring about > the whole L4S debate has subscribed to ecn-sane and can take the > noise? I wonder whether the L4S issue is not actually relevant to the = bloat crowd? It certainly comes with sufficient drama ;) >=20 > To some extent I personally of have a goal of "one post to each list" > per week of something interesting latency or edge or wifi, related > (and I do wish more popped up with interesting finds, also - I hadn't > seen the wonderful animation of the congestion avoidance either) just > to keep us conversing around the virtual water cooler. This is > considerably less traffic than the Interesting People list... There > was a time I was on irc a lot.... >=20 > For example, instead of gardening today, I just finished reading > "eccentric orbits" - which is the story of Iridium's (and to some > extent teledesic) bankruptcy and recovery - GREAT BOOK. Utterly > fascinating if you are trying to reverse engineer > how spacex starlink or amazon oneweb are going to work, or puzzled at > the machinations of big corps, high finance, > and international governments. Get it. :) I wish I would find to read a book anytime soon. (My reading = list consists out of Mark Twain's autobiography and the Beastie Boys = Book, none of which is terribly compatible with my current bus commute, = nor space related...) >=20 > Anybody else got a space related communications book recommendation? > Something highly technical? >=20 > ... >=20 > I incidentally had totally missed the AC_VO thing as a place to stick > NQB packets. AC_VO also has the CS6 problem. And on wireless-n cannot > aggregate (ac and later can). Thx for pointing that out. As we say at home, "even a blind chicken occasionally finds a = grain". It took some dedication to actually read through the draft, = albeit in all fairness compared to he other L$S drafts this was = refreshingly brief and concise. >=20 > It's looking potentially like much less a problem on 802.11ax gear... > once it ships on both clients and aps. The grass is always greener in the future (modulo the effects of = global warming). No excuse for detoriating the life for 11n and 11ac = users... >=20 > The VI class (CS4 or CS5) however, is seemingly a good place to stick > some intended L4S-ish flows - with emphasis on "some", the L4S idea of treating all flows to = the same low-latency treatment makes an L4S dscp completely incompatible = with anything except AC_B in my book. Unless I misunderstand the scoope = of NQB, if this marking excludes bulk flows things _might_ be = acceptable. > at least from an IPTV or interactive > video (VR) perspective it's a decent place, I think - a bounded txop, > mild extra priority. For 11ac, as far as I can tell the txop is bounded, but larger = than the AC_BE txop, no? > For bigbuckbunny & netflix, though, no so much, > and of course, if everybody marked packets CS4 or CS5 nobody would > win. That reminds me of my old idea of having your AP monitor the = distribution of the different ACs and adjust its own AC to guarantee = some reasonable airtime access (I came to this observatiun when I saw my = macbook in RRUL tests completely pummel the AP's tx rate). > (actually if universal, they might - bandwidth would go down, but > txop size would be more limited so we'd multiplex between stations > better - I'd really like us in the wifi work to limit txop size both > on the ap and in the beacon, under load) +1, latency over bandwidth. Except the wifi MACs impressively = large preamble setting a lower bound on reasonable txop length (for bulk = flows). But I might misremember things a bit, this is my hobby, not my = profession. >=20 > I incidentally :cough: mark all my ssh/mosh packets CS4 when in a > horrible wifi environment. It's evil of me, I suppose, but it lowers > my jitter related stress level in multiple coffee shops I frequent > (and haven't helped fix yet) Ah, come on, you are not going full mental with CS6/7 ans AC_VO = ;). This just demonstrates that in a shared ressource system like wifi = the whole WMM abstraction is not a good match to reality, no? >=20 > On Sat, Aug 24, 2019 at 2:59 PM Sebastian Moeller = wrote: >>=20 >> Well, >>=20 >>=20 >> now I wasted my evening by going through this once again, and I = remember why I forgot its content from last time around... >=20 > thx for taking the time! Got a good book to read yourself to sleep = with? Yes, I just need to actually go put it next to the bed and read = it instead of light browsing of the web. >=20 >>=20 >> I am with Dave, it is a bit wordy for effectively saying let's call = 2A =3D NBQ, and it comes with loads of tangential text that really seems = to belong to an actually substantial L4S RFC. >>=20 >>=20 >> I wrote way to much and I am way to remote of all of this but I will = try to just extract the most relevant part of my draft (the wifi = recommendation map NBQ to AC_VO is horrendously wrong IMHO). >=20 >=20 >>=20 >>=20 >>=20 >>> On Aug 24, 2019, at 18:27, Rodney W. Grimes = <4bone@gndrsh.dnsmgr.net> wrote: >>>=20 >>>> Hi Dave, >>>>=20 >>>> fun fact, the draft is titled "Identifying and Handling Non Queue = Building Flows in a Bottleneck Link". >>>> To which the _only_ and obvious answer is one does this by by = observing flow-behavior on the element that egresses into the bottleneck = link. >>>> Case closed, Nothing to see folks, you can go home... ;) >>>=20 >>> As Dave points out, and probably his strongest point, >>> this is yet another attempt to have sources classify thier >>> traffic for HIGHER priority or LOWER latency and ignore or >>> hand wave away the security (DOS) implications that causes. >>=20 >> It has other issues as well, like misunderstanding with equal = sharing under load is a rational strategy and believing that the queue = protection method as pseudo-coded on the docsis standard document are = anything but a poor man's fq system (and rather rich to point at = fq_codel's hash collision issue over (default) 1024 flows, while queue = protect seems to only use 32 queues, plus a catch all flow for all the = rest, tell me with a straight face that the fate sharing going on in = that bucket is going to be less severe than the hash collisions in a = 1024 flow system) >>=20 >>>=20 >>> You can do that type of thing in a controlled situation, >>> even as large as a whole AS, but this can never succeed >>> at the scale of "Internet." >>=20 >> I believe all of this is not really aimed for the internet = anyway. What I see are building blocks for a low latency highway from = the (DOCSIS)-ISP to directly connected data centers, and I am not sure I = want that. >>=20 >>>=20 >>>> (I have started to read this thing ages ago and blissfully forgot = all about it, time to read it agian?) >>>=20 >>> Yes, please, everyone read it again and comment on it, >>> it is very far along in the process now. >>=20 >> =46rom my perspective the 2A=3DNBQ part is fine it is all the = rest that seems superfluous. >>=20 >>>=20 >>>> Best Regards >>>> Sebastian >>>=20 >>> Regards, [Some more comments inline below] >>> Rod >>>=20 >>>>=20 >>>>> On Aug 24, 2019, at 16:57, Dave Taht wrote: >>>>>=20 >>>>>=20 >>>>> I decided that perhaps it would be best if we tried harder >>>>> to live within the ietf's processes for calm, reasoned discussion >>>>>=20 >>>>> But in trying to review this internet draft... >>>>>=20 >>>>> https://tools.ietf.org/id/draft-white-tsvwg-nqb-02.html >>>>>=20 >>>>> I couldn't help myself, and my review is here: >>>>>=20 >>>>> = https://mailarchive.ietf.org/arch/msg/tsvwg/hZGjm899t87YZl9JJUOWQq4KBsk >>>>>=20 >>>>> If someone could make something constructive out of that, great. = It >>>>> would be good to have a really clear definition of what we mean by >>>>> sparse, and good definition and defense on our website of the = properties >>>>> and benefits of fair queueing. >>>=20 >>> I concur that a good, concise and complete definition of "sparse = flow" would be useful. >>> I would also like to see a good glossary of all the terms tossed = around so often, >>> FQ, CoDel (vs FQ_CoDel vs non FQ Codel which is often ambigous in = scope as to which >>> of the three are actually being referenced) >=20 > Yes. Really need to combat the FUD. >=20 >>>=20 >>> And from another thread calling things "Classic" needs to die, >>> it is about as good as calling things "New", it is not Classic ECN, >>> it is RFC3168 ECN, it is not Classic TCP, it is RFC793 TCP, etc al. >=20 > I'm very, very happy to have seen multiple other IETF members demand > this clear distinction in the documents > instead of the marketing driven phrasology. +1, the fact that David requested RFC 3168 ECN instead of = classic ECN made me smile, btw. am i the only on remembering the "new = coke" vs. "classic coke" marketing kerfuffle? >=20 > I plan to adopt this clearer terminology instead of what I'd been = using. Can we somewhere note this new terminology as reference? I had = the impression the draft did argue against a hypothetical straw-man = fq_codel and it would be great to have a likk to paste foe a veridical = summary of the rfc-compliant fq_codel. Best Regards Sebastian >=20 >=20 >>>>>=20 >>>>> And I'm going to go off today and try to do something nice for a = small >>>>> animal, a widow, or an orphan. Maybe plant some flowers. >>>>>=20 >>>>> Some days it doesn't pay to read your accrued inbox messages. = Today >>>>> was one of them. You needen't read mine either! >>>=20 >>> Regards Again, >>> -- >>> Rod Grimes = rgrimes@freebsd.org >>=20 >> _______________________________________________ >> Ecn-sane mailing list >> Ecn-sane@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/ecn-sane >=20 >=20 >=20 > -- >=20 > Dave T=C3=A4ht > CTO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-831-205-9740