On Thu, 9 Sep 2021 14:46:39 +0200 (CEST), Christian Huitema <[email protected]> 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
