Do you think a replacement to TCP is important?
Yes, sort of. The first version of TCP was written in 1974 (1). The Internet Protocols were intended to be a communications network for US military operations. The original goal was to connect together the original ARPANET with the ARPA packet radio network, in order to give users on the packet radio network access to the large service machines on the ARPANET. At the time it was assumed that there would be other sorts of networks to interconnect, although the local area network had not yet emerged (2). When the internet began being used by the public and commercial entities, it grew beyond the initial expected scope. In 1995 there were an estimated 16 million users of the Internet. As of June 2019, there are an estimated 4.5 trillion Internet users (3). Prior to 1991, the internet was primarily text based. The most popular user applications were gopher (a search engine for organized files), email, IRC (Internet Relay Chat) and Usenet news (the Reddit of yesteryear in text based format). In August of 1991, the first website went online. Today there is 1.7 billion websites on the Internet (4). The World Wide Web has changed the nature of Internet traffic, which now includes images, streaming movies and audio. This traffic and the number of users has increased the amount of bandwidth that is used. While TCP was suitable for network operations for many years, it has become somewhat of a hindrance today. Let’s start with the TCP “three-way handshake”. “The TCP handshaking mechanism is designed so that two computers attempting to communicate can negotiate the parameters of the network TCP socket connection before transmitting data such as SSH and HTTP web browser requests” (5). This is the communication that has to take place for each TCP connection:
Host A sends a TCP SYNchronize packet to Host BHost B receives A’s SYN
Host B sends a SYNchronize-ACKnowledgement
Host A receives B’s SYN-ACK
Host A sends ACKnowledge
Host B receives ACK.
TCP socket connection is ESTABLISHED.
Since the client must wait for the server to send its connection response, this procedure incurs some built in latency. Once the connection is established, instead of having to wait for each packet to be acknowledged, TCP allows the sender to send out new segments even though it may not have received acknowledgements for previous segments.
To prevent the sender from overflowing the receiver’s buffers, in each segment the receiver tells the sender how much data it is prepared to accept without acknowledgments (6). In TCP, this is referred to as “Slow Start”. It restricts how much data may be initially transmitted over a connection, then increases that capacity methodically (7). When a connection first starts up, each sender is only allowed to have a single unacknowledged segment in transit. Every time a segment is acknowledged without loss, the congestion window is opened; every time a segment is lost and times out, the window is closed. For short lived TCP connections such as HTTP this also creates unnecessary latency.
On many networks the maximum transfer unit (MTU) is 1500 bytes. The TCP header is 20 bytes. This leaves about 1480 bytes for a packet payload. A 1 GB file is 1 Billion bytes. That comes out to 675,675 packets which translates to 13,513,500 bytes (108 MB) of header data; and that doesn’t take into account acknowledgment packets. Simply put, in a world of streaming movies and music, and households with multiple devices on the Internet (including tablets, smart phones, TV’s, appliances, etc), TCP adds a good amount of latency and bandwidth.
Do you think the adoption of a TCP replacement will be as slow as the transition from IPv4 to IPv6?
I don’t think TCP will be completely phased out for many years. I think that it will happen slowly over time on an application by application basis. Two interesting protocol replacements for TCP are RUDP (reliable UDP) and QUIC, a protocol that was developed by Google.
“Reliable User Datagram Protocol (RUDP) is a transport layer protocol designed at Bell Labs for the Plan 9 operating system. It aims to provide a solution where UDP is too primitive because guaranteed-order packet delivery is desirable, but TCP adds too much complexity/overhead. In order for RUDP to gain higher quality of service, RUDP implements features that are similar to TCP with less overhead (8)”. While both Cisco and Microsoft have released RUDP versions for specific tasks, because of the “task-specific” nature of RUDP implementations, RUDP hasn’t become a formal standard. Thus far it has never progressed beyond “draft” status (9).
Another hopeful protocol that seems to be getting more traction is the QUIC (pronounced ‘quick’) protocol from Google. It was initially designed by Jim Roskind in 2012, and has been added into the Chrome browser. QUIC is used by more than half of all connections from the Chrome web browser to Google’s servers (10). It’s also been announced that HTTP version 3 will replace TCP with QUIC (11), and there is currently work being done to implement QUIC directly into the Linux kernel. This is big news, since much of the current TCP traffic is going over HTTP/HTTPS. While this is promising, it will take lots of time to rewrite all application code to take advantage of QUIC. Denis Bider wrote:
“Standardizing new SSH transport and connection layers cannot be done properly by one person. It requires multiple years, and the amount of tedium that needs to be performed is huge. Even if others were interested, I wasn’t sure I was willing. Subsequently, I did RFC 8308 and RFC 8332 – comparatively small things, with the help of the awesome group at Curdle. The process for those was decidedly painful. A new SSH protocol is 5x or 10x the amount of work.
It does not seem easy to fit into an existing SSH implementation. For users, it may seem like a drop-in replacement, but at an implementation level, many things change. It would take years to iron out new issues that arise (12)”.
This means that it would be easier to just re-write a login protocol than to update the existing ssh, just as it was easier to write ssh than build encryption into telnet in the 1990’s. My best guess is that in some cases applications will be replaced with new implementations, and in other cases we’ll live with “legacy applications” on TCP. Hopefully newer projects will target the QUIC protocol over TCP.
Much like how Python became more popular than Perl as a development platform, QUIC needs a strong self-promoting community to gain support. I think this could happen quickly by introducing good QUIC libraries into existing development language installs. I’ve found some early work to implement QUIC in Python (https://github.com/ZhukovAlexander/quic-py) , Java (https://github.com/hrqiang/quic-java) and C++ (https://github.com/devsisters/libquic), but they are not included as part of the standard libraries that come with the languages.
Citations:
(1) “Specification Of Internet transmission Control Program”, Vinton Cerf, Yogen Dalal, Carl Sunshine, December 1974, RFC 675 , https://tools.ietf.org/html/rfc675
(2) Clark, D. 1988. “The Design Philosophy of the DARPA Internet Protocols.” ACM SIGCOMM Computer Communication Review 18 (4): 106–114. doi:10.1145/52325.52336.
(3) “Internet Growth Statistics”, Miniwatts Marketing Group, September 26, 2019, https://www.internetworldstats.com/emarketing.htm
(4) Internet Live Stats, Internetlivestats.com, updated live, https://www.internetlivestats.com/total-number-of-websites/
(5) “TCP 3-Way Handshake (SYN,SYN-ACK,ACK)”, InetDaemon Enterprises, updated May 19, 2018,https://www.inetdaemon.com/tutorials/internet/tcp/3-way_handshake.shtml
(6) “Analysis of HTTP Performance problems”, Simon E Spero, July 1994, https://www.w3.org/Protocols/HTTP/1.0/HTTPPerformance.html
(7) “TCP Slow Start”, Patrick Sexton, May 15th 2016, https://varvy.com/pagespeed/slow-start.html
(8) “Reliable User Datagram Protocol”, Wikipedia Foundation, updated September 21, 2019, https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol
(9) "Reliable UDP (RUDP): The Next Big Streaming Protocol?", Dom Robinson, October 1, 2012, https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=85316
(10) “QUIC”, Wikipedia Foundation, Updated September 29, 2019, https://en.wikipedia.org/wiki/QUIC
(11) "Next Version Of HTTP Will Replace TCP With Google’s QUIC", Anmol Sachdeva - November 13, 2018, https://fossbytes.com/next-version-of-http-will-replace-tcp-with-googles-quic/
(12) "The case for SSH over UDP", Denis Bider, June 13, 2019, https://denisbider.blogspot.com/2019/06/the-case-for-ssh-over-udp.html
