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
