One of the primary goals of MAMI’s measurement work is to quantify path transparency in the Internet: how likely a given transport protocol or feature is to work on which paths, and how these features break. Earlier work by MAMI partners ETH and the University of Aberdeen on this topic focused on Explicit Congestion Notification (ECN) in TCP, a feature that allows congestion to be detected without packet loss. Our paper, based on measurements in August and September 2014 and published at PAM 2015, found that 56% of IPv4 and 65% of IPv6 hosts serving the Alexa top million websites would negotiate ECN if the client requested it, which at the time was not the default in any major client operating system. ECN negotiation attempts could lead to connectivity issues and fallback to non-ECN usage for 0.42% of IPv4 and 0.05% of IPv6 servers in the top million.
In the meantime, Apple has added ECN negotiation by default on the client side in developer previews of Mac OS X and iOS, and our patch adding fallback in the case of ECN failure to non-ECN usage, as specified in RFC 3168, has been added to the Linux kernel. The tooling for the 2015 paper is evolving into a generic path impairment measurement tool called PathSpider. So what’s the state of the Alexa top million today?
We recently ran a measurement from a single vantage point, a DigitalOcean server in Amsterdam, to the set of unique IPv4 and IPv6 addresses serving the top million websites, and found that 432544 of 617873 (70.005%) of IPv4 addresses and 20262 of 24472 (82.797%) IPv6 addresses will negotiate ECN. This continues a trend ETH started observing in 2013, shown here.
The proportion of servers requiring fallback has not changed appreciably: 0.44% of IPv4 and 0.11% of IPv6 servers. This reflects the two different forces at work: ECN support on the server side generally follows the operating system defaults, and web hosting machines generally run a recent Linux, the first operating system with server side ECN on by default. Connectivity problems, however, are often a function of faulty middleboxes, which are more slowly replaced, or firewall rules explicitly disabling ECN traffic for dubious reasons.
Detailed analysis behind this blog post is available here; the raw data it runs on will be made available shortly.