What to do about multipath in QUIC

[Spencer Dawkins at IETF <[e-mail]>]

Lars said that if we wanted to move forward on multipath in QUIC, we should
be talking about multipath in QUIC on the mailing list, so this is my
suggestion as a starting point, based on my understanding of where we ended
up after the October virtual interim meeting and resulting threads on the
mailing list.

It's pretty clear that a lot of people have deploying and testing
connection migration as their priority in the near future, and we should
not distract them from that worthy task.

It's clear that at least some people think that connection migration onto a
new connection that has already been validated is a lightweight operation.
Deploying and testing connection migration will be a good basis for
verifying that theory.

It's clear that there are different ways of thinking about multipath in
QUIC - https://datatracker.ietf.org/doc/draft-deconinck-quic-multipath/ is
the proposal I have the most experience with, but Yanmei was presenting
https://datatracker.ietf.org/doc/draft-an-multipath-quic/ at the virtual
interim, and Christian submitted
https://datatracker.ietf.org/doc/draft-huitema-quic-mpath-option/ a day or
two before the virtual interim. That leads me to make two suggestions:

   - That we get experience with the proposals that we already have, and
   any proposals that pop up in the meantime.
   - That we discuss that experience and work on coming to a consensus
   about how multipath should work before moving forward.
   - That we publish (one or more) multipath proposals as Experimental, if
   and when that's the right thing to do.

Thoughts?

Best,

Spencer