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

[Sebastian Moeller]

Well,


now I wasted my evening by going through this once again, and I remember why I forgot its content from last time around...

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