Part of what we're arguing in this article is that there is no good answer today because of the assumption that TCP was good enough. Homa is challenging that assumption (as many others have tried before). My view is that if you want something better than TCP for RPC today, QUIC is the best thing available, as discussed here: https://systemsapproach.substack.com/p/quic-is-not-a-tcp-rep...

What you run over that for your RPC is a matter of taste - gRPC is certainly popular, and can be run over QUIC.

You’re thinking too high level, this is talking about replacing TCP or UDP with a new transport protocol designed specifically with RPC in mind.

Instead of opening a TCP (or UDP) socket and writing data (or data grams) to it you’d open a (for want of a better term) RPCP socket and write data that represents the procedure call and parameters to it.

I assume the protocol would have assurances of some kind of reliability (unlike UDP) and procedure call data boundaries (unlike TCP) built in at the lowest levels along with request/response sequences to allow out of order completions.

Flatbuffers, Cap'n Proto, or SBE over RDMA.

I'm a huge fan of capnproto.org

Check out eRPC.io

It leverages DPDK and is perfect for low-latency RPC in lossless DCs