Re: [multipathtcp] Multipath Address Family

[Pasi Sarolahti <[e-mail]>]

On Nov 25, 2009, at 8:31 AM, Laganier, Julien wrote:

>> Even if we had a new mptcp_connectx, bindx, etc. calls, the problem
>> still remains what to do with the old socket operations that assume
>> only single address per endpoint. A new address family would be one
>> (unfortunately non-backwards compatible) way to address that problem
>> (possibly with the cost of introducing new problems).
>
> The "old" socket can have its semantic preserved by exposing through  
> it only the initial address-port pair in use.
>
>   - connect() will connect to one address-port
>   - bind() will bind to one address:port
>   - getsockname() will return the address-port to which the socket  
> was first bound
>   - getpeername() will return the address-port from which the  
> connection with the peer was initially established.

Ok, so the confusion is about whether get*name really refers to a  
stable "name" that misleadingly looks very much like an address/port,  
or whether it should point to a current address. Posix spec says about  
getpeername that "The getpeername() function shall retrieve the peer  
address of the specified socket", which hints towards the latter  
interpretation, but there may be other references (such as man pages)  
that spell this differently. Man page for getsockname says  
"Getsockname() returns the current address for the specified socket",  
but getpeername talks about names.

If the connection was to survive over the loss of the first address,  
getsockname or getpeername could return an address that has not been  
used by that host for a while, and the returned address might as well  
be already allocated to a different host. This may be a problem for  
applications that have assumed the "current address" interpretation. I  
agree that there needs to be a mode that is backwards compatible with  
the old AF_INET sockets for legacy apps, but if new applications were  
implemented to be multipath-aware with new or extended API, then also  
these calls should return reasonable values that correspond with  
reality.

A different question is how many applications really need to be aware  
of the underlying addresses -- probably a small minority (with  
apologies to people who are fed up with this discussion thread by now).

>> I think there is a certain elegancy in having a minimal socket API
>> with just a small basic set of operations. Until now the same socket
>> API has provided to be flexible enough to support many uses over time
>> (Unix domain sockets that take pathname as sockaddr, IPsec PF_KEY
>> sockets, netlink sockets, ...). I'm not yet ready to buy it that we
>> have come to a point that the old API is not sufficient anymore, if
>> the same functionality could be implemented by specifying a couple of
>> new socket parameters for a feature that is supported by just some of
>> the protocols under the API.
>
> AFAICS all uses of the socket API so far had the property that a  
> socket is bound to a _single_ and _constant_ name (e.g., address,  
> pathname), or in other words, there's no more than one name, and the  
> name doesn't change.
>
> This property is no longer true with MPTCP because a socket can be  
> bound to multiple and changing addresses. So if we're to design an  
> API that exposes that, extending an API that assumed exactly the  
> contrary is IMHO the wrong way to go.

I agree that this is different from earlier uses, but why is this a  
problem, if both the application and the protocol implementation have  
a common understanding (indicated by the address family) how the new  
form of sockaddress works? The socket API itself should be transparent  
about the structure of sockaddr, right? Connected socket has a  
property that it has a local and a remote endpoint, but now we have a  
case that an endpoint may have multiple "aliases" to represent it.

- Pasi