Re: Multipath QUIC prototypes

[Michael Eriksson <[e-mail]>]

On Thu, 9 Sep 2021 14:46:39 +0200 (CEST), Christian Huitema 
<[e-mail]> wrote:
 > Picoquic has in fact support for two variants of multipath, draft-liu
 > and the single number option draft-huitema-quic-mpath-option-00.
 >
 > Multipath has not yet been deployed in the picoquic demo program -- all
 > tests are on simulated environments. I could easily add a listing of all
 > IP addresses available at the client on start, given then a list of
 > addresses to choose from, and more or less automatically trying them
 > all. I should add a monitoring of this set of addresses using system
 > APIs, but those APIs are of course system dependent so that's a bit of
 > work. I would be motivated to do that if someone is using the feature...

It seems simpler to let the application find and select the
interfaces. In a prototype phase, it should be enough to give a list
of local IP address as parameters to the test client. (Servers
normally have a single (public) interface, otherwise that applies to
them too.)

On Linux, for instance, you also need to set up source routing of the
IP packets, otherwise they go out on the default route independently
of which source address you have bound your UDP socket to. To set up
the source routing, you need to be root (or have similar privileges);
something you maybe don't want your experimental code that's
connecting over the Internet to do...

 > For a discussion, see:
 > 
https://huitema.wordpress.com/2021/02/14/how-many-packet-number-spaces-for-quic-multipath/. 

 >
 > Both options work. The single number space option is simpler, the only
 > problem being the number of ranges in the acknowledgements.

Yes, I read your blog posts at the time, and they convinced me that a
single number space is a cleaner design. I think the number ranges in
the ACKs can be handled in a good way, maybe with a little help from
the sender. We'll see...

/Michael