Re: [multipathtcp] Multipath Address Family

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

On Nov 25, 2009, at 7:38 PM, Laganier, Julien wrote:

> Michael Tüxen wrote:
>> 
>> 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.
> 
> Good for you.
> 
> I'm not talking about any kind of library call, I'm talking about an API, which is what I think the WG is chartered to work on. 
Sorry, I was not clear enough. What I meant was that it is important where the
API you are thinking about should be implemented.
If it is at the kernel/userland boundary, like the socket calls, there might be
other restrictions as when you are considering library calls.

The point I wanted to make is that doing DNS lookups in a userland library is simple,
doing it in the kernel is a different story. That is why I wanted to figure out
where you think you API is located at.
> 
>> 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'm suggesting to do DNS lookups as a result of the connect_to_name() API call, nothing more.
But my point is if it will be in the kernel (if you think your connect_to_name() call
is a system call) or if it is in a library. If it is in the library you still must be able
to implement it using existing system calls.
> 
> --julien
> 
>> 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
>>> 
> 
>