Hi, Jana, Thanks for the thoughts. I have a couple of responses below, but would love for other people to be chiming in, because I barely speak for Spencer, these days.
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. > I'm actually happy, if the path forward has "continue to work on multipath proposals on the QUIC mailing list" as its first step. I went further, but the second and third bullets were speculative, and would depend on the QUIC working group, the QUIC working group chairs, and the responsible AD deciding what to do at some point in the future. Further direction on the path forward can be picked out along the way. > >> - 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? > Thanks for asking the question this way. One of the things I took away from the virtual interim meeting on multipath, was that at least some of us have been talking about a general-purpose multipath solution, but the use cases presented at the virtual interim were different enough that we might need more than one multipath solution. Some of the use cases we talked about seemed to assume deep knowledge of applications and of path characteristics, that would be difficult to meet with a general-purpose multipath solution. Something like https://datatracker.ietf.org/doc/draft-huitema-quic-mpath-option/ might be all that they need. Other use cases, especially the ones involving bandwidth aggregation, might be a better fit for a general-purpose multipath solution. But the point is, we don't know yet. So having a place that interested parties can continue to discuss "multipath" seems most important. So, I think the "how much protocol we need to figure out how multipath could work" formulation I suggested to Martin is a reasonable proposal here. > >> - 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 trust the working group chairs to rate-limit adoptions in the QUIC working group. Looking back, we didn't even adopt draft-pauly-quic-datagram-00, submitted in 2018, as a working group item until February 2020, so I think everyone understands that the QUIC community has to have room for new work, for it to move forward. > 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? > As above - I think getting and understanding deployment experience with "existing multipath mechanisms in QUICv1", which I'm reading as "connection migration", to be a really important part of this discussion. I honestly suspect that will meet the needs of many, but not all, use cases. As an aside - I submitted a quick -00 draft from the Github repo at https://github.com/SpencerDawkins/draft-dawkins-quic-what-to-do-with-multipath on Monday (I-D cutoff), and posted a pointer on this mailing list, but I've continued typing, and the current version in the repo now says this in Section 2.2.4. One important output from the QUIC interim meeting was the recognition that some participants view "Traffic Switching" as something like "protection switching" from an active path to a standby path, that doesn't happen often, while other participants view QUIC connection migration as a way of responding frequently to changing path conditions. This will be an important part of the conversation about multipath QUIC. If a QUIC endpoint opens and validates two or more connections, no additional setup or signaling is required for a sender to switch paths - that can begin with the next packet queued for transmission. This would allow "Traffic Splitting" for unordered QUIC datagram packets [I-D.ietf-quic-datagram], with an upper-layer mechanism providing flow ordering if that is needed. That's an example of the kind of discussion I'm hoping that we continue to have. Again, thanks for your thoughts. I find them very helpful. Best, Spencer p.s. Issues and PRs are, of course, welcomed in https://github.com/SpencerDawkins/draft-dawkins-quic-what-to-do-with-multipath ... > - jana >
