I agree with Martin here. I would personally attend the BoF and commit to reviewing drafts, but I think that separating multipath from other work items that are more critical to the success of QUICv1 is the right thing to do.
David On Tue, Oct 6, 2020 at 7:02 PM Martin Thomson <[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. > >
