Re: [multipathtcp] Multipath Address Family

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

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?

--julien