I endorse all michael's points below. On Mon, Jun 13, 2022 at 6:33 AM Michael Eriksson <[email protected]> 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 <[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 >
-- FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/ Dave Täht CEO, TekLibre, LLC
