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

[Scott Brim <[e-mail]>]

Joe Touch allegedly wrote on 11/02/2009 7:23 PM:
>> (even if that
>>       subflow /path closes)
> 
> Yes, although, as noted, if the IP address goes away altogether, then
> IMO the connection needs to be terminated.

Joe, that's just not necessary except for legacy endpoint stacks.  See
the iPhone and "connectByName".  If the API revolves around a connection
ID, regardless of underlying addresses, then IP addresses can come and
go as they with as long as the transport layer has some mechanism of
maintaining session authenticity and continuity.  The scenario where a
new node gets an IP address that an old node was just using is only
relevant if the connection is maintained using IP addresses ... which it
isn't.

>>     * the protocol involves an MPTCP stack at both ends of the MPTCP
>>       connection
>>           o [Comment: this is in our charter]
> 
> Agreed (as per the charter), but seriously this begs the question of
> what is "TCP" about the result. I don't like the idea of doing this all
> inside TCP solely as NAT camouflage.

Why not?  NAT is now architecture, and we have to deal with it.  You
could just as easily say we should be able to run lots of protocols over
the Internet but we have to put things in IP as "router camouflage".

>>     * There is an optional, extended API
>>           o [Question: would both ends need the extended API, with a
>>             fall-back if not?]
> 
> Seems like one end could want the extended API for explicit control of
> flows, but the other end doesn't need to care.

Agree.  The API is to access controls for the endpoint's implementation
of the protocol.  How an endpoint implements its APIs is independent of
the protocol.


Scott