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.
Quentin
