Hi Martin, hi all, I've been just catching up on this discussion after holidays and reading it all at ones, I actually did see a good set of common and reasonable use cases, and there is a plausible solution which is a good starting point, plus there is clearly a group of interested participants.
I understand the worry that this work will of course take some effort (even though there are different views about how much effort it will take) and that it could take resources away from those items we have already agreed to work on. However, I also see that multipath support where multiple paths can be used simultaneously is a fundamental feature that generates interest. So far we have been able to work on various things in parallel, because there are subgroups in the wg that are more interested and are more experienced in e.g. http and maybe less in congestion control or the other way around. I think this is also doable in future. For multipath support I'd be more worried to move that work into a separate group as it is a fundamental feature and what we have seen for the MPTCP wg is that we at the end had a split of people where some of the usual TCP expert would not participate in the MPTCP discussion anymore which I think was also not ideal. I think at this point we should start the technical discussion on MP-QUIC based on what is specified in the individual draft we have around for a while. I was actually happy to see this kind of started (even though I think it would be more helpful if people could also state why they don't agree with a certain approach). Maybe we should also discuss if we want to update the charter and scope down what multipath capabilities we want to work on e.g. explicitly exclude scheduling and path management but focus on the signaling and transport features to simultaneous use multiple paths. Further we should prioritize the work where we have already adopted wg documents, however, I also see that at least 3 of those 5 documents are in good shape and can hopefully go to last call soon. As soon as those last calls for most of the current items are done, that's the time for me to run an adoption call for an multipath extension (or even a new version that has full multipath support), but it would be really good to have made progress on the technical discussion until then to get some common understand on the base principles we want to take to enable full multipath support. Mirja On 07.10.20, 04:03, "QUIC on behalf of Martin Thomson" <[email protected] on behalf of [email protected]> wrote: I know that this subject line might be taken to be inflammatory, but no point in burying the lede. The original charter for QUIC included multipath, partial reliability, and FEC. Multipath was definitely firmer than the others, but it was still aspirational. As part of a larger package deal, it seemed OK at the time. What has become clear to me over time is that there are only a small number of people who want to pursue multipath. And I don't know whether those people have common use cases or even if a single solution is appropriate for all of those use cases. Right now, it is not clear to me that we have the right combination of problem statements (or use cases), plausible solutions, and participants to successfully drive toward a design. I've followed the discussion recently and this has become increasingly apparent. The IETF processes for deciding whether to take on new work are designed to prove that there is a need for a standard. That need depends on proof of three things: supporting use cases, credible solutions, and interested participants. That process, by which I mean BoFs, is imperfect, but they are the best we have. And it looks like this working group is on a path to avoid that process. That would be a mistake. By coasting into a decision here, we risk confusing enthusiasm for QUIC as a whole for interest in this one feature. I appreciate that some people believe that there was an understanding reached on this topic. I know we've talked about this a number of times. But discussion was always about deferral in the past. We're now talking about concretely committing time to this. If the group had nothing else to do, then I'd be less concerned about the time being spent on this. I have no real interest, but I could go elsewhere. But QUICv1 is hardly done. We have more deployment experience to learn from, version negotiation, datagrams, performance tuning, and enough stuff to keep this community busy. If this community is not committed to building multipath capabilities, then forcing that upon them would be counterproductive. If the community is indeed committed, then a demonstration of that commitment should not be difficult to muster. Deciding whether the IETF should design a multipath QUIC needs to go to a BoF.
