Two replies inline. On Tue, Sep 29, 2020 at 1:12 PM Olivier Bonaventure < [email protected]> wrote:
> Spencer, > > > > On Fri, Sep 25, 2020 at 5:00 AM Lars Eggert <[email protected] > > <mailto:[email protected]>> wrote: > > > > In parallel to progressing the "base drafts" towards RFC > > publications, the WG should now also begin to pick up the pace on > > our other adopted work items (ops drafts, extensions, etc.) > > > > One important other discussion item is what to do about the > > multipath extension milestone, which some have suggested should be > > dropped, while others still show interest to pursue it. > > > > > > So, I'd like to understand the suggestion to drop this milestone, before > > I start trying to discuss that suggestion :-). > > I'd like to understand this as well. > I want to echo Jana's reply from the original discussion here <https://mailarchive.ietf.org/arch/msg/quic/R-uJhzzXBz-93OTmYupXu8ooJdA/>. Everyone agrees multi-path transports are an interesting problem, and IETF participants love to solve interesting problems. It's not clear, however, that it should be a primary milestone of the working group at this time. > > > > In conversations with individual folk, I've heard these concerns about > > QUIC multipath: > > > > - Whether it will be possible to evaluate multipath performance at > > scale, both for evaluating proposals and testing implementations. > > We already have plenty of experience with MPTCP with several large > deployments, including : > > - MPTCP on all iPhones since 2013 with a growing number of applications > - MPTCP on Android smartphones in South Korea for WiFi/4G offload > - MPTCP in hybrid access networks that are used by different network > operators to combine xDSL and LTE > > Multipath extensions to QUIC would be applicable in these different use > cases > There is a difference between "Someone is doing these things with MP-TCP", and "Someone has shown interest and intent in doing these things with MP-QUIC". Additionally, the first example can, as I understand it, largely be replicated with QUIC connection migration. The other two I would like to hear more about, because it would surprise me if they amounted to a significant deployment. Support for MP-TCP in Android is virtually nonexistent, for example. We have deployment experience with pre-IETF QUIC, and growing deployment experience with IETF QUIC itself. However, even things like connection migration in the base drafts have been fully exercised in the real world yet. As far as I know there have not been any major implementers or "championing" applications showing a lot of interest in deploying MP-QUIC in the near future, with the exception of the 3GPP's desire to integrate it into the ATSSS specification. As I understand it, this interest does not in itself even imply a deployment in the near future. I would rather we not endeavor on tackling what is certainly going to be a difficult design problem simply under the hope that "If you build it, applications will turn up". > > > - The complexity involved in making decisions dynamically about which > > path to send a given packet on (which could be a research topic, given > > certain constraints and goals). > > The packet scheduling problem is a much simpler problem in multipath > transport protocol than congestion control. I would not consider this as > a research topic given all the experience we have with MPTCP > > > If I've misunderstood or misquoted, my apologies, of course. Please > > correct me. > > > > What other concerns do people have? I'd like to get all the objections > > out at the beginning of the discussion. > > Same for me > > > Olivier > > Matt Joras
