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