That's great to hear, I'm glad you have proven the idea with implementation experience. This removes a downside of the existing multipath design I hoped would not be required.
Ian On Fri, Nov 18, 2022 at 1:00 PM Michael Eriksson <michael.eriksson= [email protected]> wrote: > Greetings fellow multipathers, > > *TL;DR*: Contrary to common belief, it is possible to use multipath with > client-side zero-length connection identifiers and multiple packet number > spaces. We have proven this with a prototype. > > > > > *Introduction *In the QUIC multipath community, it is common knowledge > that it is impossible to use client-side zero-length connection identifiers > (CIDs) with multiple packet number spaces. This is unfortunate, as it is > not true. > > A small adjustment to the current multipath draft will allow the use of > zero-length CIDs on the client side. The mechanism for it has been > suggested multiple times, for instance by Ian Swett at IETF 115. This > message is an attempt to flesh out the details to get a better multipath > protocol without artificial limitations. Feedback is more than welcome. > > > *Design* > > The main idea is that every path has a single numerical identifier that is > used in both direction. The numerical value is the sequence number of the > CID used by the client to create the path. The path identifier is used for > generating the encryption nonce in both directions, and also to refer to > the path in signaling in, e.g., ACK_MP and PATH_ABANDON frames. The server > can generate the correct decryption nonce for the initial path setup > packet, as it recognizes the CID it has issued and can determine its > sequence number. > > On the server side, the path is recognized by the CID. On the client side, > the local IP address and UDP port number is used to separate paths. > > If the server-side CID is changed (IIUC, that is currently impossible as a > new CID will create a new path according to the current multipath > semantics), the path would still keep the same identifier. > > There are some additional advantages with this design, beyond the support > for zero-length CIDs: > > - The implementations can be simpler, when there is no need to keep > track of two different identifiers for the same path > - It simplifies logging/tracing when a path has the same identifier in > both directions > > > > > *Will it really work? *Yes, we have verified that with an > Ericsson-internal multipath QUIC prototype. > > > > > *Summary *The multipath specification should be updated according to the > path identifier design described above. It will enable zero-length > client-side connection identifiers and also make the implementations > slightly simpler. > > > /me >
