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

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

[Dave Taht]

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. 

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!

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

[Sebastian Moeller]

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...  ;)
(I have started to read this thing ages ago and blissfully forgot all about it, time to read it agian?)

Best Regards
	Sebastian



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

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

[Rodney W. Grimes]

> 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

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

[Sebastian Moeller]

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

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

[Dave Taht]

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

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@freebsd.org
>
> _______________________________________________
> Ecn-sane mailing list
> Ecn-sane@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

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

[Sebastian Moeller]

Hi Dave,


> On Aug 25, 2019, at 01:32, Dave Taht <dave.taht@gmail.com> wrote:
> 
> 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.

	Oops, sorry I included bloat without much thinking, never a good idea.

> 
> Certainly it's helpful to co-ordinate a good open discussion here and
> official responses, there.

	I fully concur, especially since I often misunderstand things intially, so having a friendly venue where I can query calmer mor experienced heads is certainly a good idea.

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

	Goos question, probably not much.

> 
> btw: there's 440+ people (or bots?) on bloat and 50 or so on
> ecn-sane)

	Funny, I came for the de-bloat and stayed for the ECN ;)


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

	I wonder whether the L4S issue is not actually relevant to the bloat crowd? It certainly comes with sufficient drama ;)

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

	I wish I would find to read a book anytime soon. (My reading list consists out of Mark Twain's autobiography and the Beastie Boys Book, none of which is terribly compatible with my current bus commute, nor space related...)

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

	As we say at home, "even a blind chicken occasionally finds a grain". It took some dedication to actually read through the draft, albeit in all fairness compared to he other L$S drafts this was refreshingly brief and concise.

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

	The grass is always greener in the future (modulo the effects of global warming). No excuse for detoriating the life for 11n and 11ac users...

> 
> The VI class (CS4 or CS5) however, is seemingly a good place to stick
> some intended L4S-ish flows -

	with emphasis on "some", the L4S idea of treating all flows to the same low-latency treatment makes an L4S dscp completely incompatible with anything except AC_B in my book. Unless I misunderstand the scoope of NQB, if this marking excludes bulk flows things _might_ be acceptable.


> at least from an IPTV or interactive
> video (VR) perspective it's a decent place, I think - a bounded txop,
> mild extra priority.

	For 11ac, as far as I can tell the txop is bounded, but larger than the AC_BE txop, no?

> For bigbuckbunny & netflix, though, no so much,
> and of course, if everybody marked packets CS4 or CS5 nobody would
> win.

	That reminds me of my old idea of having your AP monitor the distribution of the different ACs and adjust its own AC to guarantee some reasonable airtime access (I came to this observatiun when I saw my macbook in RRUL tests completely pummel the AP's tx rate).

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

	+1, latency over bandwidth. Except the wifi MACs impressively large preamble setting a lower bound on reasonable txop length (for bulk flows). But I might misremember things a bit, this is my hobby, not my profession.

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

	Ah, come on, you are not going full mental with CS6/7 ans AC_VO ;). This just demonstrates that in a shared ressource system like wifi the whole WMM abstraction is not a good match to reality, no?


> 
> On Sat, Aug 24, 2019 at 2:59 PM Sebastian Moeller <moeller0@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?

	Yes, I just need to actually go put it next to the bed and read it instead of light browsing of the web.

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

	+1, the fact that David requested RFC 3168 ECN instead of classic ECN made me smile, btw. am i the only on remembering the "new coke" vs. "classic coke" marketing kerfuffle?

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

	Can we somewhere note this new terminology as reference? I had the impression the draft did argue against a hypothetical straw-man fq_codel and it would be great to have a likk to paste foe a veridical summary of the rfc-compliant fq_codel.

Best Regards
	Sebastian

> 
> 
>>>>> 
>>>>> 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
>> 
>> _______________________________________________
>> Ecn-sane mailing list
>> Ecn-sane@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

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

[Dave Taht]

Sebastian Moeller <moeller0@gmx.de> writes:

> Hi Dave,
>
>
>> On Aug 25, 2019, at 01:32, Dave Taht <dave.taht@gmail.com> wrote:
>> 
>> 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.
>
> 	Oops, sorry I included bloat without much thinking, never a good idea.

Well, I don't know. Somehow we do need to be getting out of the echo
chambers, and into forums where we can make a difference, in general.

And ya know, on a sunday or a weekend, sometimes just having a
conversation helps.... :)

