Re: [multipathtcp] Multipath Address Family

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Laganier, Julien wrote:
> Stuart Cheshire had a nice talk at IETF 72 on the drawbacks of the current getaddrinfo() + connect() model w.r.t. to IPv6 transition,see http://www.stuartcheshire.org/IETF72/. (Somebody already mentioned that on the list I think.)
> 
> A connect_to_name() calls that hides all of the address family subtleties under the hood
> does not have such drawbacks. So if we're going to change the API anyway, this looks like a good occasion to fix that issue too, no?

I like this idea, but there needs to be a returned primary IP address if
this is intended to support TCP. I.e., you can ask the system to call a
name, but it ends up establishing a TCP connection to a socket pair (src
IP, dst IP, src port, dst port).

I'm still not sure what that means for multipath. There could be
secondary socket pairs of course, and they can vary over the life of the
connection, but I still feel that if the primary disappears the
connection MUST disappear *IF* this is TCP.

Of course, if it's not TCP, this could be easily defined in other more
useful ways.

Joe

> --julien 
> 
>> -----Original Message-----
>> From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-
>> bounces@ietf.org] On Behalf Of Michael Tüxen
>> Sent: Tuesday, November 24, 2009 1:08 PM
>> To: William Herrin
>> Cc: multipathtcp@ietf.org
>> Subject: 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
>>>
>> _______________________________________________
>> multipathtcp mailing list
>> multipathtcp@ietf.org
>> https://www.ietf.org/mailman/listinfo/multipathtcp
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAksMYHoACgkQE5f5cImnZrsNfACgh9pUrJDwwvYhwDeJFVR/xI0t
/NgAoLjph0OwVVfegYKxYx2otnCIh8Pp
=fyli
-----END PGP SIGNATURE-----