Re: [multipathtcp] Multipath Address Family

[Joe Touch <[e-mail]>]

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



Laganier, Julien wrote:
> 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.

Sure. I was speaking in a general sense.

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

That basically kills legacy apps. You want getsockname to return the
initial, and some other call to return the full list (or supplemental
socket pairs).

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

iEYEARECAAYFAksMbBMACgkQE5f5cImnZrsVswCgoFpCKQa8jx5gpDG2Re01s6ic
elcAoLDKy6KCjJDGgcxKL95tjlmuAKz3
=hbq9
-----END PGP SIGNATURE-----