Re: [tcpm] MPTCP RobE

[Kangjiao <[e-mail]>]

Hi Olivier,

Thanks for the review. Please see a clarification inline for your suggestion. Thanks


> -----Original Message-----
> From: Olivier Bonaventure [mailto:[e-mail]]
> Sent: Monday, November 16, 2020 9:08 PM
> To: [e-mail]; [e-mail]
> Cc: Kangjiao <[e-mail]>
> Subject: Re: MPTCP RobE
> 
> Markus, Jiao,
> >
> > as one of the authors of
> https://datatracker.ietf.org/doc/draft-amend-tcpm-mptcp-robe/, I kindly
> request feedback from you, in particular however from the RFC6824/8684
> authors and MPTCP implementers.
> >
> > With MPTCP RobE (Robust Establishment) we address the lack of MPTCP to
> reliably setup a MPTCP session, when the selected path for the initial session
> setup is malfunctioned. The MPTCP RFCs does not give any guidelines for this
> particular problem and it is left to the implementer to take care. For that we
> propose and compare different strategies in the draft document, separated by
> their demand on MPTCP protocol changes. Apart from that our claim is, that
> with these proposals compared to MPTCP, no additional security flaws are
> raised and any potential computational overhead is minimized.
> >
> 
> Sorry for the late reply. I have looked at the document and found that handling
> both RFC6824 and RFC8684 adds a lot of complexity to the document. Since
> RFC8684 is the standards track version of MPTCP, I would suggest to only
> discuss this version of MPTCP in the document.
> 
> My main concern about the proposed approach is how this will work with
> load-balancers. When there is a load-balancer in front of a pool of servers that
> use the same IP address, there is no guarantee that SYNs from the same client
> will be delivered to the same server, especially if these SYNs are sent over
> different paths and thus with different source addresses. If the two
> connections that RobE tries to establish terminate on different physical servers,
> they cannot be joined. Given the importance of load balancers, I would prefer a
> solution where the application simply tries to open two parallel mptcp
> connections, prefers the first that gets established, adds another subflow to
> this connection and resets the second one. This would slightly increase the
>
>
> delay compared to RobE, but would preserve load balancers. In practice, I
> expect that MPTCP stacks will leverage information about the current quality of
> the access networks (e.g. WiFi and xG on smartphones) and will only attempt
> parallel connections when the conditions are uncertain. Apple's WiFi assist
> already includes such functionnality.
>
>

I think this point has already been covered by the RobE_IPS (initial path selection) in the draft (Section 2.3).

 
> Best regards,
> 
> 
> Olivier