There is no way to 'push a new version of TCP', I believe that's one of the strong motivations for these protocols. Billions of devices and the world's entire network infrastructure would need to be upgraded, you'd only start seeing decent support after a decade. So you have to work with what we have - TCP and UDP.

Given how IPv6 went, a decade seems optimistic.

IPv6 had a really bad case of second system effect, though.

>There is no way to 'push a new version of TCP'

Yes there is.

TCP has a variable options range of up to 320 bits starting at the 20th octet to handle exactly feature extensions (This is exactly how Multi-Path TCP is implemented). There are also 3 reserved bits set for future use (13th octet), which can also form the basis of even larger extended option ranges for stuff like TLS negotiation.

You're describing how it can be upgraded in theory but the parent was explaining that it can't be done in practice.

One of the lessons of the last decade or so has been that only end-to-end encryption prevents ossification. To the extent that middleboxes can read stuff they will break forward compatibility.

For example certificate compression. How are we only sending that to standardisation now in 2020? Well it was impossible to deploy this before TLS 1.3. Why? Because older versions of TLS didn't encrypt certificates, and so middleboxes could read them, and so middleboxes would freak out if the certificate wasn't as expected. That's all it took to make a useful optimisation impossible to deploy.

> You're describing how it can be upgraded in theory but the parent was explaining that it can't be done in practice.

Adding features to TCP was done many times successfully already. When my jurney started there was no ws-scaling, ECN, SACK... They are all widely adopted now.

Ten years after it was standardised, field reports showed ECN at 0.06% of all connections using ECN while almost 40% showed countermeasures preventing ECN or other failures (the remainder did not attempt ECN)

So what did they do? Well they adjusted ECN so that it tolerates the broken middleboxes. That's what you have today. Your systems go "Oh, ECN is broken, oh well" and press on without it. You see this as a feature added "successfully" and I call it what it is: Failure.

Where you're talking about TCP, then the only state aware devices in the path are usually stateful firewalls close to the beginning and end of the path. I can't see this causing major issues as firewalls don't usually act on options unless specifically configured, seeing that they don't change the fundamentals of TCP flow (ie. flags, seqs and acks). The option but are usually just flags for signalling between the two endpoints.

My apologies for just taking your comment as a jumping-off point, but could you or anyone else point me in the best (free) direction to properly learn about this whole stack of protocols? It's been very high on my list to finally figure out what sits below HTTP, and in a roundabout way my appetite has been whetted by reading a Claude Shannon biography and The Information (which I suppose aren't perhaps /that/ close to UDP and so on but more about information theory and error correction as a historical development), but those books made me really want to dive in and learn about the building blocks of 'the internet'. Any pointers to books, articles or courses would be very much appreciated!

TCP/IP Illustated Volume 1: The Protocols by W. R. Stevens is the classic textbook and a great place to start off. You can then read the IETF RFCs, which are usually well written and completely readable to anybody with a computing background.

awesome, thanks for the recommendation!

the RFCs themselves are pretty accessible -ymmv.

rfc 791 - internet protocol

rfc 793 - transmission control protocol

Hmm I would say TCP does have downsides. The choice between TCP and UDP is all-or-nothing. Quic does some nice modularization/layering so that you can effectively control reliability and ordering separately.

One way to think about it is negotiating a connection vs what that connection actually is are pretty separate. Sadly even the literature and education materials on TCP is pretty poor at explaining this. With the QUIC spec this just feels much clearer.

I would actually say Quic is worse. In addition to mandatory ordering (like TCP) it also provides you mandatory encryption.

You can not really have "flexible ordering" with default Quic, since Quic Streams are inherently ordered Streams. You could treat them as unordered on one end and deliver out-of-order data as soon as at arrives, but that won't allow the peer to send unordered data due to an overall limited flow control window. Future extensions on QUIC (like the proposed datagram one) might change this.

You can create a new stream per datagram. Crazy, but it works.