Re: [multipathtcp] Multipath Address Family

["Laganier, Julien" <[e-mail]>]

Pasi Sarolahti wrote:
> 
> On Nov 24, 2009, at 4:34 AM, William Herrin wrote:
> 
> > It seems like you want to preserve the connect() call's parameters by
> > altering the definition of sockaddr so that it can contain multiple
> > addresses.
> >
> > But functionally, what we really want to do is pass an array of
> > sockaddrs to connect().
> >
> > Stupid question time: what makes redefining sockaddr superior to an
> > extended API call that supplants connect() and accepts an array of
> > sockaddrs?
> 
> Another question: is it better to have a compile-time error (or
> segmentation fault) or run-time error code, if application was built
> with multi-address support, but system was not?

Hmm. Neither =)

I think if we want to bind or connect an MPTCP connection to multiple addresses, we want to have new systems calls, in a fashion similar to what was done with sctp_connectx().
 
> 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. 
 
> 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.

--julien