Re: [multipathtcp] Multipath Address Family

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

Joe Touch wrote:
> Laganier, Julien wrote:
> > Hi, Joe,
> >> 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.
> >
> > Without taking position with respect to fate-sharing between the
> > MPTCP connection and the original address-port pair, whether the MPTCP
> > connection is torn down when the original address-port pair fails is,
> > I think, an issue orthogonal to the specifics of how an application
> > connects to a peer.
> >
> > In both case we can introduce the connect_to_name() call in the new
> > API.
> >
> > Orthogonal to that, if we decide we want to treat the initial address
> > pair() that got used to establish the MPTCP connection in a special
> > fashion, e.g., fate-sharing, we can still do so by defining the
> > behavior in the protocol specification.
> >
> > Makes sense?
> 
> Sure, but either way you need to return at least the primary IP
> address/port pair as results of the connect_to_name() call.
> 
> It's not sufficient to return an undistinguished set of such pairs, nor
> is it sufficient to not return any such pairs.

Unless the socket has been bind()'ed earlier, connect() doesn't return to the caller any information about the address/port that was picked as a result of the connect(). The application would need to call getsockname() to know what address/port pair was used. 

If an application is modified to use the new API, it will have to use getpeername() in addition to getsockname() to know what initial address pair has been connected.

--julien