Subject: Options for QUIC Multipath

From: Christian Huitema <[email-masked]>
Date: Sun, 14 Feb 2021 14:22:42 -0800

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 15 Feb 2021 09:48:21 -0600

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

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

---

From: Martin Duke <[email-masked]>
Date: Mon, 15 Feb 2021 12:07:08 -0800

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.