Re: What to do about multipath in QUIC

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

Hi Yanmei Liu

I think this sounds like a good approach. It takes all the work an
application would otherwise have to do and hides the complexity, without
completely introducing a lot of new protocol complexity. This allows an
application to open a stream and keep working on it regardless of which
connections are currently alive.

I wonder if there are cases where this is a bit too heavy. For example
handshakes could perhaps be simpler on secondary connections.

Also I wonder about privacy. For example if it is easy to detect that to
concurrent connections belong to the same endpoint, fingerprinting might be
easier. I guess that would always be a problem for MP.

There are also subtleties such as idle-timeout. What if each connection has
a different timeout, is it only the sub connection that dies, or the entire
connection?  There could even be a case where connections remain alive
without any currently open sub-connection in order to deal with aggressive
NAT gateways etc.

If secondary handshakes get simplified, I suspect it is more of an
implementation whether to see it as sub-connections, or just protocol
messages on different paths.

- Mikkel

On 12 November 2020 at 11.48.50, Yanmei Liu ([e-mail])
wrote:

Hi Lucas,

> >
> > You are right, connection migration is the weakest form of multipath.
> >
>
> Thanks. We heard use cases that would like stronger forms. I think it will
> help continue to move the discussion forward if we can establish some
> common ground on terms and capabilities.

I
strongly agree that we need to establish some common ground on terms
and capabilities,
so I’d like to explain some design considerations in [draft-an-multipath-quic](
https://tools.ietf.org/html/draft-an-multipath-quic-00
), and we hope to get more feedbacks.

> >
> >     However, to the network layer, each MPTCP subflow looks
> >     like a regular TCP flow whose segments carry a new TCP option type.
> >     Multipath TCP manages the creation, removal, and utilization of these
> >     subflows to send data.  The number of subflows that are managed
> >     within a Multipath TCP connection is not fixed and it can fluctuate
> >     during the lifetime of the Multipath TCP connection.
> >
> > This is not really connection migration and MPTCP provides much more
> > multipath capabilities than connection migration.
> >
>
> Yeah I follow. As someone coming from QUIC, the first sentence is kind of
> easily negated (which is a benefit IIUC). I think the remainder of the
> paragraph is partially satisfied by QUIC v1 if we consider
> PATH_CHALLENGE/PATH_RESPONSE and NEW_CONNECTION_ID/RETIRE_CONNECTION_ID.
> But it starts to fall apart when you want to do more complicated things. I
> think understanding the gaps in the transport signalling would be useful to
> document in isolation to any specific solution.
> draft-deconinck-quic-multipath has done some of that work already but it
> gets a little too tied up with the solution IMO.

  1. We think QUICv1 has already laid down the foundation to build a
general-purpose multi-path since migration can be viewed as a special
type of multi-path. Therefore, we think one should reuse the design of
migration in QUIC-v1 as much as possible, along with the features such
as PATH_CHALLENGE/PATH_RESPONSE for path challenge and address
validation, and NEW_CONNECTION_ID/RETIRE_CONNECTION_ID for CID
renegotiation of new path(which is called Sub-connection in our
draft). Reusing these features of QUIC-v1 with small extensions has
enabled us to get general-purpose multi-path features with very little
efforts in
Alibaba’s XQUIC(an implementation of QUIC-v1).
  2. We find that the simplest way to add a second path is to use a
sub-connection. The concept of sub-connection is directly inherited
from connection in QUIC-transport, defined as the logic session of
each physical path. Similar to a connection, each sub-connection has
its own packet number space for the purpose of loss detection and
recovery.
  3. To merge the gap between migration and the general-purpose
multi-path, several new features need to be supported:
  - (1) how to manage the lifecycles of individual sub-connections.
  - (2) how to distinguish packets coming from different sub-connections.
  - (3) how to co-operate with a multi-path scheduler.

We would appreciate hearing any thoughts, comments and suggestions.


Thanks,
Yanmei