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

[Mikkel Fahnøe Jørgensen <[e-mail]>]

| 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 ([e-mail]) wrote:

 It also seems odd to create a (bidirectional?) "path" with different
identifiers at both sides.