OK, first some meta-discussion. A little background: I am so far an IETF tourist (but a few of my colleagues at Ericsson Research are pretty well established). I am in this working group mainly to try to contribute to a good multipath QUIC protocol.
The current version of the multipath draft describes two different solutions, single or multiple packet number spaces. It also says "More evaluation and implementation experience is needed to select one approach before final publication", which is excellent. For a layman, it's hard to understand how "we" got from there to having perceived consensus for a new, third, solution. Additionally, I really don't want to be seen as a last-minute troublemaker who is delaying a useful protocol, that has not been my intention. ...and now for something completely different: technical stuff. I have convinced myself that a multiple packet number (PN) space solution is the best, but think it would be great if we could understand the single PN space option better. You claim that a single PN space makes hardware offload easier, which is against my understanding after having supervised Rebecka Alfredsson's master thesis project on hardware offload for multipath QUIC. As I wrote in a previous message, receive-side hardware offload needs to expand the received compressed packet number to a full packet number to be able to decrypt the packet. This is hard to do if there are holes in the packet number sequence, which will happen if you have a single PN space. To be explicit, different paths can arrive on different offloading NICs or be handled by different threads due to load-balancing mechanisms similar to receive-side scaling (RSS). The same problem could affect more abstract designs, such as those based on P4. It would be good to understand how the "ACK inflation" can be handled in a good, simple and efficient way, since a single PN space will lead to a lot of ACK ranges. Preferably, a specification of a single PN space solution should give some implementation guidance (just like RFC 9002 does for loss detection etc). /me ________________________________ From: Christian Huitema <[email protected]><mailto:[email protected]> To: Michael Eriksson <[email protected]><mailto:[email protected]>, Yanmei Liu <[email protected]><mailto:[email protected]> Cc: IETF QUIC WG <[email protected]><mailto:[email protected]> Subject: Heads up -- unifying of multipath options. Date: Wed, 15 Jun 2022 21:37:20 +0200 (Central European Summer Time) On 6/15/2022 12:07 PM, Michael Eriksson wrote: > In my response to Christian Huitema, I suggest a design that fully supports > client-side zero-length connection IDs but only uses multiple PN spaces. In > addition to (noticeably) reduced complexity, it has these advantages: > > 1. Support for full use of ECN also for paths with zero-length connection > IDs > 2. Enabling (or at least simplifying) hardware offload when using > zero-length connection IDs This discussion makes me wonder whether we have consensus for a unified multipath option. The authors believe that we do, but Michael clearly does not believe it. If we go back to the drawing board, then another unified option is possible, centered on the "single space" option. It would require adding a "path report" frame to convey congestion control information for the path, something like: PATH_REPORT { path_identifier, time stamp(i), last received time stamp on path(i), delay since last time stamp(i), ECN Counts (..) }ive us lots of benefits compared to the current solutions: * easier hardware offload, as there is only on number space and one encryption context, * keep using 64 bit nonce, removing the need for multipath-specific 96 bits nonce and new APIs, * solve the "rtt per path" measurement issue, * solve the "ECN per path" measurement issue, * full support of zero-length CID, * remove the interaction between CID and number space, no need to start a new number space on NAT rebinding or CID renewal, * common code for unipath and multipath, * and of course, single multipath option. Maybe we should investigate that. -- Christian Huitema
