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
