Re: Heads up -- unifying of multipath options.

[Dave Taht <[e-mail]>]

I endorse all michael's points below.

On Mon, Jun 13, 2022 at 6:33 AM Michael Eriksson
<michael.eriksson=[e-mail]> wrote:
>
> Hi Christian,
>
> Thanks for progressing this!
>
> Single vs multiple packet number spaces
>
> I used to think that a single packet number (PN) space was a cleaner and simpler solution, partly because of less difference with singlepath QUIC. A later insight is that this is mainly an issue if you add multipath to an existing singlepath stack. With a stack designed for multipath from the beginning, multiple PN spaces actually seem more straightforward and efficient. With a careful design of multiple PN spaces, there is very little difference between a singlepath connection and a multipath-enabled connection that only uses one path.
>
> Additionally: At Ericsson Research, we have Rebecka Alfredsson finishing her M.Sc. thesis and prototype of multipath QUIC hardware offload. During that work, we have realized that multiple PN spaces are more or less needed for multipath QUIC offload. The reason is the compressed packet numbers, holes in the packet number sequence makes it difficult to expand the packet number on the receiving side.
>
>
> Both single and multiple packet number spaces
>
> What you suggest is to use both single and multiple PN spaces, which I think is a mistake. The main reason is the increased complexity and double implementation.
>
>
> Zero-length connection identifiers
>
> The stated need for a single PN space is to support zero-length connection identifiers (CIDs). I think that multiple PN spaces can be used also for zero-length CIDs if the IP address and port number ("socket" in practice) is used for demultiplexing on the receiver side.
>
> Zero-length CIDs are very seldom, if ever, used on the server side. The client will normally use separate local network interfaces (e.g., cellular and Wi-Fi) for the different paths, and thus have separate sockets for the different paths anyway. The server can handle a NAT rebinding, since the different paths are separated by the connection ID and the event is handled as in RFC 9000 (i.e., path validation).
>
>
> Path Identification
>
> Each path needs to have an identity for mainly two reasons:
>
> to refer to the path in signaling frames, e.g., PATH_ABANDON.
> to avoid reusing encryption nonces when using multiple PN spaces
>
> The current draft uses the destination CID sequence number to create the nonce. Since zero-length CIDs don't have sequence numbers, they can't be used with multiple PN spaces.
>
> I suggest that the sequence number of the server's CID is used to identify the path in both directions, including for nonce generation. This has two direct advantages:
>
> It allows multiple PN spaces for zero-length CIDs on the client side
> The path has the same identity in both directions, which reduces the complexity and risk for errors
>
> "PN Space ID" should be removed from the specification and Path ID used everywhere.
>
>
> Summary
>
> I suggest that only multiple PN spaces are used for multipath QUIC. I have shown how zero-length CIDs can be used on the client side and argue that they will not be used on servers anyway.
>
>
> /me
>
> ________________________________
> From: Christian Huitema <[e-mail]>
> To: mailing-lists.ietf.quic
> Subject: Heads up -- unifying of multipath options.
> Date: Thu, 9 Jun 2022 06:30:29 +0200 (Central European Summer Time)
>
> When we presented the work on QUIC multipath at the last IETF, we provided two options: one in which there is a packet number space for each path; and one in which there is a single number space. The high level summary is that the "number space per path" option allows for more precise management of packet loss recovery and congestion control, while the single number space option also works well if one of the peers use zero-length CID. The authors believe that we can "unify" the two options, as explained in the PR https://github.com/quicwg/multipath/pull/103.
>
> The PR essentially proposes to use the "packet number space per path" option when both peers generate non-zero-length connection ID, but to fall back to the "number space per path" option for managing packets sent with a zero-length CID and their acks. That, plus a number of nice provision to control code complexity. The issue was discussed on this list, in WG meetings, and on Github. We know that many WG members care about multipath and have either preferences for one or the other option, or maybe opinions about how soon we need to converge. It would be very nice if we heard opinions quickly, and even better if those opinions came before the draft submission cut-off date!
>
> -- Christian Huitema
>


-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC