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

[Olivier Bonaventure <[e-mail]>]

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