[lmilcin]

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.

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.

It might be because it is "just enough" to build upon.

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.

For some reason none of these projects get traction.

[klodolph]

Depends on what you mean by “traction”. You and I may sit at home with our gigabit internet connections and think that the limitations of TCP are a minor annoyance at best. However, at the internet factories, where internet is made, in large data centers spanning the globe, TCP’s flow control translates directly to poor utilization of expensive, high-bandwidth links between different data centers. The problem gets worse as the links get bigger. The utilization left on the table is easily enough to pay for the salaries of a few world-class network engineers and kernel programmers.

As an analogy, consider high power factor power supplies. Nobody is gonna care, at home, what the power factor of their PSUs are. However, a poor power factor at a large scale (electrical grid) translates to millions of dollars of unused current capacity. The money left on the table was so large that PFC is everywhere these days. The same thing will happen with TCP's replacement. Just give it time.

[lmilcin]

That, again, is static view.

Game-theory view is that any organization that would like to push this would have to spend enormous amount of resources to reinvent almost anything that has anything to do with TCP. Remember, it is implemented in hardware in many different types of devices, stacks, applications, it permeates almost anything. The application I am working on right now which has lived for over a decade and will live for another has TCP artifacts all over it. Who's going to want to fix it when it gains maybe a tiny bit of additional performance?

There aren't very many applications that have TCP as their single biggest performance problem with best ROI. Almost every is integrated with bunch more other applications over TCP causing chicken-egg problem.

Maybe Google could do that? IDK. They would maybe do it after they have reinvented almost everything else in their DC infrastructure.

[klodolph]

It sounds like you are evaluating the idea that protocol X will replace TCP, but I don’t think anyone is making that argument. Protocol X would be used alongside TCP, and you wouldn’t be able to use protocol X in all networks. This is already the world we live in.

[lmilcin]

Then I don't understand what your argument is. There is already a bunch of protocols you can use if you don't like TCP.

[klodolph]

I’m saying that these protocols are getting traction.

[the8472]

> in large data centers spanning the globe, TCP’s flow control translates directly to poor utilization of expensive, high-bandwidth links between different data centers.

For internal traffic they have the option to choose custom congestion controllers that don't care about being fair to Reno and can also tolerate a few packet losses. Linux has offered options here for a long time.

[renox]

Some of the articles point have nothing to do with the age of TCP, some do, if I copy just two points: 1) TCP makes applications build their own messaging protocols on top 2) The three-way handshake (and connection shutdown) is slow and wasteful for short connection (1) is a big issue but has nothing to do with the age of TCP whereas (2) is related to TCP's age: using big SYN cookies with the underpowered hardware of the time..

[senderista]

Unfortunately we're stuck with TCP, UDP, and nothing else if you want to build on IP, thanks to protocol ossification. That's one of the main reasons why QUIC built on UDP rather than directly on IP (and why they didn't just use SCTP).