Thanks for all of this, Christian. FWIW, I am deeply concerned about the complexity of the second approach, and like that the first approach's changes are almost entirely sender-side. IIUC on the receiver side, the only requirement is enough state to keep more than 1 path validated and active at once. If the objective is to provide a way to get MP-QUIC experiments up and running, this is an important consideration.
I am also quite fearful of undermining the assumption that sequence numbers increase monotonically; in particular, I'm afraid of messing up the key update logic. On Mon, Feb 15, 2021 at 7:48 AM Behcet Sarikaya <[email protected]> wrote: > > > 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 >> >> >>
