Since the 1980s, the Transmission Control Protocol (TCP) has controlled much of the Internet traffic. TCP is one of the cornerstones of Internet communication to this day. With the Request for Comment 9293 (RFC 9293), small changes that have been submitted over the years are summarized for the first time and a minimum requirement for dealing with overload is added.
The RFC specification 793 adopted by the Internet Engineering Task Force (IETF) in 1981 was therefore valid for around forty years. The basic transport protocol for the Internet regulates communication between a server and a client who want to exchange IP packets as quickly as possible using error correction, but have no concrete information about how fast the route they are communicating over is.
All in all, the TCP specification is about opening and closing a connection and ensuring complete transmission of the data packets, or about the method by which the sender and receiver detect and correct transmission errors. Unlike the underlying IP layer and its counterpart UDP (User Datagram Protocol), TCP is a “stateful” protocol, which means that the two servers involved know about the status of the connection.
Consolidation and new language
Basically, the good old TCP, as described by Internet father Jon Postel in the 1980s, has changed little. Essentially, the new version is a “merging of various documents that have accumulated since RFC 793,” explains Professor Michael Scharf of Esslingen University. Scharf served as a co-chair of the IETF’s TCP Maintenance and Minor Extensions Working Group (TCPM) from 2011 to March 2022.
The documents that have now been integrated include, for example, the 1989 definition of an algorithm for calculating the period after which the sender should resend a packet that has not been acknowledged by the recipient (RFC 1122). The most recent integrated RFC dates from 2012 and is ultimately just a clarification of the maximum size of TCP segments. RFC 9293 brings all of these things together, Scharf explained. “Anyone who wants to develop a new TCP implementation will find everything they need here.”Many of the integrated RFCs are therefore obsolete and become “historical texts”.
The renovators probably also classified Postel’s description of the “philosophy of the TCP” and also the reference to the original client, the US Department of Defense, as historical. On the other hand, the new “Security Considerations” section, which was not yet considered in Postel’s day, deals with possible attacks and vulnerabilities as well as the security mechanisms sometimes offered for them, such as TCPCrypt, which is not very common.
Innovation congestion control
However, the editorial team around Wesley Eddy, CTO of the software-defined networking company MTI Systems, made an exception. For the first time, the TCP standard specifies minimum requirements for TCP congestion control.
However, the choice of congestion control algorithms is still left to the implementers and thus remains flexible, as Scharf emphasizes. This is necessary because in the area of congestion control, newer ones such as Google’s BBR are available in addition to the currently frequently used Reno and Cubic. The next generation is already in the works.
However, the new TCP standard document specifies the minimum requirements that congestion control must follow in order to avoid overload.
TCP vs Quic
There is movement in the standardization process not only in congestion control. With Quic, there has long been a TCP competitor that some observers believe has a good chance of outstripping the older transport protocol. Quic originally brought Google into the standardization; it is based on UDP and brings encryption with it.
Despite the initial surge in Quic traffic, Scharf sees several areas where TCP will continue to play its role as the base protocol. Appropriate server software is still missing for the time being for smaller internet providers. So far, neither Apache nor NGINX are designed for Quic, so many websites are accessed without the new protocol. In addition, TCP remains the protocol of choice for the exchange of routing information, i.e. for BGP traffic.
And while part of Quic’s speed advantage is due to the fact that the engineers have intertwined several protocol layers, TCP still attracts with its conventional concept and more easily understandable functionality because it only maps one communication layer. For some developers faced with a choice, this may be the deciding factor in favor of TCP because it promises faster implementation and easier error analysis.
Heterogeneous infrastructure
However, Scharf expects that some of the innovations that Quic has brought will also be considered for TCP. “For RFC 9293, it was decided to stay as close as possible to the text of RFC 793 in terms of the functionality of the protocol.” This is also due to the enormous number of implementations. The closer RFC 9293 stays to the original wording, the less likely it is that there will be errors due to different interpretations in future implementations. For the future, however, he certainly sees the opportunity to teach the good old TCP in Quic tried and tested functions.
