Re: [multipathtcp] Multipath Address Family

Dear all,

just one note:
In SCTP we use sctp_connectx() to connect to multiple addresses.
Kacheong pointed a couple of years ago out that a more generic
connectx() would make sense to other protocols supporting multihoming
as well (but there were no).

So you might want to look at sctp_connectx() which the SCTP socket API
uses to handle the problem.

Best regards
Michael

On Nov 24, 2009, at 1:34 PM, William Herrin wrote:

> On Mon, Nov 23, 2009 at 4:40 PM, Pasi Sarolahti <pasi.sarolahti@iki.fi> wrote:
>> I think a new address family would be a minimal needed change to the current
>> socket API, without extending the API with new operations, but yet provide
>> an interface to handle multiple addresses in a socket. One potentially
>> useful characteristic would be that this would allow name resolver to return
>> multiple IPv4 and/or IPv6 addresses from the name server as a single
>> sockaddr structure, that could be directly given as a parameter to a connect
>> call, which would lead to trying which of the addresses are reachable for
>> the MPTCP session.
> 
> Hi Pasi,
> 
> 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?
> 
> 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?
> 
> 
>>> SOCK_MULTISTREAM or using a combination socket type like SOCK_STREAM |
>>> SOCK_MULTIPATH
>>> from the following reasons.
> 
> 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?
> 
> Regards,
> Bill Herrin
> 
> 
> 
> -- 
> William D. Herrin ................ herrin@dirtside.com  bill@herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp
> 