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

[Ian Swett <[e-mail]>]

Christoph, thanks for the great information.

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?

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

On Fri, Oct 2, 2020 at 8:53 PM Lucas Pardue <[e-mail]>
wrote:

> Hey,
>
> On Sat, 3 Oct 2020, 01:09 Christoph Paasch, <[e-mail]> wrote:
>
>> Hello Lucas,
>>
>>
>> "could hurt end users", you mean consume significant cellular data? Or do
>> you mean hurt performance?
>
>
>> If it is the former, I agree. And that's why the client should not
>> establish
>> a uniflow unless it actually is willing to receive data on that uniflow.
>>
>
> Yes I meant this former case. And by using the term end user I was very
> much channeling RFC 8890.
>
> I doubt there is a specific reason on why the MP-QUIC draft does not have
>> such an "MP_PRIO"-concept. In any case, that would be a minor point that
>> can
>> easily be added.
>>
>
> Thats a good suggestion, I think adding something on this would help.
>
> Cheers
> Lucas
>
>
>>