General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Sebastian Moeller <moeller0@gmx.de>
To: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Cc: Dave Taht <dave@taht.net>,
	ECN-Sane <ecn-sane@lists.bufferbloat.net>,
	bloat@lists.bufferbloat.net
Subject: Re: [Bloat] [Ecn-sane] non queue building flows ietf draft review.
Date: Sat, 24 Aug 2019 23:59:40 +0200	[thread overview]
Message-ID: <3534C5ED-2F1F-4785-AAE2-7FC1E7DFB02F@gmx.de> (raw)
In-Reply-To: <201908241627.x7OGR0ia068613@gndrsh.dnsmgr.net>

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


       reply	other threads:[~2019-08-24 21:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <201908241627.x7OGR0ia068613@gndrsh.dnsmgr.net>
2019-08-24 21:59 ` Sebastian Moeller [this message]
2019-08-24 23:32   ` Dave Taht
2019-08-24 14:57 [Bloat] " Dave Taht
2019-08-24 15:37 ` [Bloat] [Ecn-sane] " Sebastian Moeller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3534C5ED-2F1F-4785-AAE2-7FC1E7DFB02F@gmx.de \
    --to=moeller0@gmx.de \
    --cc=4bone@gndrsh.dnsmgr.net \
    --cc=bloat@lists.bufferbloat.net \
    --cc=dave@taht.net \
    --cc=ecn-sane@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox