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

[Tommy Pauly <[e-mail]>]

> On Oct 4, 2020, at 7:56 AM, Ian Swett <ianswett=[e-mail]> wrote:
> 
> Is the lack of MP-QUIC likely to cause QUIC to be disabled for certain key use cases(ie: Siri and Apple Music), or can existing connection migration be made to work?

Since multipath support has proved to be a key part of optimizing performance for services like Siri and Apple Music, we wouldn’t plan to move Siri or Apple Music off of MPTCP onto QUIC until QUIC has support for “full” multipath. (This of course doesn’t affect adopting QUIC for applications that don’t use MPTCP to start with.)

Thanks,
Tommy

> 
> For example, I can imagine working around true multipath by only using one path at once, but sending PATH_CHALLENGE on the other path to probe reliability and/or RTT.  Or even sending identical packets(ie: a request) on both paths and the receiver will naturally respond on the path the packet is received first and drop the other packet as a duplicate.
> 
> My key takeaway from the multipath scheduler papers I've read is that most of the performance gains are obtained by always sending on the faster of the two available paths, and in a large set of circumstances, nothing should be sent on the slower path.
> 
> Thanks, Ian
>