Re: [multipathtcp] A proposal for MPTCP Robust session Establishment (MPTCP RobE)

Hi, Olivier and Markus,

I meet the same problem that the connection establishment fails due to weak WiFi signal although LTE is good.
The HappyEyeBalls is a good solution that we do not need modify the MPTCP. However, it requires the enhancement of the applications, as you mentioned. 
How about if the application does not support the enhancement, since we can't control the design of applications? 
I am considering that we may modify the MPTCP, e.g., let the MPTCP stack open two separate connections with indicated network IP addresses instead of the applications do. Moreover, this solution does not increase as much complexity as 'Duplicate SYN' does. Instead, the duplicate SYNs are sent to build two separate MPTCP connections without modifying the process of MPTCP connection establishment. How do you think?

Kind regards,
Jing

> -----Original Message-----
> From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of
> Olivier Bonaventure
> Sent: Thursday, July 13, 2017 3:48 AM
> To: Markus.Amend@telekom.de; multipathtcp@ietf.org
> Subject: Re: [multipathtcp] A proposal for MPTCP Robust session Establishment
> (MPTCP RobE)
> 
> Markus,
> 
> The problem that you raise is very similar to the HappyEyeBalls solutions that is
> used by web browsers on dual-stack hosts. The final goal is to make sure that
> applications can connect quickly to a destination when there are two paths
> available and one of them is bad.
> 
> I think that there are two ways to solve this problem :
> 
> 1. Enhance MPTCP so that MPTCP can support this use case without requiring
> any modification to the applications
> 
> 2. Enhance the applications without adding complexity to MPTCP
> 
> Concerning the first approach, I guess that you solution is to let the server parse
> through all the received SYN with a given key to check whether this is a dual
> connection establishment or a regular connection establishment. The limitation
> of this approach is that server needs to lookup all the keys of the received SYNs
> (possibly during a given period of time as you mention in your email) everytime
> it receives a SYN. This increases the SYN processing time on servers and thus the
> risk of denial of service attacks. It would be interesting to see how your
> implementation copes with this issue. Note that it requires the presence of a
> key inside the SYN (as defined in RFC6824). This implies that this is not
> compatible with RFC6824bis.
> 
> The second approach has been used successfully with HappyEyeBalls by web
> browers. It could be integrated in any library or higher level programming
> language by simply trying to open separate MPTCP connections and reset that
> one that connects slowly. A kernel implementation could probably also include
> code to support these parallel establishments of MPTCP connections. This
> would allow all applications to benefit from this feature, even those that use
> the C socket API directly.
> 
> The main benefit of the second approach is that the client is in control. It can
> delay the transmission of the second SYN as in HappyEyeBalls to avoid doubling
> unnecessarily the number of SYNs that a server has to process. Since the client
> is less loaded than the server, it is less an issue to put some complexity (e.g.
> timers, remembering the best interface, ...) on the client side.
> 
> If you travel to Prague, I'd be happy to discuss with you. We'll also participate to
> the hackathon on Sunday if you'd like to discuss about your implementation.
> 
> Best regards,
> 
> 
> Olivier
> 
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp