Re: What to do about multipath in QUIC

[Yanmei Liu <[e-mail]>]

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