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

[Florin Baboescu <[e-mail]>]

Dear all,



I would like to support Olivier’s request that “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”.

While it is easy to agree with Jana’s comment that “There will be quite
some heavy lifting to do if we go down the path of designing a multipath
extension for QUIC” one can definitely not ignore 1) the experience gained
through the MPTCP work as well as 2) the fact that QUIC simplifies the
design and makes it more flexible than in the case of MPTCP.

With regard to Jana’s comment that “I would also like to see
implementations that are keen to build it if an extension were to be
developed, and applications that will use it” I would like to point out the
followings:

1.       In 3GPP Release 16, MPTCP has been adopted as a solution for
Access Traffic Steering, Switching and Splitting(ATSSS) support in the 5G
System architecture.

2.       In 3GPP Release 17 (to be completed by December 2020) a large
number of companies would like to be able to complement the solutions
adopted in Release 16 with a MPQUIC based solution if available. These
companies represent handset vendors, operators and network vendors.

This is why it is easy to say that we do see a very strong need and
interest in this work and we would like to support it.

Thank you.

-Florin





*From:* QUIC [mailto:[e-mail]] *On Behalf Of *Jana Iyengar
*Sent:* Tuesday, December 17, 2019 10:26 PM
*To:* Christian Huitema <[e-mail]>
*Cc:* Olivier Bonaventure <[e-mail]>; Quentin De
Coninck <[e-mail]>; Mark Nottingham <[e-mail]>;
Lars Eggert <[e-mail]>; Mikkel Fahnøe Jørgensen <[e-mail]>;
IETF QUIC WG <[e-mail]>
*Subject:* Re: Multipath (was: Re: Re-chartering for extension work)





I'm not sure that this is the time for this conversation, but I'll share my
thoughts since the question has been raised.



There will be quite some heavy lifting to do if we go down the path of
designing a multipath extension for QUIC. We've seen this before. I worked
on multipath for SCTP, which was quite some work. I remember when we
started work on MPTCP at the IETF in 2009, and it was a lot more effort
than most people anticipated. When we started work on connection migration
for QUIC, we thought it might get done relatively quickly, but it was a
feature that kept on giving.



None of this is to say that we shouldn't take on a hard problem, but before
we start sliding into it, I would like to be convinced of its importance.
We already have connection migration in the core drafts, and I'd like to
see an articulation of the problems that multipath would solve in addition
to basic migration. I would also like to see implementations that are keen
to build it if an extension were to be developed, and applications that
will use it. Without those, we would be putting the cart before the horse.



- jana



On Mon, Dec 16, 2019 at 12:52 PM Christian Huitema <[e-mail]>
wrote:



On 12/16/2019 9:20 AM, Mikkel Fahnøe Jørgensen wrote:

If you can observe encrypted traffic on both paths you have an opportunity
to correlate traffic if an endpoint consistently acks on one path and sends
on another. On path has small packets a fixed interval after larger packets
on the other paths. That could happen in a migration scenario where one
path is not yet fully committed so ACKs stay on the main path.



I don’t recall how it works today with single path migration, but I think
that it is required that ACKs happen on the same path as the packets on
which they are sent.



No, that's not required. In fact it cannot be required, because one of the
scenarios is "transmit some data on path X, then migrate to path Y". If you
don't ack on path Y for packets sent on path X, you end up having to repeat
these packets on path Y.

But your general point is correct, Mikkel. If application traffic is spread
over multiple paths, it is probably hard to hide the correlation between
these multiple paths. Not necessarily impossible, but if this is a goal we
have better design for it.

-- Christian Huitema