TCP is an extensible protocol. Since the publication of RFC793, various TCP extensions have been proposed, specified and eventually deployed. When looking at the deployment of TCP extensions, one needs to distinguish between the extensions that provide benefits once implemented on senders and receivers and the implementations that need to be supported by both client and servers to be actually used.

These two types of extensions are deployed are very different rates. Examples of extensions that only require changes on a single host include Fast retransmit, various forms of TCP congestion control or increasing TCP’s initial window. This last extension was first proposed in 2010 and has been later adopted by the IETF in RFC6928.

Recent measurements indicate that it is used by large CDN providers as shown by the following screenshot extracted from https://www.cdnplanet.com/blog/initcwnd-settings-major-cdn-providers/ based on https://www.cdnplanet.com/tools/initcwndcheck/

- source : https://www.cdnplanet.com/blog/initcwnd-settings-major-cdn-providers/

Deploying TCP extensions that use TCP options that need to be negotiated during the three-way handshake is a different story. There is often a chicken-and-egg problem that needs to be solved before those extensions get deployed. Developpers of client stacks don’t want to deploy them until servers support them and the same applies for servers. A recent discussion on the tcpm mailing list mentioned that inclusion of the extension in the Linux kernel is one of the main factors driving adoption and deployment. This is one of the factors, but clearly not the only one. Several measurement papers have shown that it takes years to deploy a TCP extension that uses new TCP options.

A first example are TCP’s Selective Acknowledgement options. This extension was specified in RFC2018 in 1996. It clearly improves the performance of TCP when there are packet losses. Despite of its benefits, it took more than a decade to be widely deployed. In An Analysis of Longitudinal TCP Passive Measurements, Kensuke Fukuda analyses packet traces over a decade and shows in figure 7 the fraction of TCP connections that successfully negotiated SACK. The deployment of the Timestamp and Window Scale options defined in RFC1323 in 1992 was even slower.

- source : An Analysis of Longitudinal TCP Passive Measurements

Another recent example is the TCP Fast Open Extension. With this extension, clients and servers can send data inside the SYN and SYN+ACK packets to speed up the exchange of data on short TCP connections. TFO was initially proposed in 2011 in draft-cheng-tcpm-fastopen-00 . Client-side support was added in Linux kernel 3.6 and server-support was added in Linux 3.7. A good article on this TFO implementation was published on lwn.net. Given the benefits of TFO for web applications and the client support announced by Apple and Microsoft, one could expect that TFO would be widely deployed. Unfortunately, this is not yet the case. In Tracking transport-layer evolution with PATHspider, Brian Trammel and his colleagues study the deployment of TFO by using pathspider. Their measurements show that TFO is only deployed by a minority of web servers and most of the servers that support TFO are inside Google’s AS. Despite the support of TFO on Linux since 3.7 and by Linux, Apple and Microsoft clients, this extension is still not widely deployed

- source : Tracking transport-layer evolution with PATHspider