Re: [multipathtcp] Multipath deployment and fate sharing

[Iljitsch van Beijnum <[e-mail]>]

On 14 dec 2009, at 17:38, Laganier, Julien wrote:

> In the MPTCP fate sharing discussion there are two situations to consider:

> 1- a peer stop to use the original IP address but nobody else uses it
> 2- a peer stop to use the original IP address but somebody else starts to use it (e.g., address is re-allocated via DHCP)

> In SHIM6 only the situation #1 is likely to occur, because as Marcelo pointed out earlier, SHIM6 security relies on the use of a specific type of addresses (Hash Based Addresses and Cryptographically Generated Addresses) whose size and random nature make them unlikely to ever collide, thus situation #2 cannot happen in SHIM6.

Hm, yes. However, in the case of an address with an interface identifier that comes from a MAC address with the U/L bit set to "unique" we basically have the same situation as with Shim6 and HBA, except that the uniqueness is by convention rather than cryptographically protected.

But my point in my earlier message was that in a potential case 2 (might be a case 1 but we can't be sure), after the valid lifetime of the address expires, we should stop sending packets with the now invalid address. Other subflows that use different addresses can continue from the perspective of address uniqueness. 

Now there is the second issue of whether it's ok to continue communicating on different addresses when the originally chosen addresses are no longer valid for reasons of conforming to application expectations.

There, my point was that we can do this without reservation if the applications on both sides don't perform any API calls that reveal they're especially interested in the addresses used for a session.

So this leaves the situation where we know an address is no longer valid and the application(s) are interested in the addresses. Eventually we need to move to a situation where applications need to register their wishes in this regard and allow MPTCP by default if they don't, because the opposite situation isn't workable. However, it could be reasonable to have an interim period during which the default is to make MPTCP sessions bound to addresses that are no longer valid go down if the applications have expressed interest in those addresses.

> With IPv4 of course the situation would be different due to the IPv4 address space exhaustion, presence of NATs, and DHCP allocation with 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.

Iljitsch