[Ecn-sane] straw men

[Dave Taht <dave.taht@gmail.com>]

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