Re: [multipathtcp] High-level design decisions /architecture

[marcelo bagnulo braun <[e-mail]>]

William Herrin escribió:
> On Mon, Nov 2, 2009 at 1:47 PM,  <[e-mail]> wrote:
>
> Hi Philip,
>
> Apologies if any of this rehashes discussions you've already had.
>
>   
>> The MPTCP connection is identified, from an apps perspective, by the
>> addresses associated with the original path (even if that subflow /path
>> closes)
>>     
>
> I'm concerned about this idea. One of the corner cases where shim6
> falls apart is: once the connection migrates away from the original
> addresses, how do the endpoints decide whether a new connection
> request for the original addresses means the migrated addresses or the
> current holder of the addresses? Think: FTP.
>   

could you expand on this?
I wasn't aware shim6 falls apart in any case neither this particular 
approach...

Regards, marcelo

>
>   
>> A SYN/ACK exchange (on a single path) checks that both ends support MPTCP,
>> with automatic fall-back to TCP if not
>>     
>
> We have an awful lot of TCP options that are only valid in the
> SYN-SYN/ACK exchange and only 40 bytes to put them all. What's wrong
> with starting all TCP connections in non-MP mode and allowing the
> connection's initiator to request MPTCP starting with any packet that
> expects an ACK?
>
>
>   
>> each MPTCP subflow looks exactly like an ordinary, semantically independent
>> TCP flow. MPTCP effectively runs on top. So re-transmission, FINs etc are
>> independent on each subflow
>>     
>
> I'm almost sold on the idea of subflows. Can you give me a run down on
> the pros and cons, particularly the cons?
>
> Thanks,
> Bill Herrin
>
>
>