Re: [tcpm] MPTCP RobE

[[e-mail]]

Ho Olivier,

See inline

> -----Original Message-----
> From: Olivier Bonaventure <[e-mail]>
> Sent: Montag, 16. November 2020 14:08
> To: Amend, Markus <[e-mail]>; [e-mail]
> Cc: [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.
> 

Good idea, would simplify some things. However most of our proposals are MPTCP version agnostic, expecting RobE eSIM.

> 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.
> 

Yes, that is a valid point, but similar to my answer above, probably only affects the RobE eSIM out of a bunch of proposals. Since RobE eSIM is an optional feature, which requires receiver (load balancer) support, load balancers can implicitly decline support (see MP_JOIN_CAP or ROBE_eSIM_EN).
From my perspective I see most value of RobE eSIM in e.g. 3GPP ATSSS (Proxy solutions) or real end-to-end MPTCP sessions.

> Best regards,
> 
> 
> Olivier