Live data from Hacker News

We need a replacement for TCP in the datacenter [pdf]

web.stanford.edu

101–110 of 329 posts

Re: We need a replacement for TCP in the datacenter [pdf]

#102

I'd tell you a UDP joke, but you probably wouldn't get it. So here's a TCP joke: Hello, would you like to hear a TCP joke? Yes, I'd like to hear a TCP joke. OK, I'll tell you a TCP joke. OK, I'll hear a TCP joke. Are you ready to hear a TCP joke? Yes, I am ready to hear a TCP joke. OK, I'm about to send the TCP joke. It will last 10 seconds, it has two characters, it does not have a setting, it ends with a punchline.…

Did

Did you

Did you hear

Did you hear the

Did you hear the one

Did you hear the one about

Did you hear the one about traceroute?

Re: We need a replacement for TCP in the datacenter [pdf]

#103

Earlier quoted context omitted.

Cute, but I am suggesting not having a standard response.

And "not having a standard response" is the antithesis of global communication. I appreciate your perspective though. Have a wonderful day.

I usually find that standard responses impede real communication.

Re: We need a replacement for TCP in the datacenter [pdf]

#104
The assumptions here seem to be no speed of light lag, no packet loss, and no security. The only problem is congestion. That's more like the interconnection fabric of a single-purpose supercomputer than a general-purpose data center. Which is probably why they mention Infiniband, a hardware interconnect for supercomputers, so much.

Would this break down if you had to start talking to a remote machine in another data center? That's how outages and overloads are handled, after all.

This is an interesting idea, but it's for a relatively narrow use case.

Re: We need a replacement for TCP in the datacenter [pdf]

#105
My take: this is the making of a great essay question for a graduate course in networking.

The chance of TCP being thrown out wholesale is zero. What might happen is some slow, incremental improvements in certain aspects of networking, like some other comments suggest.

Until eventually, a networking student picks up a dusty old TCP doc and says to his teacher, innocently, "But we're not doing hardly any of this stuff anymore!"

Re: We need a replacement for TCP in the datacenter [pdf]

#106
post #83

Earlier quoted context omitted.

In addition to QUIC, KCP [1] is another reliable low-latency protocol that sits on top of UDP that might be interesting. And unlike RFC 9000/9001 (QUIC), encryption is optional. I haven't really seen it mentioned much outside of primarily China-focused projects, like V2Ray [2], but there is also some English information in their Git repo [2]. [1]: https://github.com/skywind3000/kcp > [2]: https://www.v2fly.org/en_US/…

KCP uses a brute force congestion control algorithm that is unfair and inefficient. It is also poorly specified, which is probably why it is less commonly used outside circumvention circles.

KCP is notably used by the popular mobile game Genshin Impact.

Re: We need a replacement for TCP in the datacenter [pdf]

#107

I'd tell you a UDP joke, but you probably wouldn't get it. So here's a TCP joke: Hello, would you like to hear a TCP joke? Yes, I'd like to hear a TCP joke. OK, I'll tell you a TCP joke. OK, I'll hear a TCP joke. Are you ready to hear a TCP joke? Yes, I am ready to hear a TCP joke. OK, I'm about to send the TCP joke. It will last 10 seconds, it has two characters, it does not have a setting, it ends with a punchline.…

Wait, two characters, as in, like, characters in a string, or characters in a story? Is a punchline like a newline?

Re: We need a replacement for TCP in the datacenter [pdf]

#108

The assumptions here seem to be no speed of light lag, no packet loss, and no security. The only problem is congestion. That's more like the interconnection fabric of a single-purpose supercomputer than a general-purpose data center. Which is probably why they mention Infiniband, a hardware interconnect for supercomputers, so much. Would this break down if you had to start talking to a remote machine in another data…

It’s a narrow use case sure, but at the same time it’s an important one to a number of companies with significant engineering resources.

Re: We need a replacement for TCP in the datacenter [pdf]

#109

Yes!!! I have been saying for years that lower level protocols are a bad joke at this point, but nobody in the industry wants to invest in making things better. There are so many improvements we could be making, but corporations don't see any "immediate shareholder value", so they sit around happy as pigs in shit with the status quo. What's kind of hilarious about this paper is, these are just the network-layer probl…

> corporations don't see any "immediate shareholder value", so they sit around happy as pigs in shit with the status quo.

And yet every time hardware designers get the chance they redesign Ethernet and IPv4--poorly.

See: HDMI 2.0+, USB 3.0+, Thunderbolt 3.0+, etc.

My suspicion is that this paper works fine beween pairs of peers and immediately goes straight to hell after that. It is extremely suspicious that there is zero mention of SCTP and only compares to TCP and not UDP.

The problem with RPC is that multiple organizations must agree on meaning. And that's just not going to fly. It is damn near a miracle that a huge number of institutions all agree on the Ethernet/IP command "Please take this bag of bytes closer to the machine named: ."

Re: We need a replacement for TCP in the datacenter [pdf]

#110

Earlier quoted context omitted.

> corporations don't see any "immediate shareholder value", so they sit around happy as pigs in shit with the status quo. This is ridiculous. Hyperscalars see an immediate ROI from efficiency/reliability improvements and actively invest in TCP alternatives all of the time. It's just really hard. Networking companies see an ability to differentiate their products from their peers and work on this kind of thing as well…

> 50 years of clock time and thousands of years of engineer time It's not just the size of the investment, it's that it's the protocol everyone uses to talk to other people's machines, and you can't upgrade or replace other people's machines.

Yes you can. Just offer a better product, and people will buy it instead of the old or bad product. Better yet, make the new product backwards compatible, and fewer people will have qualms about forking out for it. Better yet, do an aggressive takeover, like Microsoft did, and just force the entire industry to adopt your stuff...
Post reply on HN