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

[<[e-mail]>]

Hi Olivier,

thanks for your feedback, see inline...

BR

Markus 

> -----Original Message-----
> From: Olivier Bonaventure [mailto:[e-mail]]
> Sent: Mittwoch, 12. Juli 2017 21:48
> To: Amend, Markus <[e-mail]>; [e-mail]
> 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

That is exactly what we aim to, because of application transparency. MPTCP is a wonderful protocol which extends TCPs single path limitation to multipath support. But again, like the TCP it tries to improve in respect to multipath support, it depends during sessions establishment from a single path. We see the chance to make MPTCP both robust against default route blocking and at the same time reduce establishment latency to the fastest path in game. This idea of robustness and acceleration is implemented in our "Downgrade" proposal, without any network overhead, but obviously a proposal with higher complexity. Especially compared to an approach which only tries to solve robustness challenge.

> 
> 2. Enhance the applications without adding complexity to MPTCP
> 

You are absolutely right to raise this option, which was never in focus of us, because we think/thought it should be a MPTCP inherent capability, see above. But why not...
At the end it needs special treatment from application developers, where I ever thought, that MPTCP focus is to be application transparent.

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

Yes, good observation. Indeed, it is a risk and I guess without additional processing, compared to MPTCP, it is hard to solve.

Our implementation uses the same functionality as exists in the MPTCP reference implementation for ensuring local uniqueness of keys respectively the corresponding token (hashtables). Thus the complexity is reduced to search the correct hash table entry and then only parse the linked list stored at this point.

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

It seems so, just read it the first time and yes, if KeyA is missing it is hard to figure out SYNs, related to the same request.

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

It is like the "Break before make" or "Timer" proposal from my original email, which is very similar to HappyEyeBalls idea in kernel space.

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

I guess, you mean the third "Timer" proposal, which fulfill the requirement of robustness as well. As you already wrote, we possibly delay!!! requests, that's why we don't prefer it currently, especially compared to the "Downgrade" proposal.
We know about the complexity of the first "Downgrade" proposal, but hey, to be honest, MPTCP is somehow also not easy :-)

I think in further discussion we have to clarify, if we raise with the question for MPTCP robust establishment a standard relevant topic or is it just implementation related?

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

Unfortunately, I arrive Sunday late around 8pm. But I like to discuss the ideas with you and anyone who is interested. Perhaps, we agree during the first MPTCP session on Tuesday some additional discussion? Otherwise you can contact me directly if you have some time on Sunday evening or Monday.
I'm looking forward to meet you in Prague. 

> Best regards,
> 
> 
> Olivier