I authored two drafts proposing two different solutions for Multipath
QUIC: QUIC Multipath Negotiation Option
(https://datatracker.ietf.org/doc/draft-huitema-quic-mpath-option/);
and, in collaboration with colleagues at Ali Baba, Multipath Extension
for QUIC (https://datatracker.ietf.org/doc/draft-liu-multipath-quic/).
Apart from some details that could easily be aligned, the main
difference is that the “negotiation option” maintains the property of
QUIC Transport
<https://datatracker.ietf.org/doc/draft-ietf-quic-transport/> to have a
single packet number space for all application packets while the
“multipath extension for QUIC” specifies that there will be a specific
packet number space for each path. I have now implemented both options
in Picoquic. This blog describes what I learned:
https://huitema.wordpress.com/2021/02/14/how-many-packet-number-spaces-for-quic-multipath/.
To summarize, I believe now that both options work. The simple option
requires some additional work for managing acknowledgement, but the
multiple number space option adds a lot more complexity (41 new code
branches compared to only 6), and will require a lot more testing
because it also change the processing of the "single path" scenarios.
The multiple number space option also prevents the use of zero-length
connection IDs, and thus causes additional overhead in some important
deployment scenarios. So, yes, both options work, but the simpler option
provides simpler code and also less overhead.
In any case, I hope that this exercise will inform our efforts to
standardize multipath support in QUIC.
-- Christian Huitema
- Options for QUIC Multipath Christian Huitema
-