I'd like it if the gaming industry as a whole woke up to fq and
bufferbloat solutions (instead of just their users), and the whole cloud
based industries attempting to outsource all computation to the cloud
also get on board in educating their users as to how much better their
services would be if their customers had better networks in the first
place.

We are still after all this time, mostly just a bunch of enthusiastic
end-users, waiting for more ISPs/chipmakers/gaming/cloud companies
to pay attention. We've made a big dent in all kinds of stuff both on
the edge and in the cloud - but it's not something anyone notices
because "it just works".

On my bad days I'm thinking that fq_codel defaulting on everything is
the only thing keeping the containers of the world from melting down the
Net but it's still a mystery to me what the cloud networks are doing to
manage their bandwidth in the first place.

Recently I went and did benchmarks of every coffeeshop in town and
thought (still think) it might make a good (if depressing) blog entry or
paper, but I don't have a lot of incentive to finish the work. Actually
I'd rather like it if everybody here "got out" once in a while and did a
few flent tests - and jumped over the counter to help the coffeeshop
make better wifi. The coffee/wifi culture was really key in spreading
the technology, and came with a double latte and some actual physical
socialization. I long ago "jumped the counter" at a few of my favorite
places in town to help fix things.

And I'm frequently sad that membership of the lists is stagnant and most
of the visible conversation (since google seemingly has stopped indexing
mailing lists) takes place on websites like reddit.

If we had a budget (and a salable product, instead of something
great we're trying to give away) I'd have an army giving presentations
all over the world at all kinds of conferences - cable-tek, wisp, e3,
etc.

Ranting here or on my blog doesn't seem to help much, and my enthusiasm
for that sort of outreach is at an all time low, personally. 

>
>> 
>> Certainly it's helpful to co-ordinate a good open discussion here and
>> official responses, there.
>
> 	I fully concur, especially since I often misunderstand things
> intially, so having a friendly venue where I can query calmer mor
> experienced heads is certainly a good idea.

Your "I'm only an egg" approach is often productive.

>
>> 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? -
>
> 	Goos question, probably not much.

Well, perhaps I'll try to publish a policy. I come from an era (netnews)
where crossposting was a useful technique often, but most people's
mailers no longer filter out multiple copies of a given post anymore.

I have been fiddling with chat software for websites a bit. I think we'd
have more engagement if we had that again. Presently the winner is
"commento".

>> 
>> btw: there's 440+ people (or bots?) on bloat and 50 or so on
>> ecn-sane)
>
> 	Funny, I came for the de-bloat and stayed for the ECN ;)
>
>
>> 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?
>
> 	I wonder whether the L4S issue is not actually relevant to the bloat crowd? It certainly comes with sufficient drama ;)

It used to be "we were all in this bloat together", with participants
across the entire industry, and sometimes, to cheer myself up, I look at
the quality and enthusiasm of the early days of the bloat list in the
archives. The three week codel/fq_codel effort was a high. Seeing BQL
work, was a high. Getting dslreports' bufferbloat stuff working was a
high. Finally fixing wifi was a massive high.

Incremental improvements since, are still worthwhile, but staying focused
- and in the case of wifi, maintaining a lab - is currently impossible.

There are so many other things we could tackle in this world - better
tcps, videoconferencing, improvements to all sorts of other devices
(like the raspi 4, or ethernet over powerline)  - and so on.

I still have a long term goal of building a "jamophone" (
https://www.internetsociety.org/wp-content/uploads/2013/09/28_towards_imperceptible_latency.pdf
) - while in part my involvement in the bufferbloat effort came from my
network wifi breaking in heavy rain while I lived in Nicaragua and then
discovering via jim gettys it was a worldwide and growing worse problem
- the other was that long held desire to one day be able to plug my
piano into the wall and play with a drummer across town.

We're actually at that point on a real fiber network, but gpon too has
latency and jitter issues. Worse, linux itself can no longer run ardour
particularly reliably... so I've reverted to a mac.

Everybody else here has different motivations - the number of people
that have told me sqm/ sch_cake "saved their marriage" recently cracked
10.

I'd like to find something fun AND profitable to do with what remains
of my life and I don't know what that is. 

>> 
>> 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. :)
>
> 	I wish I would find to read a book anytime soon. (My reading
> list consists out of Mark Twain's autobiography and the Beastie Boys
> Book, none of which is terribly compatible with my current bus
> commute, nor space related...)

Thx for sharing. I liked his "Captain Stormbreaker's visit to heaven" all
those years ago... and we've used a twain analogy of coaxing individuals
to help paint just a bit of this fence, all along.

