Re: [multipathtcp] Multipath Address Family

[Pasi Sarolahti <[e-mail]>]

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?

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).

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.

> Poking around linux's include files (netinet/in.h, bits/socket.h) I
> notice that they go to a lot of trouble to make all sockaddrs come out
> to exactly the same number of bytes. Won't a variable length sockaddr
> that holds a variable number of addresses make a mess of that?

I guess the question is whether the length of sockaddr is a Linux  
implementation issue that can be fixed, or whether there is some  
deeper reason for having the sockaddrs to be of same length. In Unix  
domain sockets the pathnames in sockaddr can be variable length and  
quite long, to my understanding, certainly worth of several IP  
addresses. But it would be interesting to know what, if anything,  
would break in legacy systems with a new sockaddr variant. I'm  
assuming that the TCP stack needs to go through fairly significant  
change anyway because of MPTCP.

> Found a quote I think bears on the topic at
> http://lkml.indiana.edu/hypermail/linux/net/9904.2/0091.html :
>
>> The AF_ prefix stands for "address family" and the PF_prefix stands  
>> for
>> "protocol family". Historicly, the intent was that a single  
>> protocol family
>> might support multiple address families and that the PF_ value was  
>> used to
>> create the socket and the AF_ value was used in socket address  
>> structures.
>> But in actuality, a protocol family supporting multiple address  
>> families has
>> never been supported and the <sys/socket.h> header defines the PF_  
>> value
>> for a given protocol to be equal to the AF_ value for that protocol.
>
> I think when we discuss allowing multipath TCP to use IPv4 and IPv6
> addresses interchangeably, we're talking about one protocol family
> using multiple address families, are we not?

I have been curious about this PF/AF dependence that seems like a long- 
standing "bug" in some systems. Have you ever investigated this  
deeper? Why would it be so hard to fix it so that you could have  
several address families in one protocol family?

- Pasi