Greetings, all, We'll be publishing an active measurement study on ECN negotiability and connectivity risk at PAM 2015, just before the IETF; the author copy of the paper is at
http://ecn.ethz.ch/ecn-pam15.pdf. The key findings are: (1) More than half of the Alexa top million web servers (600k accounting for duplicate IPs) will happily negotiate and mark ECT0 if you ask nicely (at least as of September 2014). This mainly reflects people upgrading Linux servers to kernels where tcp_ecn=2 is the default, and strongly validates changing default configurations as a method for increasing ECN deployment. (2) 0.42% of these webservers will fail to connect if you try to negotiate ECN, but simple ECN fallback as in RFC 3168 (retransmitted SYN ECE CWR sent as SYN) commutes this to a risk of slightly increased handshake latency. (3) A vanishingly small number (15 / ~600k) of these have *different* ECN connectivity dependency depending on where you connect from, indicating that the box breaking ECN is not directly adjacent to the server. A third of these (6) are GoDaddy parking sites. (4) There is more mangling of the ECN IP header bits than connectivity dependency, and successful negotiation does not always mean successful marking. About 2% of IPv4 servers and 15% (!!!) of IPv6 servers signal in other than expected ways, indicating that negotiated ECN might not be useful. (5) We appear to have seen two (count 'em, two!) CE markings in the wild, both from the same webserver (www.grandlyon.com) when probing 600k IP addresses 3 times from 3 different locations (i.e., 2 out of 5.6 million flows). This is neither encouraging nor surprising. Bottom line, the risk to connectivity of turning ECN on by default in clients is vanishingly low, though not yet in the one in ten million range, when simple fallback as in RFC3168 is implemented. Modern Windows and Mac OS X do this; Linux doesn't yet, though we have a three line patch (which, anecdotally, I've been running without incident on my desktop for the past half year). Given the signaling anomalies, especially on IPv6, defining simple methods to detect and dynamically ignore anomalous signaling at the endpoints is probably the next area of work to getting ECN deployable. There *is* some path dependency of ECN brokenness, but not enough to make it worth it to continue working on the approach in the expired draft-kuehlewind-tcpm-ecn-fallback until we have a solution for the general ECN IP signaling anomalies. I was hoping to get continuous measurements based on a new version of the measurement and analysis scripts up and running before the IETF, but this has fallen to task queue triage. We also have a student working on doing this for things other than the web; all of this is in my queue for mid-May at this point, so watch this space. Cheers, Brian and Mirja _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
