Hi Spencer, I shy away from deciding "how multipath should work." I think we should figure how much protocol we need for the experimenters to figure out how multipath should work. But maybe that's what you meant.
On Wed, Nov 4, 2020 at 3:39 PM Spencer Dawkins at IETF < [email protected]> wrote: > 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 > >
