[Ecn-sane] non queue building flows ietf draft review.

Sun Aug 25 13:26:02 EDT 2019

Hi Dave,

> On Aug 25, 2019, at 01:32, Dave Taht <dave.taht at gmail.com> wrote:
> 
> 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.

> 
> 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.

> 
> 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 ;)

> 
> 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....
> 
> 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...)

> 
> Anybody else got a space related communications book recommendation?
> Something highly technical?
> 
> ...
> 
> 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.

> 
> 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...

> 
> 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.

> 
> 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?

> 
> On Sat, Aug 24, 2019 at 2:59 PM Sebastian Moeller <moeller0 at gmx.de> wrote:
>> 
>> Well,
>> 
>> 
>> now I wasted my evening by going through this once again, and I remember why I forgot its content from last time around...
> 
> 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.

> 
>> 
>> I am with Dave, it is a bit wordy for effectively saying let's call 2A = NBQ, and it comes with loads of tangential text that really seems to belong to an actually substantial L4S RFC.
>> 
>> 
>> 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).
> 
> 
>> 
>> 
>> 
>>> On Aug 24, 2019, at 18:27, Rodney W. Grimes <4bone at gndrsh.dnsmgr.net> wrote:
>>> 
>>>> Hi Dave,
>>>> 
>>>> 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...  ;)
>>> 
>>> 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.
>> 
>>        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)
>> 
>>> 
>>> 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."
>> 
>>        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.
>> 
>>> 
>>>> (I have started to read this thing ages ago and blissfully forgot all about it, time to read it agian?)
>>> 
>>> Yes, please, everyone read it again and comment on it,
>>> it is very far along in the process now.
>> 
>>        From my perspective the 2A=NBQ part is fine it is all the rest that seems superfluous.
>> 
>>> 
>>>> Best Regards
>>>>     Sebastian
>>> 
>>> Regards, [Some more comments inline below]
>>> Rod
>>> 
>>>> 
>>>>> On Aug 24, 2019, at 16:57, Dave Taht <dave at taht.net> wrote:
>>>>> 
>>>>> 
>>>>> I decided that perhaps it would be best if we tried harder
>>>>> to live within the ietf's processes for calm, reasoned discussion
>>>>> 
>>>>> But in trying to review this internet draft...
>>>>> 
>>>>> https://tools.ietf.org/id/draft-white-tsvwg-nqb-02.html
>>>>> 
>>>>> I couldn't help myself, and my review is here:
>>>>> 
>>>>> https://mailarchive.ietf.org/arch/msg/tsvwg/hZGjm899t87YZl9JJUOWQq4KBsk
>>>>> 
>>>>> 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.
>>> 
>>> 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)
> 
> Yes. Really need to combat the FUD.
> 
>>> 
>>> 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.
> 
> 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?

> 
> 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

> 
> 
>>>>> 
>>>>> 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.
>>>>> 
>>>>> Some days it doesn't pay to read your accrued inbox messages. Today
>>>>> was one of them. You needen't read mine either!
>>> 
>>> Regards Again,
>>> --
>>> Rod Grimes                                                 rgrimes at freebsd.org
>> 
>> _______________________________________________
>> Ecn-sane mailing list
>> Ecn-sane at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/ecn-sane
> 
> 
> 
> --
> 
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-205-9740