Re: [multipathtcp] API: which address to use

[Pasi Sarolahti <[e-mail]>]

On Nov 9, 2009, at 10:42 PM, William Herrin wrote:

> On Mon, Nov 9, 2009 at 5:49 AM, Pasi Sarolahti  
> <[e-mail]> wrote:
>> This problem was just discussed in the meeting. Could one possible  
>> solution
>> to the getsockname semantics problem be to use a separate address  
>> family for
>> multipath connections? It could be similarly structured to the  
>> traditional
>> AF, but from the different AF the app would know the semantics are
>> different.
>
> Not really, no.
>
> Backwards compatibility is an issue, as you mentioned. So is a desire
> to be able to use both IPv4 and IPv6 paths in a single multipath TCP
> connection. If it's a legacy app then it's expecting getsockname to
> return the same address family that it used to initiate the socket. If
> you provide something else you could open a path for buffer overflows
> or other mischief.

Ok, so there could be a non-backwards compatible way and a  
(pseudo)backwards compatible way. I don't think these had to be  
exclusive, and both could be supported at the same time.

Non-backwards compatible version would be to use new AF_MULTIPATH,  
that would be an array of AF_INET and AF_INET6 entries. Of course that  
would need to be used consistently throughout the connection lifetime.  
gethostname and getpeername would return the current set of active  
addresses at local or remote end. bind() could use this to bind to  
several addresses at a time. connect() could use this to give more  
than one known destination addresses to connect to (although the MPTCP  
protocol logic may prevent the actual connect operation from happening  
simultaneously).  gethostbyname might return several addresses from  
DNS in a single AF_MULTIPATH record, to be directly used by  
connect(AF_MULTIPATH), instead of needing to cycle through the  
addresses separately, as a traditional single-homed version would do.  
This would require modifications also elsewhere than TCP code, but  
that's what you get for having an API that exposes the IP address to  
the application and assumes only one address is in use at a time.

The backwards compatible version could just return the oldest active  
address and hope nothing breaks on legacy apps. I don't know if this  
is better or worse choice than returning the first used address that  
might not exist anymore. Has it been specified anywhere that  
getsockname/getpeername should return same result through the  
connection lifetime?

- Pasi