For a while now a control plane/data plane distinction has permeated much of academia. Ostensibly this take on matters made some things simpler.
My take was, to mis-quote jwz's take on regex's: "Now you have two problems". Having the complexity of two "wires" or two busses hurts MTBF, raises costs, introduces desynchronization problems, and so on. To some extent my support of FQ techniques was to find better ways of multiplexing control and data signals along a single bus. More recent additions, such as AQM and classification, further this. If you go looking however, no matter how clean an architecture, there are always "control" packets on a data or control plane. Easy examples are LLC packets in DSL, management frames in wifi, and arp. More complicated ones are spanning tree, ethernet pause frames and the plethora of other schemes the IEEE has been coming up with to at least theoretically deal with congestion. Easy examples as to why these sorts of packets are needed abound - block arp, LLC or spanning tree for a minute and your network fails. Get wifi management frames out of order, and wifi fails. One of the many things I like about pie and codel is that by focusing on latency, they interoperate fairly well with various flow control schemes, but life here remains imperfect. Yet these control packets also are subject to a need for rate control themselves. I keep trying to remember the paper's name that showed that 75% of the wifi packets in a stadium were management frames, in particular. All the ants scurrying about are largely unmanaged and unobserved. What we started to call "ants" - relative to the mice, elephants, and lemmings - in the early stages of the bufferbloat project - are worrying me, more and more. On Wed, Sep 19, 2018 at 8:13 AM Dave Taht <[email protected]> wrote: > > At one level, my hope in starting this project is that once enough > researchers realize that ECN is now ubiquitous in apple's products, > all kinds of new ideas and research will emerge and we won't have to > do any more work. :) > > In my case, though, I rather wanted to promote a skeptical look at the > edge cases. A quick look at things like /etc/services or the long list > of ethertypes > https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml#ieee-802-numbers-1 > is sufficient cause to worry. > > I'm pretty good with short, ringing phrases, and hereby give away most > of these potential paper titles away to whoever wants to use them. > > I'm going to talk to two or three of these in the coming weeks, but to > at least get the list out of my system: > > Where ECN is unfair > When ECN is evil > ECN along the edge > ECN as an attack vector > DCTCP along asymmetric paths > Towards making ecn generally deployable > Fair queuing failures > ack-filtering in practice > ECN has mass! > ecn over wifi > syn/ack limiting as rate control > self congestion as aqm > ecn on alternative protocols > sch_cake and blue > ECN should be an earlier congestion signal than loss? > Mosh's reaction to ecn > ECN outbound on residential links > GSO considered harmful > Making tcp go slower makes it faster > Damage from an ecn enabled DDOS > FQ is not enough > ECN on meshy protocols > ECN vs ISIS > > -- > > Dave Täht > CEO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-669-226-2619 -- Dave Täht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619 _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
