Re: [multipathtcp] Multipath deployment and fate sharing

[Joe Touch <[e-mail]>]

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



Laganier, Julien wrote:
> Joe Touch wrote:
>> Laganier, Julien wrote:
>>> Iljitsch van Beijnum wrote:
>>>> On 14 dec 2009, at 17:38, Laganier, Julien wrote:
>>>>> With IPv4 of course the situation would be different due to the
>>>>> IPv4 address space exhaustion, presence of NATs, and DHCP 
>>>>> allocation with[Laganier, Julien]  short term leases. So in IPv4
>>>>> we can't rule out situation #2, and thus we want to make fate 
>>>>> sharing the default IPv4.
>>>> I don't see that. With NAT you don't know who you're going to
>>>> encounter behind a given address, anyway.
>>> This is a valid point.
>>>
>>> Thus it seems that whether or not MPTCP implements fate sharing, 
>>> a host can never be sure who's really behind a given IPv4 address.
>>> Essentially the address semantic is broken end-to-end.
>>>
>>> For purely local matters, fate-sharing can be used to maintain some
>>> applications' expectations regarding the relationship between local
>>> addresses and the transport connections that are bound on them.
>>
>> Apps have those expectations - local or remote. That's why some apps
>> break when they go through NATs. Let's not compound that situation with
>> by assuming fate sharing can be ignored.
> 
> Not what I intended to say, should have been more precise.
> 
> Fate sharing does not solve (neither its absence make worse) the 
> issue of a remote address X not being uniquely associated with a
> peer. For example, with fate sharing and normal TCP there's the issue
> of an application connected to a peer application on remote address X
> not being able to connect to the same peer when issuing another
> connect().
>
> This is different from the issue of an application expecting a
> connection to be up if and only if the remote address X is still in use
> by its peer. That one is influenced by our decision regarding fate-sharing.

I agree fate sharing doesn't solve the issue, but its absence definitely
does make it "worse", where "worse" is considered (by me) to be "not
what existing TCP does".

IMO, if you want to use TCP as the basis of MPTCP, then you need to have
defaults that do what TCP does, as visible to the app. layer, w.r.t.
addresses.

Joe

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

iEYEARECAAYFAksmhagACgkQE5f5cImnZrsV2gCfXtlziKZ6kYgGjjXxJTOgfSTs
BpsAn3jwTXcQ0g5qY+KTQASds2IebpFL
=484d
-----END PGP SIGNATURE-----