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

[Christian Huitema <[e-mail]>]

On 12/16/2020 5:08 AM, Quentin De Coninck wrote:
>
>>> In my opinion, I don't think the "path" should be the element we 
>>> should identify. Rather, I think we should identify "forward flows" 
>>> and "backward flows" (what we call uniflows in our deconinck draft) 
>>> and see paths as a combination of a forward flow and a backward one.
>>>
>> Maybe - it sounds appealing. But if the client is always responsible 
>> for probing paths also for different server announced endpoints, then 
>> both endpoints are naturally coupled. The alternative would be for 
>> the server to also probe paths, and that can be difficult with NATs 
>> without STUN. There are many things to consider ...
>>
> Sure. Most of the time it is the client that will open the way and the 
> server waits for the client's packets exposing reachable IP/port 
> tuple. But I would find unfortunate to have a core design preventing 
> such flow creation initiative by the server. And while the client can 
> use, e.g., two flows to reach the server, the server may only want to 
> keep one flow towards the client to limit its state and we have two 
> possible circuits: 1) flow 1 client to server/flow server to client 
> and 2) flow 2 client to server/flow server to client.
>

The "symmetry of paths" is exactly the kind of issue for which we need 
experimentation with multiple implementations. We will know much more 
about that in a couple weeks.

The "symmetry of roles" is another matter. It is tied to discovery of 
addresses and traversal of NAT and firewalls. The address discovery 
issues are not specific to multipath -- they are prominent for example 
in P2P scenarios using QUIC V1. I think we should address them 
separately, as part maybe of an address discovery extension to QUIC V1. 
If that discovery extension was available, it could be composed nicely 
with multipath extensions.

I don't think there is anything in the current draft that would prevent 
that "composition with address discovery", but people are fallible. If 
there is, it will be fixed.

-- Christian Huitema