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