Thanks to a joint effort of all previous multipath QUIC drafts, the common draft focusing on core Multipath QUIC has been adopted by the IETF QUIC Working Group. While authors agree on most of its core components, there remain discussions about the number of packet number spaces that a Multipath QUIC connection should use.
There are two divergent viewpoints about this. The first solution consists in reusing the same application packet number space over paths. With a single packet number space, we can send packet N on a given path, and then packet N+1 on another. Such an approach does not require much changes on a QUIC implementation to make it use multiple paths simultaneously, as regular ACK frames can acknowledge packets received on several paths. However, there is a concern about the size of the acknowledgements that would be generated when using paths exhibiting different latencies.
The other solution consists in dedicating an application packet number space per path. When using multiple packet number spaces, there is no more packet number gaps over a given path, as each path will use packet numbers 1, 2, 3,.. independently of the others. Hosts can identify the path used thanks to the Connection ID contained in the QUIC header, enabling the receiver to differentiate two packets having the same number. This design requires more code changes than using a single packet number space. Besides introducing a path specific version of the ACK frame (ACK_MP), implementations need to adapt their nonce computation to avoid packets over different paths sharing a same number to use the same cryptographic nonce.
To address this discussion, we recently wrote an ArXiv technical report exploring the performance of two different implementations, whose one supports both designs, in many network scenarios under a NS3 environment. Our results suggest that while both approaches work to make QUIC simultaneously use several paths, the single packet number space design is more sensitive to the receiver’s behavior, i.e., the performance of the transfer is dependent on how the receiver generates ACK frames.
The ArXiv technical report is available at https://arxiv.org/abs/2112.01068.