| 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. 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. 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. Mikkel On 16 December 2020 at 08.25.34, Yunfei Ma ([email protected]) wrote: It also seems odd to create a (bidirectional?) "path" with different identifiers at both sides.
