Hello, to answer Ian's question regarding Multipath:
We (Apple) are using both Wi-Fi and Cell simultaneously for a number of use cases. The scheduling decision is different for each of the use cases based on policy, quality of experience requirements and traffic patterns. Our different scheduler modes (handover, interactive and aggregate) are described in [1]. For Siri, we send traffic on Wi-Fi and Cell simultaneously depending on the latencies of each path, using the MPTCP interactive mode [1]. This per-packet scheduling allows it to have the best latency across Wi-Fi and Cell. Wi-Fi/Cell latency can have huge short-term variances due to signal-strength, at very short time scales. A pure migration solution would not allow for a quick reaction on those time scales. Apple Music uses Wi-Fi and Cell simultaneously whenever the need arises where Wi-Fi signal is not strong enough. As music streaming can potentially consume significant amounts of data, it is important to keep cellular data usage to a strict minimum, and here it uses the MPTCP aggregation mode [1] only when necessary to ensure a smooth music playback. A migration-based solution would instead be a hard handover to cellular. This could consume significantly greater amounts of cellular data (with all the costs that entails), while simultaneously being very dependent on the good quality of the cellular access. Considering the benefits of using multipath for these use cases and the work involved for the IETF to standardize MP-QUIC, I believe that the QUIC Working Group should add MP-QUIC to the charter as a deliverable. Otherwise, there will always be situations (like the above) where QUIC migration will not be satisfactory in bad network environments. In those situations, one must be able to leverage multiple paths simultaneously to get the best of them. Keeping the complexities of packet scheduling and path management out-of-scope is a good idea, as both are generic research questions that have already seen significant work as part of MPTCP and will still be worked on - similar to QUIC's stance on more sophisticated congestion controllers. [1] https://developer.apple.com/documentation/foundation/urlsessionconfiguration/multipathservicetype Christoph On 09/30/20 - 12:12, Ian Swett wrote: > I'm very receptive to Jana's arguments, but I think it's also worth > understanding how much work we believe this will be for the QUIC WG. > > Many fairly complex multipath problems have already been dealt with by > supporting connection migration in QUIC v1, such as path validation and > linkability between flows. Multiple packet number spaces during the > handshake means that implementations already have some ability to have > multiple loss recovery contexts, though they may not be easily adaptable to > multipath. > > Scheduling seems like a big problem, but it's not clear to me that the QUIC > working group should be attempting to solve that. I'd argue we should make > that explicitly out of scope if we took on this work. > > The existing draft(draft-deconinck-quic-multipath-05 > <https://tools.ietf.org/html/draft-deconinck-quic-multipath-05>) adds > ADD_ADDRESS/REMOVE_ADDRESS frames and modifies the ACK, NEW_CONNECTION_ID, > and RETIRE_CONNECTION_ID frames. It also adds what appears to be a > debugging frame(UNIFLOWS) and a single transport parameter to indicate > support and indicate the max number of uniflows. Having sets of CIDs per > path seems an unfortunate complication to me, but I haven't thought about > it enough. The two new frames and modifications to the ACK frame are > simple enough. > > Is there MORE work QUIC WG would have to do than what's described in the > draft? If so, can people outline that work? > > I certainly think MP-QUIC is a cleaner solution than MP-TCP. > > I lean towards keeping multipath in scope, and I'd be willing to spend time > improving a proposal if it was adopted. One reason is that I never want to > be forced to support MP-TCP because there is no MP-QUIC. I also don't > think this has to be designed with HTTP in mind, even if that was the focus > of QUIC v1. MASQUE/VPNs are a more compelling use case to me. > > Ian > > PS: It'd be good if someone from Apple could share their perspective on > whether MP-QUIC is necessary, since they have quite a bit of experience > with MP-TCP. > > On Tue, Sep 29, 2020 at 4:31 PM Matt Joras <[email protected]> wrote: > > > 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 > >
