On 6/13/2022 7:03 AM, Michael Eriksson wrote:
Hi fellow multipathers, In addition to my separate response to Christian Huitema's suggested draft updates I have some additional suggestions for changes to the multipath protocol below. I send this as a wg mail instead of GitHub PRs in hope to induce some discussion. I am currently arguing for a protocol with multiple packet number spaces, so that is implied in the text below. Acknowledgements The current version of the multipath draft specifies the use of ACK_MP frames when multipath has been enabled. I suggest that the regular ACK frames should be used also for multipath, and that ACK_MP frames could be optionally used as an optimization. The ACK frame would mean that packets on this particular path is acknowledged. The implementation would be very similar to singlepath QUIC when it comes to RTT estimates, loss detection etc, which would reduce the implementation complexity. ACK_MP, on the other hand, could be used to acknowledge packets received on other paths (it could be used for the same path but with some overhead compared to a regular ACK frame). Some reasons to use ACK_MP: * Faster acknowledgement can allow some congestion control algorithms to increase the congestion window (but see below) * Faster loss detection (and retransmission) in some cases * Reduced buffering on the sender side and smaller flow control receive windows
Mixing ACK and ACK MP looks like a recipe for bugs in implementations. The current spec is very clear: implementations MUST use ACK-MP if they negotiate multipath. If they receive a regular ACK frame, they MUST treat it as an ACK for path 0.
From an implementation point of view, it is just as simple to send ACK "on this path" and ACK-MP "on this path."
RTT updates and indirectly setting PTO timers should normally only be done using in-path acknowledgements. Cross-path is interesting, but maybe complex enough to warrant a Ph.D. thesis, especially when path properties and existence change :-).
There are many scenarios mixing one high bandwidth -- high latency path, and another low bandwidth low latency path. In these scenarios it is much more efficient to send the acknowledgements on the low latency path, and trigger retransmissions or at least probes based on that. If an implementation wants to support these scenarios, it has to manage the corresponding complexity.
I'm not exactly an expert, but sending ACKs over different paths can probably confuse some congestion control algorithms, e.g., delayed-based ones like BBR. For instance, if you lose the fast ACK path the ACK latency increases for a remaining path which makes it needlessly slow down the sending rate. Explicit path setup This is a half-baked idea, but maybe it's better to use new signaling for setting up paths for multipath QUIC and not reuse path validation (PATH_CHALLENGE and PATH_RESPONSE frames). That could for instance give the server a chance to refuse another path even if the client has enough connection IDs to create one.
That would break the design goal of keeping exactly the same probe mechanisms as RFC 9000.
-- Christian Huitema
