Re: [tcpm] MPTCP RobE

[Olivier Bonaventure <[e-mail]>]

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