Is it still possible to extend TCP?

  • Authors:

  • Michio Honda;Yoshifumi Nishida;Costin Raiciu;Adam Greenhalgh;Mark Handley;Hideyuki Tokuda

  • Affiliations:

  • Keio University, Fujisawa, Kanagawa, Japan;Keio University, Fujisawa, Kanagawa, Japan;Universitatea Politehnica Bucuresti, Bucharest, Romania;University College London, London, United Kingdom;University College London, London, United Kingdom;Keio University, Fujisawa, Kanagawa, Japan

  • Venue:
  • Proceedings of the 2011 ACM SIGCOMM conference on Internet measurement conference
  • Year:
  • 2011

Quantified Score

Hi-index 0.02

Visualization

Abstract

We've known for a while that the Internet has ossified as a result of the race to optimize existing applications or enhance security. NATs, performance-enhancing-proxies,firewalls and traffic normalizers are only a few of the middleboxes that are deployed in the network and look beyond the IP header to do their job. IP itself can't be extended because "IP options are not an option". Is the same true for TCP? In this paper we develop a measurement methodology for evaluating middlebox behavior relating to TCP extensions and present the results of measurements conducted from multiple vantage points. The short answer is that we can still extend TCP, but extensions' design is very constrained as it needs to take into account prevalent middlebox behaviors. For instance, absolute sequence numbers cannot be embedded in options, as middleboxes can rewrite ISN and preserve undefined options. Sequence numbering also must be consistent for a TCP connection, because many middleboxes only allow through contiguous flows. We used these findings to analyze three proposed extensions to TCP. We find that MPTCP is likely to work correctly in the Internet or fallback to regular TCP. TcpCrypt seems ready to be deployed, however it is fragile if resegmentation does happen---for instance with hardware offload. Finally, TCP extended options in its current form is not safe to deploy.