A critical biography of twain, perhaps, would go into detail on his
fight to alter copyright law to be able to benefit his heirs - and he
succeeded but his original intent was not to benefit the assigns....

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

Seriously. Imagining a BRAND NEW internet network in space is way more
fun than trying to fix wifi or docsis.


>> ...
>> 
>> 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.
>
> 	As we say at home, "even a blind chicken occasionally finds a
> grain". It took some dedication to actually read through the draft,
> albeit in all fairness compared to he other L$S drafts this was
> refreshingly brief and concise.
>
>> 
>> It's looking potentially like much less a problem on 802.11ax gear...
>> once it ships on both clients and aps.
>
> 	The grass is always greener in the future (modulo the effects
> of global warming). No excuse for detoriating the life for 11n and
> 11ac users...

It's still very unclear how much these things can be adopted in low
power systems. I figure apple and chromebooks will lead the way in
support as they did in the first place... but most of the chipsets
for android seem quite lame on the wifi dept.

>
>> 
>> The VI class (CS4 or CS5) however, is seemingly a good place to stick
>> some intended L4S-ish flows -
>
> 	with emphasis on "some", the L4S idea of treating all flows to
> the same low-latency treatment makes an L4S dscp completely
> incompatible with anything except AC_B in my book. Unless I
> misunderstand the scoope of NQB, if this marking excludes bulk flows
> things _might_ be acceptable.

I don't think

>
>> at least from an IPTV or interactive
>> video (VR) perspective it's a decent place, I think - a bounded txop,
>> mild extra priority.
>
> 	For 11ac, as far as I can tell the txop is bounded, but larger than the AC_BE txop, no?
>
>> For bigbuckbunny & netflix, though, no so much,
>> and of course, if everybody marked packets CS4 or CS5 nobody would
>> win.
>
> 	That reminds me of my old idea of having your AP monitor the
> distribution of the different ACs and adjust its own AC to guarantee
> some reasonable airtime access (I came to this observatiun when I saw
> my macbook in RRUL tests completely pummel the AP's tx rate).
>
>> (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)
>
> 	+1, latency over bandwidth. Except the wifi MACs impressively
> large preamble setting a lower bound on reasonable txop length (for
> bulk flows). But I might misremember things a bit, this is my hobby,
> not my profession.

My experiments with modifying the txop size as a function of load were
quite promising - even cutting the max txop size from 5.3ms to 4ms,
generally, was promising. With shorter txops, interactivity improves,
retransmits due to interference decline - things get better. Rationing
the clients in the beacon helped also.

sadly - last year I shut down the lab and sold off/gave away most of the
gear and haven't had a peep of interest in wifi stuff from any
manufacturer since. 

>
>> 
>> 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)
>
> 	Ah, come on, you are not going full mental with CS6/7 ans
> AC_VO ;). This just demonstrates that in a shared ressource system
> like wifi the whole WMM abstraction is not a good match to reality,
> no?

Yep. (well, the VI queue can aggregate, so it's a better choice for
the limited but more than one packet characteristics of mosh and ssh)

In general I think 802.11n APs should be BE only, but accept clients
attempting to use 802.11e, still. AC - was and remains terribly buggy.
Most of my hope for ax comes from having had a bit of influence over it,
and praying that manufactures expose a per station queue - which none
have done yet.

Also extremely promising in ax gear is the DU concept - but clients need
to come along to use it. It seems possible that OFDMA may make wifi
scale much better than it has before - vastly superior to 5G - 

I have some benchmarks from battlemesh showing how badly 802.11e behaves
when you flood the four hardware queues. I really need to write that up...

>
>> 
>> On Sat, Aug 24, 2019 at 2:59 PM Sebastian Moeller <moeller0@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?
>
> 	Yes, I just need to actually go put it next to the bed and read it instead of light browsing of the web.
>
>> 
>>> 
>>> 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)
>> 
>> 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.
>
> 	+1, the fact that David requested RFC 3168 ECN instead of
> classic ECN made me smile, btw. am i the only on remembering the "new
> coke" vs. "classic coke" marketing kerfuffle?
>
>> 
>> I plan to adopt this clearer terminology instead of what I'd been using.
>
> 	Can we somewhere note this new terminology as reference? I had
> the impression the draft did argue against a hypothetical straw-man
> fq_codel and it would be great to have a likk to paste foe a veridical
> summary of the rfc-compliant fq_codel.
>
> Best Regards
> 	Sebastian
>
>> 
>> 
>>>>>> 
>>>>>> 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
>>> 
>>> _______________________________________________
>>> Ecn-sane mailing list
>>> Ecn-sane@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