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

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

web.stanford.edu

Post reply on HN
Print view View original

191–200 of 329 posts

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

#191

Post by josephg »

langsoul-com wrote: post #154
josephg wrote: post #125

> The data model for TCP is a stream of bytes. However, this is not the right data model for most datacenter applications. Datacenter applications typically exchange discrete messages to implement remote procedure calls This isn't just a datacenter problem. Every single network protocol I've ever created or implemented is message based, not stream based. Every messaging system. Every video game. Every RPC transport.…

What do you make to require implementing or making network protocols?

Multiplayer video games, realtime updating webpages, database bindings, sync protocols (I play around around with CRDTs a lot), p2p distributed systems, whatever really!

Implementing a wire protocol seems to come up about once every couple of years. And for context, I've been programming now for about 30 years.

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

#192

Post by josephg »

ithkuil wrote: post #167
josephg wrote: post #125

> The data model for TCP is a stream of bytes. However, this is not the right data model for most datacenter applications. Datacenter applications typically exchange discrete messages to implement remote procedure calls This isn't just a datacenter problem. Every single network protocol I've ever created or implemented is message based, not stream based. Every messaging system. Every video game. Every RPC transport.…

Even TCP itself uses discrete messages under the hood :-)

Hah yes; although TCP frames can be arbitrarily refragmented and rejoined as they travel through the network before reaching your destination.

If you ever play an indie game which seems unusually janky over wifi, its probably because the code isn't correctly rejoining fragmented network packets at the application level. Ethernet is remarkably well behaved in this regard. Wifi is much better at shaking out buggy code.

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

#193

Post by rossmohax »

> It uses several techniques for this, of which the most notable is that it takes advantage of the priority queues provided by modern switches.

I'd understand if they said routers, but switches? Do L2 switches have any notion of priority and if yes how does it work?

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

#194

Post by twawaaay »

throwaway892238 wrote: post #37

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…

I don't think you realise why this is so hard.

The basic reason is that software at every level expects TCP/IP. And you can't drop in a translation layer because it will require at least the same amount of overhead as "real" TCP/IP.

It is not a local problem, it is a global problem that affects basically every single piece of non-trivial software in existence.

Even if you construct your datacenter with the new protocol you will run into problems that you can't run anything in it. Want Python? Sorry, have to rewrite it. And every Python library. And every Python application. Then you need to deal with problems that people who can run their scripts on their machines can't run them in datacenter. And so on.

The reason nobody wants to do this is that they would be investing huge amount of money to solve a problem for everybody else. Because the only way to make TCP/IP replacement work is to make it completely free and available to everybody.

There are much better ways to allocate your funds and precious top level engineers that let them distance themselves from competition temporarily.

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

#196

Post by sriku »

Ourtserhout's paper perhaps comes from his vision for RAMCloud as well ... in which he bet on network latency going ultra low over time that accessing memory on another machine was fast enough to enable whole new categories of applications to emerge.

https://dl.acm.org/doi/10.1145/2806887

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

#197

Post by starfallg »

throwaway892238 wrote: post #37

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…

> We still lack any way to communicate up and down the stack of an entire transaction, for example for debugging purposes. We should have a way to forward every single layer of the stack across each hop, and return back each layer of the stack, so that we can programmatically determine the exact causes of network issues, automatically diagnose them, and inform the user how to solve them. But right now, you need a human being to jump onto the user's computer and fire up an assortment of random tools in mystical combinations and use human intuition to divine what's going on, like a god damn Networking Gandalf. And we've been doing it this way for 40+ years.

This violates the principle of encapsulation that the entire field of networking is based on, not to mention an massive security hole.

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

#198

Post by zokier »

cryptonector wrote: post #130
jl2718 wrote: post #122

The ultimate dream protocol is one in which a sender just encodes bits in a certain way such that the receiver will get them, and puts them on the line without any handshaking or synchronization. I don’t think this is impossible. The space of orthogonal codes across time and frequency could be chosen to be practically infinite, therefore, any random selection of two such codes would look like white noise to each othe…

> The ultimate dream protocol is one in which a sender just encodes bits in a certain way such that the receiver will get them, and puts them on the line without any handshaking or synchronization. This is a recipe for DDoS. Some handshaking is always necessary. You can minimize it, but you can't get rid of it.

> This is a recipe for DDoS.

Inside a datacenter?

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

#199

Post by KaiserPro »

throwaway892238 wrote: post #37

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…

> We should have a way to forward every single layer of the stack across each hop, and return back each layer of the stack, so that we can programmatically determine the exact causes of network issues

Thats virtual networking. but that introduces latency if its not well configured.

> But right now, you need a human being to jump onto the user's computer and fire up an assortment of random tools in mystical combinations and use human intuition to divine what's going on, like a god damn Networking Gandalf

not really, assuming you have the right fabric, its nowhere near as hard as that. Plus you seem to be forgetting that there is more to the network than TCP. There is a whole physical layer that has lots of semantics that greatly affect how easy it is to debug higher levels.

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

#200

Post by Kiro »

8371861215 wrote: post #188
Aissen wrote: post #173

Earlier quoted context omitted.

Because most protocols can handle message loss, with retransmit and proper ordering ? And we haven't started to talk about congestion yet… TCP is useful, and while I'd like to see a message get rid of one (or more) of those constraints to go with a a custom protocol, I feel like they'd be re-implementing the features in the end because these are very useful properties to have… Edit : the proposal in the article is ac…

Quoted post unavailable.

Very peculiar spam. Does anyone have a theory what the motive is?
Post reply on HN