Ian,
Given the responses, can we narrow down the way forward(ideally on a
different thread) to directions that are less open-ended? I'll suggest
some options, but the chairs and/or ADs need to decide.
1) No future work on multipath in the QUIC WG, in the belief the
existing connection migration functionality is sufficient.
2) Adopt the existing draft as a starting point for QUIC
multipath(draft-deconinck-multipath-quic
<https://tools.ietf.org/html/draft-deconinck-multipath-quic>), with the
explicit goal of not expanding the scope of the document.
3) Adopting multipath as a core QUIC WG deliverable.
I favor #2, but these may not be the right options. Normally I'd say
people should work this out in person, but that doesn't seem viable at
the moment. I'm happy to set up a long(3-4+hr) Google Meet to discuss
this via videoconference if that helps move the discussion forward.
Thanks for proposing this excellent suggestions.
Or we can form a design team, which typically takes O(3 months) to finish.
I think that it would be useful to continue the technical discussion
that has started. I'll leave up to the WG to decide how best to proceed.
I'd also suggest to initially keep the scope of the multipath discussion
narrow. We can update the draft to include the feedback received so far
or collect issues on github and then work to address them
Olivier
