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

[Mikkel Fahnøe Jørgensen <[e-mail]>]

ACK across paths could lead to privacy leaks, no?

Mikkel

On 16 December 2019 at 13.13.47, Olivier Bonaventure (
[e-mail]) wrote:

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