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

161–170 of 329 posts

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

#161

Post by fragmede »

simplotek wrote: post #146
duped wrote: post #112

Earlier quoted context omitted.

Every major corporation has multiple research organizations doing nothing but invest in things that don't have immediate shareholder value. What you're talking about though isn't just coming up with new ideas or even new products. It's replacing hundreds of billions in infrastructure wholesale. The scale at which these changes needs to happen to be practical are at the cluster level in a single data center. If you ca…

> What you're talking about though isn't just coming up with new ideas or even new products. It's replacing hundreds of billions in infrastructure wholesale. I'd put it differently: it's paying up hundreds of billions in infrastructure to have some sort of gain. And which gain is that exactly? I see a lot of "the world is dumb but I am smart" comments in this thread but I saw no one presenting any clear advantage or…

I mean the goal is more performance, especially if you can get more performance out of the same hardware. Faster setup times, faster connections, more connections, maybe faster teardown. Lower contention on saturated links. Inside of the datacenter is a controlled environment where something like that could work. Replacing TCP over the Internet at large is going to be an uphill battle. Still, if we're replacing the whole thing, then simpler code on the client and server end would be nice.

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

#162

Post by midasuni »

tezza wrote: post #155
lamontcg wrote: post #131

Earlier quoted context omitted.

After having lived through Amazon's early (pre-2003ish) UDP-based networking I got a laugh around 2006-ish or so reading about how facebook was into UDP. I assume there are people who worked there who still have the scars.

Do you have any specific problems you can elaborate with the UDP ? UDP used successfully many places.

UDP is just a protocol. I’ve served millions - even billions - of people with UDP media delivery. I use it all the time for all my work communication (WireGuard)

I wouldn’t use it to ping my gateway though, or to join a multicast group, nor would I use it to establish my bgp session, I use icmp, igmp and tcp for that.

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

#163

Post by primeblue »

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…

No post body was provided.

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

#164

Post by friendzis »

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…

> It completely ignores that the "port number" abstraction for service identification has completely failed due to the industry glomming onto HTTP as some sort of universal tunnel encapsulation for all application-layer protocols

I think this is more of an artefact of horizontal scaling and port-contention. De-facto standard discovery mechanism DNS does not work with ports, so "well-known port" abstraction kinda fails. Http as tunnel mostly avoids/sidesteps this problem.

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

This is weird take or I don't understand it. If you can communicate with an edge node in another network, but the edge node has issues communicating with some inner node (on your behalf), then, as a user, you have no hope of fixing that connectivity issue anyway, regardless of whether layered approach is used or not. This may be related to previous point about http as universal tunnel. Yes, this is a problem, but in a way that communications are effectively terminated at the edge node and monstrosity of stuff happens behind the scenes

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

#166

Post by Luker88 »

kanwisher wrote: post #145
Luker88 wrote: post #135

A few years ago (when QUIC was coming out) I was developing the theory of a new transport/encryption/authentication protocol. The focus was as much on transport as in the built-in federated authentication. There was not much interest in the field and I had a lot of the theory and formal proofs, but no implementation. This month I found a cofounder and we are reordering a lot of the information and presentation, we sh…

Why don’t you actually build gasp a prototype before asking for money

yeah, thank you for the kind comments about not needing money (aka: my time as no value) and asking me to build the prototype with irony.

As I said, the project was started a few years back, and since I did not have the time to work on it, maybe it means my life does not give me the time and money to build this on the side.

But I'll always find it funny how half of the people go "you need to have solid theory proofs before" and the other half goes "where is the working code".

As I said we just started some housekeeping and are not ready to start, and as many point out, it's hard to make money on infrastructure. I know, I did not ask how to make money on this. The idea is to keep the base as open as possible and make money on other service built on this. I was only asking on pointers to funds interested on tech loosely connected to this. And if they don't like our current state or something else fine, no need for you to do their job, and in a witty way, too.

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

#167

Post by ithkuil »

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 :-)

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

#168

Post by adamcharnock »

tezza wrote: post #155
lamontcg wrote: post #131

Earlier quoted context omitted.

After having lived through Amazon's early (pre-2003ish) UDP-based networking I got a laugh around 2006-ish or so reading about how facebook was into UDP. I assume there are people who worked there who still have the scars.

Do you have any specific problems you can elaborate with the UDP ? UDP used successfully many places.

I’m really looking forwarding to seeing the original commenters reply on this. But I’ll share my experience too.

I’ve found UDP to be great for latency but pretty awful for throughout. Especially over longer routes (ie inter-region transports). Also, if you fire UDP packets out of a machine in a tight loop then there is every chance you could overload various buffers and just loose them (depending on the networking hardware).

TCP is comparatively amazing for throughput, but you do take a latency hit (especially on the initial handshake, which doesn’t exist for UDP).

There are some very experienced people commenting here though, and I’d be happy to be corrected or expanded upon.

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

#169

Post by Luker88 »

mikepurvis wrote: post #151
Luker88 wrote: post #135

A few years ago (when QUIC was coming out) I was developing the theory of a new transport/encryption/authentication protocol. The focus was as much on transport as in the built-in federated authentication. There was not much interest in the field and I had a lot of the theory and formal proofs, but no implementation. This month I found a cofounder and we are reordering a lot of the information and presentation, we sh…

Very interesting stuff, but not going to lie, I have trouble imagining how you'd build a viable company around this kind of thing. Infrastructure/protocol companies are always going to be a very tough sell (Sandstorm) unless there's a compelling freemium model like with GitLab, Cloudbees, Sentry, etc.

The infrastructure/protocol will need to remain open, since this kind of thing works better the bigger the user base is. it will probably spin off to its own foundation as soon as it is viable.

The income will come from another project built directly on this, on managing the domain and its users/devices, plus other stuff, mainly for businesses.

I don't see much need to go into details right now, but we have a clear distinction in mind between what is infrastructure and what will be the product.

Again, still in the housekeeping phase, just looking for potential future funds once we finish this phase

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

#170

Post by patrec »

friendzis wrote: post #164
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…

> It completely ignores that the "port number" abstraction for service identification has completely failed due to the industry glomming onto HTTP as some sort of universal tunnel encapsulation for all application-layer protocols I think this is more of an artefact of horizontal scaling and port-contention. De-facto standard discovery mechanism DNS does not work with ports, so "well-known port" abstraction kinda fail…

> De-facto standard discovery mechanism DNS does not work with ports

Yes, it does, see SRV records.

Post reply on HN