Options for QUIC Multipath

[Christian Huitema <[e-mail]>]

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