I cant discuss the use case in detial but perhaps it is worth noting that the WebRTC case I mention has a web client at one end, and a mobile server at the other end, and here the multipath concern is primarily the connectivity of the mobile server. Therefore the current multipath proposal would not be sufficient (along with WebRTC on QUIC).
Mikkel On 15 December 2020 at 01.08.17, Mikkel Fahnøe Jørgensen ([email protected]) wrote: I am indeed working with a STUN WebRTC use case which could benefit from a QUIC MP replacement of WebRTC. A problem here is that it is often necessary to use WebRTC over TLS/TURN because of firewall policies. Hopefully a future QUIC version could both provide multipath and avoid TURN overhead provided QUIC gains enough traction to slip through firewalls by default. But in this discussion I’m more thinking about possible server configurations either server to server or client to server. A server might implement itself on multiple hardware nodes, for resilience, load balancing, or locality of reference, or a server might have access to multiple network cards with different IP addresses. Kind Regards, Mikkel Fahnøe Jørgensen On 15 December 2020 at 00.27.13, Yunfei Ma ([email protected]) wrote: Hi Mikkel, I think this current protocol does not prevent you from doing that as it is designed as a minimally-scoped extension of QUIC-v1. The goal is to make it easier for people to try different things with multi-path. As pointed out by Christian, announcing address/port/QoE does have some complexity. One way is to let the client server cooperate, but you may also want to use a STUN server to help you achieve that which is similar to the case of RTC. We would appreciate it if you could try and let us know your experience. Cheers, Yunfei On Mon, Dec 14, 2020 at 2:56 PM Mikkel Fahnøe Jørgensen <[email protected]> wrote: > These are good problems to address, but I would rather address them in a > targeted effort than as part of the multipath design. > > Good point and interesting description on VPN case. > > I think it would be helpful for multipath to still consider this at an > abstract level such that it can be plugged in at a later point without > deciding on the exact details up front, if for no other reason than to > avoid hardcoding things that don’t have to be. > > >
