Subject: Re: [multipathtcp] Integration with SSL

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 7 Aug 2009 10:55:54 +0200

On 27 jul 2009, at 14:58, Costin Raiciu wrote:

> The reason we've included the complex looking explicit address  
> signaling is because implicit signaling as you propose below does  
> not work in all cases; fixing it to work in all cases effectively  
> requires explicit signaling.

One important point that goes beyond this particular issue: in  
multipath TCP, we have the luxory of not having to work 100% of the  
time. If we try to do multipath and it doesn't work, we still have a  
normal single path session so we haven't lost anything. This is  
especially relevant to NAT traversal: with other stuff, if you can't  
get through the NAT, you're dead in the water. We are still alive in  
the water, just not swimming as fast as we'd like to. (Unless, of  
course, we modify TCP so much that the initial subflow won't pass  
through NATs anymore.)

> As for integrating one-ended with two ended, the difference  
> resulting from one sequence space  vs multiple sequence spaces is  
> big enough that you effectively need "switch" from one to the other.  
> The only way I see is to make them working together is to use the  
> MPTCP negotiation in the beginning. For instance:
> 1. Start with MTCP capable option in the SYN
> 2. If the other end replies with MPATH capable, then use 2-ended  
> algorithm.
> 3. If the other end doesn't include MPATH capable in his SYN, use  
> one-ended mpath if you can.

Basically, what you're saying is that there is no useful middle ground  
between the one-ended and the two-ended approach. Obviously to some  
degree this is true, either you're one-ended or two-ended. But the  
current two-ended approach is very complex, so the gap between the two  
approaches is large. I can imagine that someone would like more  
functionality than the one-ended approach provides, but doesn't want  
to implement all the complexity of the current two-ended approach. By  
making some parts of your approach optional, it would be easier for  
people to implement at least some level of multiaddress MPTCP even if  
they feel that implementing all the mechanisms is too much.