Re: Multipath (was: Re: Re-chartering for extension work)

[Olivier Bonaventure <[e-mail]>]

Lars,

> 
> On 2019-12-13, at 20:05, Olivier Bonaventure <[e-mail]> wrote:
>> Do you have any specific plans for the multipath work ?
> 
> thanks for reminding us about that! There is of course no intention of dropping the multipath work item from the charter. It's already in the charter and will remain there, so it's not affected by this rechartering.
> 
> (One could call multipath an extension and mention it alongside the others in the modification that Mark posted in the first message of this thread. Personally, I see it as a much more fundamental - and difficult - update to the base protocol, and therefore would keep it highlighted in the way it currently is in the charter.)
> 
> I think we'll be ready to start having discussions on multipath in parallel to working on these new extensions; I do expect the multipath work to progress at a slower pace, however. While we don't have to start at zero thanks to MPTCP, 


We can leverage many of the lessons learned from the design and the deployment of Multipath TCP into MPQUIC. 

When Multipath TCP started, multipath congestion control was a challenge, this problem has been solved with different coupled congestion control schemes. 

With Multipath TCP, we had to struggle a lot with middleboxes and how they interfere with TCP and Multipath TCP. QUIC avoids these problems and makes the design more simple and more flexible. There are many problems that exist in MPTCP that disappear in MPQUIC. For example, in MPTCP, data sent over a subflow must still be retransmitted over this subflow even if it has already been acknowledged over another subflow at the data level. With MPQUIC, once data has been acknowledged on a path, it never needs to be retransmitted again. Another example are the selective acknowledgements. In TCP, the length of the (MP)TCP header restrict the number of blocks that they cover. In MPQUIC, we do not need to deal with this problem...

> hard challenges remain (e.g., when pooling capacity, can we do it in a way that doesn't leave us operating near the max. RTT of the paths?)

With MPQUIC, we are not as constrained as with MPTCP for the transmission of acknowledgements. This means that when pooling capacity it is possible to send acknowledgements on a different path than the one used for the data. This would be difficult in an MPTCP implementation but is easy in MPQUIC. 

As QUICv1 is now getting stable, it makes sense for the working group to adopt an initial design for multipath QUIC and then improve it.


Olivier




-- 


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