Re: Options for QUIC Multipath

[Behcet Sarikaya <[e-mail]>]

On Sun, Feb 14, 2021 at 4:23 PM Christian Huitema <[e-mail]>
wrote:

> 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.
>


Great!
I thought it was a given.

Thanks for your hard work Christian.

Behcet

> In any case, I hope that this exercise will inform our efforts to
> standardize multipath support in QUIC.
>
> -- Christian Huitema
>
>
>