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 <4b...@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 <d...@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 rgri...@freebsd.org
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
