Re: [multipathtcp] Multipath deployment and fate sharing

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

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.

--julien