Hi Mikkel,
Le 16/12/20 à 10:19, Mikkel Fahnøe Jørgensen a écrit :
| It also seems odd to create a (bidirectional?) "path" with different
identifiers at both sides.
Hi Quentin, I have not read through your document, as I mentioned in
an earlier mail, I also have some concerns about the the Path-ID being
too granular because QoE does not relate to a path instance (sequence
number) but rather the tuples it runs over - at least most of the time.
+1, both the "forward path" and the "return path" should be considered.
But … the Path-ID in Liu uses the sequence number of the client CID.
Presumable both endpoints uses the same Path-ID for the same path,
even if server sends with a different CID.
Probably, but how can we ensure that for a given Path ID, each endhost
uses the same network road to reach its peer?
I had some concerns about PATH_STATE frames conflicting on Path-ID
when sent from different endpoints, but that shouldn’t be a problem. I
also especially had a concern about future symmetric multipath with
server announced endpoints, but if the client always probes the path
first, the client CID still remains a unique identifier.
Now, I do think that a more stable Path-ID makes sense compare to the
(potentially) frequently changing CIDs. But, again thinking about a
future server announced endpoint, a server might want to use different
paths for traffic steering even if the endpoint tuple remains the same
for multiple virtual paths. The server CID could be computed
differently for each virtual endpoint and affect server side routing.
So I am not sure client side Path-ID should be client CID because it
changes often, but it should be sufficiently unique for both
endpoints. Also I am not sure that a tuple based Path-ID is a good
decision because of potential virtual server endpoints.
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.
Best,
Quentin
Mikkel
On 16 December 2020 at 08.25.34, Yunfei Ma ([email protected]
<mailto:[email protected]>) wrote:
It also seems odd to create a (bidirectional?) "path" with different
identifiers at both sides.
