Hi Spencer, I agree with your analysis that many of us think that our priority ought to be to test our existing multipath capabilities (connection migration) first before building more multipath capabilities. Which is why I agree with your first suggestion, but not the other two.
> > - That we discuss that experience and work on coming to a consensus > about how multipath should work before moving forward. > > I don't understand this (and I've read your response to Martin's similar comment). How is this a smaller work item than working on general-purpose multipath? > > - That we publish (one or more) multipath proposals as Experimental, > if and when that's the right thing to do. > > This will require the wg to adopt these proposals and engage on them. I don't understand how the second and third suggestions follow from your first suggestion of "get experience with the proposals that we already have, and any proposals that pop up". This is what I want to see, but that also means that we don't rush into adopting and working on proposals yet. I want to remind folks that we need to have bandwidth in the wg for the items that we _need_ to work on, and importantly, for experience that we will have to share about our early QUIC and HTTP/3 deployments. We need to have some room for it. I've been asking this, and I'll do it again: Can someone please explain what the urgency is in working on general-purpose multipath? Why are we not waiting for deployment experience with existing multipath mechanisms in QUICv1 before considering what to do next? - jana
