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 <[email protected]><mailto:[email protected]>
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
