Re: [multipathtcp] Multipath Address Family

[Michael Tüxen <[e-mail]>]

On Nov 24, 2009, at 11:32 PM, 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'm interested in the userland/kernel boundary, the system calls, not any kind of library calls.
So are you suggesting to do the DNS name lookups in the kernel? This would mean that
you want to implement DLS in the kernel. I'm not sure if I really like that...
We had^H^H^H have a feature in SCTP which also requires DNS lookups right from the
kernel and no-one implemented it. 

I think Stuart was referring to some stuff in CoreFoundation, which are library calls, I think.

Best regards
Michael
> 
> --julien 
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:multipathtcp-
>> [e-mail]] On Behalf Of Michael Tüxen
>> Sent: Tuesday, November 24, 2009 1:08 PM
>> To: William Herrin
>> Cc: [e-mail]
>> 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
>> <[e-mail]> 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 ................ [e-mail]
>> [e-mail]
>>> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
>>> Falls Church, VA 22042-3004
>>> _______________________________________________
>>> multipathtcp mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/multipathtcp
>>> 
>> 
>> _______________________________________________
>> multipathtcp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/multipathtcp
>