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
