[Bloat] data/control plane

[Dave Taht]

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 <dave.taht at gmail.com> 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