Suggested multipath changes

[Michael Eriksson <[e-mail]>]

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

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 :-).

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.


/me