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