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

Sat Aug 24 19:32:08 EDT 2019

Just for the record, the reason why I did not cross post my comments
to ecn-sane as well as tsvwg, was in the hope
that by putting the commentary on the draft there, and the venting,
here, was that it might cut down on the noise and pain level this time
around as we ramp up for another tense debate in singapore.

Certainly it's helpful to co-ordinate a good open discussion here and
official responses, there. And maybe the cc
thing between lists is the right idea? I don't know to what extent the
whole bloat list really cares about these issues? -

btw: there's 440+ people (or bots?) on bloat and 50 or so on
ecn-sane), and since g+ died, don't know of a way to give a short
"heads up" on anything. So it's my hope now that anybody caring about
the whole L4S debate has subscribed to ecn-sane and can take the
noise?

To some extent I personally of have a goal of "one post to each list"
per week of something interesting latency or edge or wifi, related
(and I do wish more popped up with interesting finds, also - I hadn't
seen the wonderful animation of the congestion avoidance either) just
to keep us conversing around the virtual water cooler. This is
considerably less traffic than the Interesting People list... There
was a time I was on irc a lot....

For example, instead of gardening today,  I just finished reading
"eccentric orbits" - which is the story of Iridium's (and to some
extent teledesic) bankruptcy and recovery - GREAT BOOK. Utterly
fascinating if you are trying to reverse engineer
how spacex starlink or amazon oneweb are going to work, or puzzled at
the machinations of big corps, high finance,
and international governments. Get it. :)

Anybody else got a space related communications book recommendation?
Something highly technical?

...

I incidentally had totally missed the AC_VO thing as a place to stick
NQB packets. AC_VO also has the CS6 problem. And on wireless-n cannot
aggregate (ac and later can). Thx for pointing that out.

It's looking potentially like much less a problem on 802.11ax gear...
once it ships on both clients and aps.

The VI class (CS4 or CS5) however, is seemingly a good place to stick
some intended L4S-ish flows - at least from an IPTV or interactive
video (VR) perspective it's a decent place, I think - a bounded txop,
mild extra priority. For bigbuckbunny & netflix, though, no so much,
and of course, if everybody marked packets CS4 or CS5 nobody would
win. (actually if universal, they might - bandwidth would go down, but
txop size would be more limited so we'd multiplex between stations
better - I'd really like us in the wifi work to limit txop size both
on the ap and in the beacon, under load)

I incidentally :cough: mark all my ssh/mosh packets CS4 when in a
horrible wifi environment. It's evil of me, I suppose, but it lowers
my jitter related stress level in multiple coffee shops I frequent
(and haven't helped fix yet)

On Sat, Aug 24, 2019 at 2:59 PM Sebastian Moeller <moeller0 at gmx.de> wrote:
>
> Well,
>
>
> now I wasted my evening by going through this once again, and I remember why I forgot its content from last time around...

thx for taking the time! Got a good book to read yourself to sleep with?

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

Yes. Really need to combat the FUD.

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

I'm very, very happy to have seen multiple other IETF members demand
this clear distinction in the documents
instead of the marketing driven phrasology.

I plan to adopt this clearer terminology instead of what I'd been using.

> >>>
> >>> 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
>
> _______________________________________________
> Ecn-sane mailing list
> Ecn-sane at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ecn-sane

--

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740