Re: [multipathtcp] Multipath deployment and fate sharing

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

Joe Touch wrote: 
> 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".

So the situation is already "worse" without MPTCP to the extent that "existing TCP" on SHIM6 already modifies the range of event that are visible to applications compared to the "existing TCP" on "existing IPv6".
 
> 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.

If I apply that same logic to SHIM6 it should be turned off by default for all transport connections where the application hasn't opted in.

--julien