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

[Quentin De Coninck <[e-mail]>]

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 ([e-mail] 
> <mailto:[e-mail]>) wrote:
>
>> It also seems odd to create a (bidirectional?) "path" with different 
>> identifiers at both sides.