Re: [Bloat] [Ecn-sane] non queue building flows ietf draft review.
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 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 <4b...@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
Re: [Bloat] [Ecn-sane] non queue building flows ietf draft review.
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 <4b...@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 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 rgri...@freebsd.org ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] [Ecn-sane] non queue building flows ietf draft review.
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 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-s...@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/ecn-sane ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
[Bloat] non queue building flows ietf draft review.
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! ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] buffer sizing meeting notes
On Sat, Aug 24, 2019 at 9:59 AM Sebastian Moeller wrote: > Another nugget from the notes ( > http://yuba.stanford.edu/~bspang/buffer-sizing-meeting/notes/): > > This looks like an argument for fq_codel/cake's use of time instead of > queue length, OR an argument for fq, because in a non-overwhelmed fq_system > the local bucket's queue length should be somewhat stronger correlated with > the sojurn times, than the sojurn time of a packet though a shared queue, > no? > I believe that using fq there are good implications in terms of buffer sizing rules. The focus is only on backlogged flows. The sparse flow queue can be sized purely based on queue load. Which is trivial queuing theory formulas with non-TCP traffic. For backlogged flows, sizing is just like sizing a buffer for a single TCP flow. So the computation can be done based on estimations of the number of backlogged flows and by setting the cut-off BDP based on the largest (maximum) min RTT one want to serve optimally. So AQM is really needed to get optimality. The number of backlogged flows could be estimated as a max value or an avg value, and this of course changes depending on the network segment (DC, residential, campus, access, backhaul etc.). Nick McKeown has done quite a lot of research on the topic (reported in the slide deck), so I find hilarious the following in his slide deck "Personal confession: I have no idea what the general answer is" about sizing buffers! ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] buffer sizing meeting notes
Another nugget from the notes (http://yuba.stanford.edu/~bspang/buffer-sizing-meeting/notes/): Chuanxiong Guo, Bytedance Talked about buffering in Bytedance’s datacenters. The top of rack switches have buffers of 12-32MB, and the aggregation switches have larger buffers of several GB. Were hoping to use ECN to reduce buffers for aggregation switches, but argued that precise ECN marking on egress queue length in VoQs is hard. However, Arista and Barefoot said they’ve fixed this using the packet latency instead of queue length for ECN. This looks like an argument for fq_codel/cake's use of time instead of queue length, OR an argument for fq, because in a non-overwhelmed fq_system the local bucket's queue length should be somewhat stronger correlated with the sojurn times, than the sojurn time of a packet though a shared queue, no? Best Regards Sebastian > On Aug 24, 2019, at 09:54, Jesper Dangaard Brouer wrote: > > On Fri, 23 Aug 2019 10:13:39 -0700 > Simon Barber wrote: > >>> On Aug 23, 2019, at 9:07 AM, Dave Taht wrote: >>> >>> There's some good preso from various representatives in the dc market here. >>> >>> The p4 stuff, in particular (from barefoot) is looking impressive. >>> >>> http://yuba.stanford.edu/~bspang/buffer-sizing-meeting/ > > I followed the link to the animation of AIMD (Additive > Increase/Multiplicative Decrease), that was really cool! > > https://dabh.github.io/network_animations/ > > -- > Best regards, > Jesper Dangaard Brouer > MSc.CS, Principal Kernel Engineer at Red Hat > LinkedIn: http://www.linkedin.com/in/brouer > ___ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] buffer sizing meeting notes
On Fri, 23 Aug 2019 10:13:39 -0700 Simon Barber wrote: > > On Aug 23, 2019, at 9:07 AM, Dave Taht wrote: > > > > There's some good preso from various representatives in the dc market here. > > > > The p4 stuff, in particular (from barefoot) is looking impressive. > > > > http://yuba.stanford.edu/~bspang/buffer-sizing-meeting/ I followed the link to the animation of AIMD (Additive Increase/Multiplicative Decrease), that was really cool! https://dabh.github.io/network_animations/ -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
