QUIC is much more well known than Homa. Are there downsides for using it for this application?
However, software QUIC implementations are generally much slower than software TCP implementations. This is not due to any fundamental protocol design limitations, it is just that most/every QUIC implementation is poorly implemented for maximizing performance.
You can, of course, do multiple times more throughput than QUIC or TCP with a protocol better designed for performance, but that is likely orthogonal to your question.
bold claim. Go tell that to Cloudflare, for example. And/or show us your implementation.
The official MsQuic benchmarks [2] tuned for the standard QUIC benchmark [3] with massively over-provisioned hardware does not even reach 8 Gbit/s on large sends with negligible RTT and loss.
If the highest performing public implementation can not even reach a paltry 8 Gbit/s it is fair to say they are all poorly performing.
As for what I would consider “okay” that would be around 30 Gbit/s per core, bottlenecking on decryption (assuming you do not use the allowed null encryption for benchmarking), or bottlenecking on ~1/3 of the bulk 1 Kbyte memcpy() throughput on your hardware, whatever comes first. “Good” is on the order of 100 Gbit/s per core or the same external limiting factors.
[1] https://www.sciencedirect.com/science/article/pii/S014036642...
[2] https://microsoft.github.io/msquic/
[3] https://datatracker.ietf.org/doc/html/draft-banks-quic-perfo...