Re: Multipath

[Olivier Bonaventure <[e-mail]>]

Gorry,
>> 
>>    A second use case is for mobile devices that need to preserve
>>    connectivity while switching from one wireless network to another.
>>    When such a device detects another wireless network, it needs to
>>    bet whether migrating the connection to the new network would
>>    improve performance. With a multipath transport, there is no need
>>    to bet as the transport will automatically select the best
>>    performing network. Apple’s deployment of Multipath TCP is a good
>>    example of the benefits of such a multipath strategy.
>> 
>> 
>> FWIW, QUIC connection migration was designed to do explicitly this and has been very successful in Google's deployment. I don't think this is a good justification for multipath QUIC.
>> 
>> Cheers,
>> 
>> Ryan
> 
> Just as an observation - It seems you can design connections:
> 
> (1) to survive rebinding here you expect normally the same path (or set of devices on path),
> 
> (2) to fail-over between different paths where you expect diverse characteristics -  SCTP separated path fail-over (a standardised feature)
> 
> and (3) to do multi-path sharing (not currently in the RFC series) - where you may wish to schedule to minimise delay; maximise throughput; optimise for some other metric.
> 
> 
> I can see merit in acquiring experience that migration works well in the first and second case before starting on scheduling/cross path sharing.


The MPTCP deployments on various smartphones bring lot of operational experience on the benefits of using multipath transport to support (1) and (2). The  hybrid access networks that use MPTCP to combine xDSL and cellular to provide fast broadband services also provide a lot of operational experience with (3). These lessons can be leveraged in multipath QUIC as well.


Olivier
-- 


Disclaimer: https://www.tessares.net/mail-disclaimer/ 
<https://www.tessares.net/mail-disclaimer/>