connection migration / multipath considerations

[marten-seemann]

I'm wondering if we can make some easy changes to make this extension work better with connection migration, and with multipath, once that RFC ships.

I believe that the following two changes would be sufficient:

1. Define that ACK_FREQUENCY frames apply per path (i.e. the ACK_FREQUENCY frame with the highest sequence number on that path applies).
2. Make ACK_FREQUENCY a probing frame. This would allow endpoints to bundle an ACK_FREQUENCY frame with the PATH_CHALLENGE / PATH_RESPONSE frame, and have these settings immediately apply to the new path.

(2) is an optimization that would make switching to a new path more efficient (see #191).
(1) would allow the use of this extension with QUIC multipath, such that each path has different ack frequency settings (it however does not cover the case where ACKs are sent on different paths).

[kazuho]

To support multipath I think we have to change the definition of the frame to include DCID (or Path ID if quicwg/multipath#214 gets adopted), assuming that we follow the convention of allowing path control signals to be sent on any path (see ACK_MP, PATH_STATUS, etc.).

And I'm not sure if we want to see ack-frequency blocked by QUIC MP finalizing how paths are to be identified.

Maybe it would be easier to finish ack-frequency, then add a section to Multipath how ack-frequency is modified for Multipath, as that Multipath draft becomes mature?

[mirjak]

We have a corresponding issue in the multipath repo and the reply there was that a new multipath-aware ack-frequency frame should rather be a separate extension.