Hi Jana,
On Thu, Nov 5, 2020 at 11:01 PM Jana Iyengar <[email protected]> wrote: > 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? > > There is no existing multipath mechanisms in QUICv1. Period. Please refer to my mail. Behcet Behcet > - jana >
