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 ([email protected]) 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
