If you’ve followed the MAMI project over the past three years, you know that we are big fans of Explicit Congestion Notification (ECN). First, it provides an illustrative case study of the deployment of an optional transport protocol feature: standardized in 2001, deployment lagged for a decade due to reports of its signaling crashing certain routers, and rolled out slowly on the server side due to defaults in the Linux kernel, until deployment accelerated due to client-side defaults in Mac OS X. Second, manipulation of ECN is indicative of other TCP and IP manipulations, especially of DSCP.
Let’s have a look at the evolution of ECN support and problems with ECN in the MAMI Path Transparency Observatory front-end. The front page shows a matrix, from which we can see that we have ECN measurements back to 2014 (including measurements taken before the project, and before the development of PATHspider):
The charts page for ECN has charts for raw observations of ECN-dependent connectivity failure (
ecn.connectivity conditions), as well as charts of ECN negotiation. Let’s look at connectivity first:
The top chart shows the proportion of observations we have of each
condition, and the bottom chart shows the absolute number of
measurements. Green (
ecn.connectivity.works) is good: indeed, attempting to ECN does not often cause problems with connectivity1.
By clicking on the conditions above the chart, we can disable the
display of certain states; by doing this for all conditions except
ecn.connectivity.broken (i.e., attempts to negotiate ECN cause connectivity failure), we can see the following clear downward trend:
Clicking on one of these bars brings up a detail view of the observations from which it is derived (If the observation query for that bar has not already been cached, you may have to wait). To learn more about each target, clicking on the IP address will pull up the RIPEstat page for that address.
For many measurements, we have data taken from multiple vantage
points toward the same targets, in order to attempt to find “on-path”
(as opposed to “near-server”) interference with ECN; these are
Here we see another unsurprising up-and-to-the-right trend: due in
large part to the dominance of Linux web servers and reasonable
practices on upgrading them, of about 800000 measurements we took from
three vantage points (in Toronto, Amsterdam, and Singapore) this week,
more than 86% support ECN negotiation. By zooming in on on
ecn.multipoint.negotiation.path_dependent conditions, we can see that there are still a few servers accessible via paths with TCP header manipulation deployed:
We invite you to explore the PTO. To learn more about the PTO itself, have a look at our Deliverable 1.2, which details its design. All of the software behind the PTO is available open source: the core PTO server and tools for running normalization and analysis are in the pto3-go repository, and the web front-end in pto3-web. Normalizers and analyzers for ECN are in pto3-ecn.
1: The grey in the low-volume measurement during the week of 14 January represents a large number of “offline” measurements, where a site was not reachable with or without ECN; this represents a transient connectivity We can click on the