Hi,
I just want to bring to your attention the below talk (I am too lazy to re-write the whole email for this slightly different audience).
Takeaway:
We'll see a lot of ECN enabled traffic in a few months. This shouldn't be a problem. I've been doing it to all my machines for 3-5 years without ill effects.
More people will become interested in how TCP works, from application, through the host stack, to the AQM (or lack thereof) in the router etc. If you don't do AQM towards your customers, be prepared that they're going to start complaining in a more informed manner in the not so distant future.
IPv6 only with NAT64+DNS64 will become a lot more feasible going forward. I am not a fan of breaking DNSSEC, but perhaps if we can do the DNS64 in the host (as it seems Apple is doing, at least for IPv4 literals), then that might be possible to work around.
Hi,
I just want to bring to your attention the below talk (I am too lazy to
re-write the whole email for this slightly different audience).
Takeaway:
We'll see a lot of ECN enabled traffic in a few months. This shouldn't be a
problem. I've been doing it to all my machines for 3-5 years without ill
effects.
I recall when ECN first came out and firewalls would block it causing me
issues on my Linux boxes sending list mail out. It was a small enough percentage
that I mostly ignored it, but this will cause trouble for people who still
haven't fixed their broken firewalls.
I encourage almost everyone on nanog to watch this talk.
- Jared
Hi,
I just want to bring to your attention the below talk (I am too lazy to
re-write the whole email for this slightly different audience).
Takeaway:
We'll see a lot of ECN enabled traffic in a few months. This shouldn't be a
problem. I've been doing it to all my machines for 3-5 years without ill
effects.
you'll also find all the networks that use the entire tos field as part
of the hash key... that's not exactly something you notice when you have
a 1:1 host to ip correspondence unless it leads to reordering. but with
stateless load balancing you can. fortunately those networks are
observably rare.
Hi,
I just want to bring to your attention the below talk (I am too lazy to
re-write the whole email for this slightly different audience).
Takeaway:
We'll see a lot of ECN enabled traffic in a few months. This shouldn't be a
problem. I've been doing it to all my machines for 3-5 years without ill
effects.
you'll also find all the networks that use the entire tos field as part
of the hash key... that's not exactly something you notice when you have
a 1:1 host to ip correspondence unless it leads to reordering. but with
stateless load balancing you can. fortunately those networks are
observably rare.
I am aware of one such (very large) network that did, indeed, (and til
recently!) have devices that used the entire tos field in their ECMP
implementation. This led to re-ordering every time ECN "CE" was
exerted on ECN enabled flows. Testing for the existence of this
problem is not terribly hard (example, have a rule that periodically
exerts CE on a bunch of test tcp flows, count the reorders in
TCP_INFO), but the tools for it are kind of adhoc as yet.
I am curious if there is a SNMP mib/cacti/mrtg/other support for
reporting "CE" events in addition to loss?
Although fq_codel and pie (as deployed in linux - sadly docis-pie has
no ECN support in the spec) do do ecn markings (fq_codel *by
default*), deployment on bottleneck links is limited as yet. 
My expectation is that this will make a difference first for apple
streaming video apps in the home, connecting to other devices in the
home (over wifi, ethernet, bluetooth, etc) that will start to make use
of this additional signalling information. And a billion new devices
with ecn on by default will probably expose all the other problems
rather rapidly. 
I recall when ECN first came out and firewalls would block it causing me
issues on my Linux boxes sending list mail out. It was a small enough percentage
that I mostly ignored it, but this will cause trouble for people who still
haven't fixed their broken firewalls.
Better fallbacks exist now.