Hi Michael, hi Christian, please see inline.
On 14.06.22, 22:54, "QUIC on behalf of Christian Huitema" <[email protected] on behalf of [email protected]> wrote: 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." [MK] I would also be concerned about ambiguity and potential implementation bugs here. It's always better to be explicit and therefore I think we should maybe even add a recommendation to the draft to always use ACK_MP. The decision on which path to send the ACK is really independent of that and we opened a new issue to add further recommendation to the draft (see https://github.com/quicwg/multipath/issues/123). [MK] Therefore I don't really understand the benefit of using an ACK frame instead of ACK_MP, expect for maybe saving a few bits but that is often not really an issue in the ACK direction. However, if you think this needs further discussion, feel free to open an issue on github! > > 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. [MK] We explicit set as one design goal to keep the differences to RFC900 as small as possible. So if there is no really good reason/clear use case to use new frames, I think we have consensus to re-use the existing ones. If you have a good reason or use case, please open a PR on github and we can discuss it further there. [MK] Regarding connection refusal, you can always do that by just not replying to the path challenges. Yes, that is slow and has some overhead but not really a use case that has been seen as important for now. This discussion actually also came up in this github issue: https://github.com/quicwg/multipath/issues/120 [MK] Moreover, even if we don't take this idea up now, there is always a possibility to specify a further extension in future. Given, we try to keep the changes to RFC9000 as small as possible with the current draft, you can see in the github issue list that this is also the proposed way forward to some other proposal (marked with the tag "separate draft"). Mirja
