Re: Multipath with zero-length connection identifiers

[Ian Swett <[e-mail]>]

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=
[e-mail]> 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
>