Subject: Re: [tcpm] MPTCP RobE

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 16 Nov 2020 14:08:17 +0100

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.

Best regards,

Olivier

---

From: <[email-masked]>
Date: Mon, 16 Nov 2020 16:01:33 +0000

Ho Olivier,

See inline

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

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

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

---

From: Kangjiao <[email-masked]>
Date: Tue, 17 Nov 2020 01:38:33 +0000

Hi Olivier,

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

> From: Olivier Bonaventure [mailto:[email-masked]]
> Sent: Monday, November 16, 2020 9:08 PM
> To: [email-masked]; [email-masked]
> Cc: Kangjiao <[email-masked]>
> 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.
> >
> 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.
> 
> 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).