Dave Taht
2018-09-19 16:45:09 UTC
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.
Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
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.
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
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
--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
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