Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's time to replace TCP in the datacenter (2023)

arxiv.org

Post reply on HN
Print view View original

61–70 of 160 posts

Re: It's time to replace TCP in the datacenter (2023)

#61

Post by bamboozled »

pif wrote: post #49

> Although Homa is not API-compatible with TCP, IPv6 anyone? People must start to understand that "Because this is the way it is" is a valid, actually extremely valid, answer to any question like "Why don't we just switch technology A with technology B?" Despite all the shortcomings of the old technology, and the advantages of the new one, inertia _is_ a factor, and you must accept that most users will simply even re…

Also there needs to be a big push to educate people on . I know TCP very well, it would need quite a lot of incentive for me to drop that for something I don't yet understand as well. TCP was highly beneficial which is why we all adopted it in the first place, whatever is to replace it needs to be at least that beneficial...which will be a tall order.

Re: It's time to replace TCP in the datacenter (2023)

#62

Post by mafuy »

slt2021 wrote: post #55
UltraSane wrote: post #12

I wonder why Fibre Channel isn't used as a replacement for TCP in the datacenter. It is a very robust L3 protocol. It was designed to connect block storage devices to servers while making the OS think they are directly connected. OSs do NOT tolerate dropped data when reading and writing to block devices and so Fibre Channel has a extremely robust Token Bucket algorithm. The algo prevents congestion by allowing receiv…

my take is that within-datacenter traffic is best served by Ethernet. Anything on top of Ethernet, and we no longer know where this host is located (because of software defined networking). Could be next rack server, or could be something in the cloud, could be third party service. And that's a feature, not a bug: because everything speaks TCP: we can arbitrarily cut and slice network just by changing packet forwardi…

In data centers/HPC, you need to know which data is flowing where and then you design the hardware around that. Not the other way around. What you describe is a lower requirement level that is much easier to handle.

Re: It's time to replace TCP in the datacenter (2023)

#63

Post by tsimionescu »

Woodi wrote: post #47

You want to replace TCP becouse it is bad ? Then give better "connected" protocol over raw IP and other raw network topologies. Use it. Done. Don't mess with another IP -> UDP -> something

Within a data center? Maybe. On the Internet? You try offering a consumer service over SCTP first, and that is decades old by this point.

Re: It's time to replace TCP in the datacenter (2023)

#64

Post by mafuy »

GoblinSlayer wrote: post #43

> For many years, RDMA NICs could cache the state for only a few hundred connections; if the number of active connections exceeded the cache size, information had to be shuffled between host memory and the NIC, with a considerable loss in performance. A massively parallel task? Sounds like something doable with GPGPU.

This has nothing to do with computing, it is about memory access.

Re: It's time to replace TCP in the datacenter (2023)

#65

Post by dboreham »

GoblinSlayer wrote: post #43

> For many years, RDMA NICs could cache the state for only a few hundred connections; if the number of active connections exceeded the cache size, information had to be shuffled between host memory and the NIC, with a considerable loss in performance. A massively parallel task? Sounds like something doable with GPGPU.

Now the information has to be shuffled between the NIC and host memory and the GPU.

Re: It's time to replace TCP in the datacenter (2023)

#66

Post by ezekiel68 »

I feel like there had ought to be a corollary to Betteridge's law which gets invoked whenever any blog, vlog, paper, or news headline that begins with "It's Time to..."

But the new law doesn't simply negate the assertion. It comes back with: "Or else, what?"

If this somehow catches on, I recommend the moniker "Valor's Law".

Re: It's time to replace TCP in the datacenter (2023)

#67

Post by imtringued »

t-writescode wrote: post #40
yesbut wrote: post #9

Another thing not worth investing time into for the rest of our careers. TCP will be around for decades to come.

True! And chances are, if you're developing website software or video game software, you'll never think about these sorts of things, it'll just be a dumb pipe for you, still. And that's okay! But there are other sorts of computer people than website writers and business application devs, and they're some of the people this would be interesting for!

>True! And chances are, if you're developing website software or video game software, you'll never think about these sorts of things, it'll just be a dumb pipe for you, still.

Wrong. I've experienced most of the complaints in the paper when developing multiplayer video games. These days I simply use websockets instead of raw TCP because it is not worth the effort and yet you still have to do manual heartbeats.

Re: It's time to replace TCP in the datacenter (2023)

#68

Post by imtringued »

j16sdiz wrote: post #29
bmitc wrote: post #24

Earlier quoted context omitted.

Yes, I know that WebSockets layer over TCP/IP. But that both misses the point and is part of the point. The reason that I ask is that WebSockets seem to almost always be used in the context of web applications. TCP/IP still seems to dominate control communications between hardware. But why not WebSockets? Almost everyone ends up building a message framing protocol on top of TCP/IP, so why not just use WebSockets whic…

WebSocket is fairly inefficient protocol. and it needs to deal with the upgrade from HTTP. and you still need to implement you app specific protocol. This is adding complexity without additional benefit It make sense only if you have an websocket based stack and don't want to maintain a second protocol.

You can easily build a JSON based RPC protocol in a few minutes using WebSockets and be done. With raw TCP you're going to be spending a week doing something millions of other developers have done again and again in your own custom bespoke way that nobody else will understand.

Your second point is very dismissive. You're inserting random application requirements that the vast majority of application developers don't care about and then you claim that only in this situation do WebSockets make sense when in reality the vast majority of developers only use WebSockets and your suggestion involves the second unwanted protocol (e.g. the horror that is protobuffers and gRPC).

Re: It's time to replace TCP in the datacenter (2023)

#69

Post by KaiserPro »

UltraSane wrote: post #12

I wonder why Fibre Channel isn't used as a replacement for TCP in the datacenter. It is a very robust L3 protocol. It was designed to connect block storage devices to servers while making the OS think they are directly connected. OSs do NOT tolerate dropped data when reading and writing to block devices and so Fibre Channel has a extremely robust Token Bucket algorithm. The algo prevents congestion by allowing receiv…

FC was much more expensive than ethernet, so needed a reason to be used.

For block storage it is great, if slower than ethernet.

Post reply on HN