Re: Fwd: New Version Notification for draft-liu-multipath-quic-01.txt

[Mikkel Fahnøe Jørgensen <[e-mail]>]

Maybe the QoE per Path-ID is too granular when the ID is tied to the CID
because the CID may change for reasons unrelated to changes in the path
metrics.

On the client side what matters is largely the 2-tuple the decides between
WiFi, modem, or ethernet.

On a future multi-homed server, the endpoint likewise dictates QoE - but
here it could mean where the server relays chat traffic separate from game
state.

Mikkel

On 15 December 2020 at 01.08.17, Mikkel Fahnøe Jørgensen ([e-mail])
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 ([e-mail]) 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 <[e-mail]>
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.
>
>
>