Re: [multipathtcp] Multipath Address Family

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. 

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

--julien

> I think Stuart was referring to some stuff in CoreFoundation, which are
> library calls, I think.
> 
> Best regards
> Michael
> >
> > --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
> >