Live data from Hacker News

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

web.stanford.edu

91–100 of 329 posts

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

#91
post #79
post #49

Earlier quoted context omitted.

Or, by sending the traffic over all routes, there is no way to keep one server from monopolizing all traffic, because each route is oblivious to the stress currently being experienced by all its peers. It has to set a policy using local data, not global data. The usual failure mode for clever people thinking about software is taking their third person omniscient view of the system status and thinking they can write s…

Ultimately one server cannot inject more than one link worth of traffic (e.g. 100 Gbps) into the network which is a tiny fraction of total capacity. Researchers have gotten really good results with "spray and pray" for sub-RTT flows combined with latency and queue depth feedback for multi-RTT flows.

Spray and pray sounds like a reasonable fit for UDP, no?

We’ve had these sorts of bottlenecks before, and they didn’t last. It’s always possible something fundamental changed, but it’s also possible that we are doing something wrong as the motherboard or OS levels and adopting new solutions puts us right back in that space where a couple of servers can easily saturate a network.

If a network card can move data as fast or faster than the main memory bus on a computer then what are we even doing? Should we be treating each subsystem as a special purpose computer and turn the bus into a network switch?

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

#92
post #76

Earlier quoted context omitted.

Don’t the hyperscaled cloud providers run totally segmented networks? What’s stopping them from using something proprietary internally and just exposing TCP at the end for termination of client connections?

Google already does that.

I’m not aware of them using something other than TCP internally (I’m sure by now they’ve migrated to QUIC but I’m not sure that QUIC necessarily solves some of the scaling challenges / optimizes for gRPC and low latency).

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

#93
post #18

Funny. I worked at AT&T Bell Labs in the 80s. All of these insights seem eerily familiar.

Sure; they're also similar to the SCTP insights, from the late 1990s.

Yup. Also QNX native networking protocol. QNX's basic networking primitive is a remote procedure call. So there's a message-oriented network protocol underneath. It can be run either on top of UDP or directly at the IP level.

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

#94

Earlier quoted context omitted.

They're not trying to make a universal standard. People are way too quick to dig out this xkcd.

So, you are suggesting a different standard response. I think this cognitive trap neglects the lessons of NetBEUI. Enhance your calm.

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

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

#95
post #56

Earlier quoted context omitted.

Surely most of your ideas are already being deployed in QUIC/HTTP3. It just happens inside a UDP datagram, for compatibility. Really you're not going to see any new IP protocol layers, there's too much quirky hardware on the network that wouldn't be able to handle it. If we can't even get IPv6 to work all the way to the client, we're never seeing new values for the protocol byte.

Don’t the hyperscaled cloud providers run totally segmented networks? What’s stopping them from using something proprietary internally and just exposing TCP at the end for termination of client connections?

They do, it's called DCTCP. Although it's actually an open standard.

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

#96

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

The handshake sequence is exaggerated. It's just usually 3 messages. The 3 initial messages establish a connection. A: I would like to tell you something. (SYN) B: I acknowledge you want to tell me something. (SYN-ACK) A: I received your acknowledgement. (ACK) After the handshake sequence is done, data transfer begins. Only then, it is possible to know that the "something" was a joke. If B answers with RST instead of…

[deleted]

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

#97

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…

At last hopefully there is light at the end of the tunnel. Big question for me is who is going to build it?

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

#98
Often these “revolutionary” changed get deconstructed and co-opted. Not always a bad thing. Looking through a video he did about this paper, I see a few things that could be popped out.

SRPT (shortest remaining processing time) is there any reason this couldn’t be implemented as a LAN protocol?

Receiver driven congestion control: isn’t this what the transmit window does? Are we not just talking about setting a more aggressive starting value?

“sends packets in any order” and “can only send the first few packets without a grant (ack)” are fighting each other. Especially if you’re building a message oriented protocol, which tends to have shorter conversations. This reads as confused or schizophrenic.

I think of what us being said here is that the Berkeley socket protocol sucks, and that a different one can get from user space to response faster. Great. But do you have to change the wire protocol for that or just introduce a better system call library? This part in particular reads a lot like , “what if Erlang was right and we implemented it at the kernel level?” Which is not a bad question to ask.

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

#99

Earlier quoted context omitted.

So, you are suggesting a different standard response. I think this cognitive trap neglects the lessons of NetBEUI. Enhance your calm.

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.

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

#100
post #76

Earlier quoted context omitted.

Google already does that.

I’m not aware of them using something other than TCP internally (I’m sure by now they’ve migrated to QUIC but I’m not sure that QUIC necessarily solves some of the scaling challenges / optimizes for gRPC and low latency).

Google is using remote memory accesses rather than TCP for at least some classes of traffic (e.g. a caching system). They've been publishing details about how it all works too.

Also, they have a transport (Pony express) developed specifically for RPCs, rather than byte streams or datagrams.

Links: https://research.google/pubs/pub51341/, https://research.google/pubs/pub50590/, https://research.google/pubs/pub48630/, more generally https://research.google/pubs/?area=networking

Post reply on HN