TCP pretty obviously doesn’t suck as it’s pretty much powered the internet for the last 30ish (maybe more) years. I’m sure it isn’t perfect for every purpose and maybe I can be improved but enough with the click bait.
TCP is fine. There is some questionable things here and I'll just touch on a couple of them.<p>1) TCP checksums are a bit weak.<p>The author claims that we don't know how many errors are not caught by TCP's CRC and while that's true on some level the probability of <i>bit</i> errors is driven by properties of the physical medium over which the packet is traveling, not the transport layer protocol in use. That's why most, if not all, physical layers that do have a significant chance of bit errors have FEC built-in at the physical layer.<p>As a point of reference, I pulled stats on one of our servers and see about 10k bad packets out of 1.3 billion. If we assume that bit errors caused all 10k, we get an error rate of about %0.00076. Since we need two independent bit errors to trigger a state where the CRC might not catch the error, we can calculate that on this particular server we would expect .076 packets that might be corrupt in a way in which it's even possible for the existing checksum would miss it (and it probably would still be caught). If that is an unacceptable error rate, you should absolutely be using some way to verify message integrity at a higher layer. Still, for most applications, a fast hash that lets a bad packet through every couple of years is a good trade-off.<p>2) TCP's over-eager in-order delivery<p>The author talks about getting packets 1,3,2 in that order in the context of a file transfer, and in that specific scenario, it <i>might</i> be marginally preferable. Far more likely than out of order packets are lost packets and lost packets may never come if the connection gets closed/reset before its retransmitted. For the vast majority of applications having a partially transferred entity isn't helpful, but not having to deal with the complexity of out of order and partial transfers is.
How can there be so much TCP bashing, without a mention of SCTP. I mean at least that's implemented in some
BSDs with ports available for other OSes.
It sounds like the author wants a protocol that allows for arbitrarily-sized datagrams, with the ability to interleave the transmission of those datagrams across a some shared master connection.<p>From my relatively-inexperienced perspective, notwithstanding the widespread protocol ossification of Internet network infrastructure, the underlying MTU for each connection seems to be the primary constraint that any viable alternative must deal with effectively. This article did not seem to discuss MTU considerations at all. It's hard to take a protocol argument seriously that neglects to deal with such a fundamental constraint of network infrastructure.
I still think that NDN [0], Named Data Networking, is the proper successor to TCP/IP. TCP is oriented around streams, but NDN is oriented around blobs of data and names which represent them; as such, NDN is much closer to the application-level concerns that we care about.<p>The main problem is that namespacing is an extremely political process in any system, including NDN, and so we cannot have nice things.<p>[0] <a href="https://named-data.net/" rel="nofollow">https://named-data.net/</a>
TCP is only one of the transport layer protocols. There are 17 transport layer protocols listed in [1], including TCP.<p>It was never designed to be the all applicable universal transport protocol either. Or it was, but sane people realize that time window when TCP could be deemed universal is very short.<p>[1] <a href="https://en.wikipedia.org/wiki/Transport_layer" rel="nofollow">https://en.wikipedia.org/wiki/Transport_layer</a>
The 4,5,7 -- depending on who you ask --layer model is nothing but pseudoscience.<p><a href="https://ouroboros.rocks/docs/overview/" rel="nofollow">https://ouroboros.rocks/docs/overview/</a>
Let's start with the fact that TCP obviously has problems. People who wrote the protocol did not expect for it to live that long. At the time the life expectancy of any standard was pretty short.<p>But... before you get too caught up with bashing... if I were you I would spend just a tiny bit trying to really understand why we are in this situation.<p>It might be because it is "just enough" to build upon.<p>You are free to use bare UDP or even bare IP for your application if you are masochist or have spare budget to allocate for fun NIH projects.<p>For some reason none of these projects get traction.
Standards always generate debate. They almost always can be improved. But hey, they are usually good enough for most use-cases. The price we end up paying, though, many times without noticing, is that layer over layer of "good enough" ends up making life much harder than it needs to be. But we only change when a single layer is clearly identified as painful enough. The article is technically very interesting, but for the general discussion my main question is: what mechanisms do we have to effectively move forward with standards? Are standards committees (good) enough (when they exist)? Are we moving at the right pace?
I am a networking novice but the fact that my networking book (TCP/IP illustrated) has one chapter on UDP and several on TCP speaks (literal) volumes.<p>My entirely uninformed opinion is that if its possible to do everything TCP does over UDP we should do so just based on the fact that it is a simpler protocol. This means that broadly speaking I think the QUIC protocol is an improvement. (Whether or not its worth implementing the change I have no opinion on.)<p>Obviously this is a very naive understanding and I welcome others telling me where my simple model breaks down. Understandably the complexity is not removed and is only pushed up the protocol stack but I would argue that the higher complexity belongs at the application layer rather than the transport layer.
I feel like the article cherry picks examples of TCP doing either too much or too little given specific applications. Of course we could always go by the end-to-end principle and tailor protocols from scratch each time we build an application but in a lot of cases the state handling provided by TCP is a pretty solid base to work with. Also, unrelated to the article, there seems to be some Dunning-Kruger peak of hating TCP that a lot of people pass at some point, myself included.
These kind of articles are made by ignoramuses that don't understand that TCP is an edge protocol and those profit from ossification because it allows the backbone to evolve without everyone re-implementing everything over and over again at the edges!<p>Over-engineering and technical debt is a bi-product of: “It is difficult to get a man to understand something, when his salary depends upon his not understanding it!” - Upton Sinclair<p>On the backbone nothing uses TCP, not even IP. It's all BGP or other proprietary formats. Edit: I'm pretty sure the backbones with billions invested in fiber across oceans are not running vanilla IP from the 70s on their hardware/cables, don't you? Or if they do then it's case closed for anything else really, so any way you turn this.<p>Re-implementing delivery guarantee wont solve anything better ever, TCP and HTTP/1.1 are the final protocols for the human race in this universe, get over it and start building something useful on top of them instead.