I disagree with all these efforts to reinvent mpquic. mpquic has already been specified we do have a draft which has already been revised several times. Why not revise that further to make it "prefect"?
I also suggest changing the name from mpquic which is too much TCP-oriented to Multiple Interface QUIC or MIQUIC (a little bit of Spanish :)). Behcet On Thu, Nov 12, 2020 at 11:05 AM Christian Huitema <[email protected]> wrote: > > On 11/12/2020 3:10 AM, Mikkel Fahnøe Jørgensen wrote: > > 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). > > Yes. That's a major investment in QUIC V1, and we should keep it. > > 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. > > > I did not want to do that in my own draft for a couple of reasons. The > main one is the interaction with encryption. > > The use of AEAD is only safe if the same packet number is not reused twice > with the same key. If we use multiple packet number contexts, AEAD is only > safe if these contexts use different encryption keys. This requires adding > a key derivation procedure for the "sub connection", and also adding ways > to identify the relevant key in the incoming packets. This gets complicated > very quickly, especially if we want to keep the possibility of using > zero-length connection identifiers on the client side. > > I use a concept very similar to the sub-connection, but only as a way to > manipulate paths, so the client can instruct the server when paths ought to > be abandoned. Otherwise, I just keep track of which PN maps to which path. > > > 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. > > > I think we need more work on the "multi-path scheduler". We have heard of > three application scenarios: maintaining the lowest RTT when sending voice > segments (Apple Siri), avoiding buffering delays when playing music (Apple > Music), and using two available links with equal preference (Ali Baba "high > speed train"). I wish that we could distillate that into a couple of simple > concepts. > > -- Christian Huitema > >
