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

141–150 of 329 posts

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

#141

Post by topranks »

adobrawy wrote: post #48
BirAdam wrote: post #10

Well, the key would be to develop and deploy Homa in a DC and test in implementation at scale. If it actually ameliorates the perceived shortcomings of TCP that make nothing in TCP worth keeping as this author says, then cool. My only complain with issues like this is the cost of implementation. Someone has to pay to build a DC around it or increase the cost of maintenance for several years to a decade while supporti…

Homa protocl can be deployed on the basis of existing switches (not all of them, but some of them will play well). See also https://github.com/PlatformLab/HomaModule . In addition, a closed environment and the SDN's popularity in large data centers is a significant cost-reducing factors compared to typical IPv6 deployment.

Hmm I didn’t really read about it.

The proposal here is to replace IP as well as TCP?

Good luck pulling that off.

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

#142

Post by simplotek »

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…

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

If this was true then how do you explain that the likes of AWS, the same company who ended up investing in developing their own processor line, doesn't seem to agree that none of the pet peeves you mentioned are worth fixing?

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

#143

Post by josefx »

manv1 wrote: post #7

It's interesting that everyone (including the author) talks about UDP as a lossy protocol, but it doesn't seem that UDP drops actually occur on a routine basis anywhere. The UDP-based DDOS attacks seem to prove that; if UDP really was being dropped, those DDOS attacks wouldn't be so problematic. That said, it's an interesting read. TCP is inefficient, but that inefficiency has been patched/masked by hardware solution…

> but it doesn't seem that UDP drops actually occur on a routine basis anywhere.

I have seen code that didn't even handle out of order delivery work well for over a decade in local networks. Even when that broke down it turned out that IP package fragmentation just triggers a slow path in smart switches, so if your packages fit into the networks MTU (with some bytes to spare for VLAN tagging) you still might be able to avoid the problem.

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

#144

Post by deanCommie »

ShroudedNight wrote: post #12

At a glance, this sounds very similar to AWS' SRD protocol [1] - I'm curious how they compare but I see no mention of SRD in this paper. [1] https://assets.amazon.science/a6/34/41496f64421faafa1cbe301c...

Strange how this is so far down the list but a more recent "nobody in the industry wants to invest in making things better" rant is higher upvoted.

Clearly, AWS knows a thing or two about the datacenter industry, wanted to invest in making things better, and DID invest in making things better - and even published a paper on it.

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

#145

Post by kanwisher »

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

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

#146

Post by simplotek »

duped wrote: post #112
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…

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 performance improvement claim about hypothetical replacements. I see a lot of "we need to rewrite things" comments but not a single case being made with a clear tradeoff being presented. Every single criticism of TCP/IP in this thread sounds like change for the sake of change, and changes that aren't even presented with tangible improvements in mind or a clear performance gain.

Wouldn't that explain why TCP is so prevalent, and no one in their right mind thinks of replacing it?

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

#147

Post by topranks »

manv1 wrote: post #7

It's interesting that everyone (including the author) talks about UDP as a lossy protocol, but it doesn't seem that UDP drops actually occur on a routine basis anywhere. The UDP-based DDOS attacks seem to prove that; if UDP really was being dropped, those DDOS attacks wouldn't be so problematic. That said, it's an interesting read. TCP is inefficient, but that inefficiency has been patched/masked by hardware solution…

“Lossy” is not the word.

Reliable/unreliable are the words.

Packets can and do get dropped, TCP, UDP or otherwise. It’s just a question of how the protocol behaves when that happens.

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

#149

Post by topranks »

PixelOfDeath wrote: post #23
vore wrote: post #8

Earlier quoted context omitted.

I think re UDP the point regarding it being unreliable is that you have to design your applications to take the unreliability into account, because it does happen even if it may be infrequent: assuming that it is reliable when you can get unreliable behavior will result in correctness issues.

I see UDP more like a low level interface allowing you to build your own on top. Where you decide what packages need to be revived 100% and which one can be dropped. Basically the foundation of your very own TCP with hookers and blackjack.

> Basically the foundation of your very own TCP with hookers and blackjack.

That’s exactly how the early drafts of the QUIC RFC described it /s

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

#150

Post by imtringued »

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

I don't bother implementing that crap anymore. I just websockets which are message oriented out of the box.
Post reply on HN