On Sun, Feb 14, 2021 at 4:23 PM Christian Huitema <[email protected]> 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 > > >
