Re: Preparing for discussion on what to do about the multipath extension milestone

[Olivier Bonaventure <[e-mail]>]

Matt,
>      >
>      > On Fri, Sep 25, 2020 at 5:00 AM Lars Eggert <[e-mail]
>     <mailto:[e-mail]>
>      > <mailto:[e-mail] <mailto:[e-mail]>>> 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.

I think that the main question is whether the working group wants to 
have a generic transport protocol which can support a variety of 
applications or wants a transport that is only tuned to the requirements 
of HTTP. Given QUIC's architecture and clean design, it is possible to 
do a generic and future proof transport that includes clean multipath 
support that is much better than MPTCP.
> 
>      >
>      > 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. 

With connection migration, QUIC has roughly the same features as SCTP's 
failover mechanism. Connection migration is a nice feature when you have 
a clear indication that one path has failed and thus move to another 
one. However, the experience reported by Apple with MPTCP on iPhones 
shows that there are many situations where the selection of one 
interface over the other is not a binary decision. When users walk, 
there are many cases where both cellular and WiFi need to be used in 
parallel for some period of time (seconds or tens of second) to achieve 
good quality of experience while none of the networks is perfect. During 
these periods, being able to send data over two paths is key.

> 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.

For the second use case, the GigaLTE service was presented by KT in the 
MPTCP working group. AFAIK, a similar service has been deployed by other 
operators in South Korea. Several smartphone vendors (Samsung, LG 
notably) have ported the off-tree Multipath TCP kernel patches on their 
high-end smartphones to support this service. Huawei has also announced 
some MPTCP-enabled smartphones and one CDN service using MPTCP in China.
There is an ongoing effort that involves Redhat, intel, Apple, Tessares 
and others to rewrite MPTCP in the mainline Linux kernel. There have 
been several presentations about that at netdev.

The third use case is deployed in several countries to combine xDSL and 
LTE to provide fast broadband services in rural areas. There are several 
references on wikipedia
  https://en.wikipedia.org/wiki/Hybrid_Access_Networks

> 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. 
When MPTCP started within the IETF, there was no major deployment and no 
experience with a pre-IETF version. This did not prevent the MPTCP 
working group to design a protocol that has been widely deployed.

> 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".

Given the experience that we already have with MPTCP, I don't consider 
the multipath extensions to QUIC as a difficult design problem. In 
MPTCP, the main problems were middlebox interference, this does not 
exist with QUIC. The MPQUIC design that was initially proposed by 
Quentin De Coninck in 2017 has been updated to take into account the 
evolution of QUIC within the IETF. The changes made to QUIC have made it 
easier to support multipath capabilities, see
https://datatracker.ietf.org/doc/draft-deconinck-quic-multipath/

There is also running code inside pquic which is a fork of picoquic
https://github.com/p-quic/pquic


Olivier