Re: [multipathtcp] Multipath Address Family

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



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.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAksMZZAACgkQE5f5cImnZruRSgCgzsQOWsLxX9olLpTzfL6epwn6
xIkAoKGYJQIgG0maVbyJ9quDS6VQg0s2
=ozME
-----END PGP SIGNATURE-----