Enabling Internet-Wide Deployment of Explicit Congestion Notification
- 1.5k Downloads
Explicit Congestion Notification (ECN) is an TCP/IP extension to signal network congestion without packet loss, which has barely seen deployment though it was standardized and implemented more than a decade ago. On-going activities in research and standardization aim to make the usage of ECN more beneficial. This measurement study provides an update on deployment status and newly assesses the marginal risk of enabling ECN negotiation by default on client end-systems. Additionally, we dig deeper into causes of connectivity and negotiation issues linked to ECN. We find that about five websites per thousand suffer additional connection setup latency when fallback per RFC 3168 is correctly implemented; we provide a patch for Linux to properly perform this fallback. Moreover, we detect and explore a number of cases in which ECN brokenness is clearly path-dependent, i.e. on middleboxes beyond the access or content provider network. Further analysis of these cases can guide their elimination, further reducing the risk of enabling ECN by default.
KeywordsExplicit Congestion Notification (ECN) Middleboxes Marginal Risk Connection Setup Latency IPv6 Hosts
This work was materially supported by the European Commission though the Seventh Framework Grant Agreements mPlane (FP7-318627) and Reducing Internet Transport Latency (RITE) (FP7-317700); no endorsement of the work by the Commission is implied. Thanks to Stephan Neuhaus for his guidance during the development of ECN Spider, to Daniel Borkmann and Florian Westphal for discussions on Linux kernel modifications for RFC 3168 Fallback, and to Stuart Cheshire for his feedback.
- 1.Ramakrishnan, K., Floyd, S., Black, D.: The Addition of Explicit Congestion Notification (ECN) to IP. RFC 3168, IETF (2001)Google Scholar
- 2.Kühlewind, M., Neuner, S., Trammell, B.: On the state of ECN and TCP options in the internet. In: Proceedings of the Passive and Active Measurement 2013, Hong Kong SAR, China (2013)Google Scholar
- 3.Baker, F., Fairhurst, G.: IETF Recommendations Regarding Active Queue Management: draft-ietf-aqm-recommendation-08. Internet-draft, IETF (2014) (Work in Progress)Google Scholar
- 4.Kühlewind, M., Wagner, D.P., Espinosa, J.M.R., Briscoe, B.: Using data center TCP (DCTCP) in the internet. In: Proceedings of the third IEEE Globecom Workshop on Telecommunication Standards: From Research to Standards (2014)Google Scholar
- 5.Bauer, S., Beverly, R., Berger, A.: Measuring the state of ECN readiness in servers, clients, and routers. In: Proceedings of the Internet Measurement Conference, pp. 171–177 (2011)Google Scholar
- 6.Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., Handley, M., Tokuda, H.: Is it still possible to extend TCP? In: Proceedings of the Internet Measurement Conference, pp. 181–194 (2011)Google Scholar
- 9.Craven, R., Beverly, R., Allman, M.: Middlebox-cooperative TCP for a non end-to-end Internet. In: Proceedings of ACM SIGCOMM 2014 Conference, Chicago, IL, USA (2014)Google Scholar
- 10.Trammell, B., Gugelmann, D., Brownlee, N.: Inline data integrity signals for passive measurement. In: Proceedings of the Sixth International Wksp on Traffic Measurement and Analysis, London, England (2014)Google Scholar
- 11.Detal, G., Hesmans, B., Bonaventure, O., Vanaubel, Y., Donnet, B.: Revealing middlebox interference with Tracebox. In: Proceedings of the 2013 Internet Measurement Conference IMC ’13, pp. 1–8, Barcelona, Spain (2013)Google Scholar