Re: [multipathtcp] Multipath Address Family

["Laganier, Julien" <[e-mail]>]

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?

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