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

["Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>]

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

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

> Best Regards
> 	Sebastian

Regards, [Some more comments inline below]
Rod

> 
> > On Aug 24, 2019, at 16:57, Dave Taht <dave@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@freebsd.org