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.

Check out eRPC for low-latency DC networking.

It would be nice to have something like that, but have libraries for most common languages.

Where would I find one of these lossless fabrics?

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.

I'm a huge fan of capnproto.org

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