“Ultimate responsibility for RESENDs lies with the client: if it has not received the entire response message within an expected time then it MUST issue RESEND request(s) for the missing part(s) of the response.”
I retract my statement that it does not describe whole RPC loss in protocol.
However, even as someone familiar with network protocols and reading RFCs that is a very oblique and easy to miss way to describe the process. I would recommend a more direct and explicit treatment of the “request lost” case and make clear the “RESEND Length=-1” mechanism as this seems like the only case where that should be relevant. Likely also a state machine since the state flows are different than the regular data loss mechanism; Tx DATA, Tx Lost, Tx RESEND, Rx RPC_UNKNOWN, Tx DATA or something of the like.
Also as I mentioned in another reply [1] the described mechanism has many undesirable propertys.
2. My statement was more about explicit consideration as to how encryption integrates. Sure, you can just layer it below with IPSec or above with TLS, or any other myriad of ways as you could in literally any protocol for transmitting bytes, but TLS over TCP versus QUIC shows how much more painful it is if it was not in the original design.
3. I did not see that it was a duplex benchmark, but that is a very non-standard way to benchmark, so I can not comment as to comparability to standard one-way benchmarks. If a one-way benchmark is equivalent to the sum of the two-way flows, then I will concede that it is comparable to QUIC implementations.
However, my personal experience with designing and implementing transport protocols results in me finding 8 Gbit/s per core in software to be extremely slow which also applies to every QUIC implementation I have ever seen.
4. Congestion control in QUIC, like in TCP, is not fixed though there are recommended implementations. Furthermore, stream prioritization, something not present in TCP due to the single stream nature, is also not fixed. A implementation that offers prioritizing which streams to transmit data for by SRPT would likely see similar outcomes to Homa. I am not aware of any implementation that does so, but it is a freely configurable element of that protocol. I see nothing that would materially stop a comparable solution from being dropped in.
Mainly, unlike TCP, the design of QUIC has knobs in many of the right places so that you can reasonably configure the desired propertys with minimal design clashing.
Really, the main fundamental distinction in steady state operation is the resend mechanism being largely ack driven TCP and QUIC whereas Homa is largely nack driven.
I am of the opinion that ack driven is much superior technically, which is part of why I think Homa is a bad design, but likely for different reasons and considerations as to how it relates to transport protocol design than the designers of QUIC.
This is also not to say that I think QUIC is the best protocol, QUIC has a number of design and performance weaknesses, but it is overall a reasonable and material improvement over TCP and should be considered the standard to beat.