TCP Sucks

This is a really weird comment. It's dated today, but seems to contain words from 1300 or so.

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?

TCP is fine. There is some questionable things here and I'll just touch on a couple of them.

1) TCP checksums are a bit weak.

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 bit 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.

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.

2) TCP's over-eager in-order delivery

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 might 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.

I think you might be mistaken on the flexibility of the infrastructure.

I personally don't think IP (tcp and udp included) will be used on Internet 2.0. Theres just too much baggage with those protocols.

Perhaps we'll see Internet 1.5 leverage encapsulation and build a huge underlying canvas for new protocols to blossom, but we seem to be approaching the point where anything with an IP address is too much of a hassle to maintain and a longterm security liability/commitment.

Just moving IP to the borders of a network would open up space for more secure protocols.

Its probably time we put the middle one behind port 79 anyways.

File-transfer is a bad example. A good example would me multiplexed REQ-RES protocol. There is no reason for Message #2 to wait on message #1.

This issue, however, is so overblown by the author. It's not that often earlier packages delayed and new packages arrive faster and when that happens often you problem is usually much greater than server waiting for 101-200 before sending 201-300 to application...

To me the most annoying part of TCP are:

- Slow Start - Single channel - Single Mode

Everyone life would be so much better if within a single established connection you could open multiple channels in multiple modes like framed vs stream. Each channel could have its own order with congestion control overseeing entire bunch of channels.

You can build something similar on top TCP today, but it's not the same. Best part of TCP is that it's a standard available everywhere without conflicting implementations.