Re: [multipathtcp] Multipath deployment and fate sharing

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

[I haven't been keeping up with this list, apologies if I make points that were discussed previously.]

On 25 nov 2009, at 16:52, Joe Touch wrote:

>> Coming back to fate sharing of multipath connection and initial
>> subflow: I would assume fate sharing will be a sysctl flag on the host,

That can only set the default, we need a socket option to do it per application.

>> a) connection doesn't go down with first subflow
>> b) connection dies when local interface dies
>> c) connection dies when subflow times out (this implies b)

> These are interesting configuration parameters from an implementation
> view, but from a protocol view, if we're talking about TCP, there are
> only two cases:

> 	a) connection goes down when the whole set of subflows goes down

Yes, you still need to have a _session_ timeout.

Somewhat related issue: do we explicitly close a session, or implicitly by closing all subflows? The latter leads to long delays when a subflow is down.

> 	b) connection goes down when the first subflow goes down

> What makes a subflow go down shouldn't be defined separately;

We need to avoid sending data over broken subflows, though.

> However, anything that would cause the original subflow to fail even
> when tunneled over other interfaces still, IMO, needs to cause the whole
> set to go down. The key example is loss of the IP address associated
> with the original flow - either when the interface goes down, or when
> it's lost via failed DHCP renewals, or when it's otherwise explicitly
> reconfigured.


There are several issues here. But before we delve in: why didn't we have this discussion in shim6, where the exact same problem is present? And what about mobility?

I agree that if a host loses an address, it should no longer send packets that use that address in some way. So in the multiaddress MPTCP case that means a subflow that uses that address will have to be terminated when the address is removed. Note though, that some systems remove addresses when the interface goes down. That in itself is no reason to release the address. If a DHCP server or RA indicates that an address may be used for X amount of time, you get to keep it X amount of time, even if connectivity goes away, temporarily or difinitively, at some point.

But then the question is: what happens to other subflows?

My answer: "if a tree falls in the forest, and all the people in the forest are wearing headphones at maximum volume, did the tree fall?"

The problem with a socket option to indicate care is that it's going to take a long time for all apps to use this socket option, and we still need a default behavior. I don't think it makes sense to make the default behavior "care" because then you have to go out of your way to not care, which by definition people don't do. Especially since it requires thinking about how to set a socket option that will be unknown on some systems for portable applications.

However, we can deduce that applications care if they bind to a specific address, or look up the address tied to the remote end of an incoming session. If neither happens subflows can continue without trouble.

By the way: we need to communicate the address loss event to the other side so the other side can tear down the session if we lose our address but don't care but the other side cares. Note also that although binding to a listening address happens before the three-way handshake, looking up the remote address may happen afterwards.

Another class of applications is those that care about the addresses, but are not bothered by change. For instance, I may log that I'm talking to 192.0.2.1 but then when that address goes down and communication continues using 10.0.0.1, I simply log the address addition/change and all is well.

So I think what we need:

- mechanism to indicate that a session is bound to an address
- mechanism to indicate that an address has been removed
- mechanism to indicate "no address agility" (default = agility)
- mechanism to indicate "no MPTCP" (default = MPTCP)

Note that "no address agility" and "MPTCP" means that you can have additional subflows using additional addresses, but only as long as the primary addresses have reachability. I think this is similar to MIPv6, where you need to return to the HoA at certain intervals.

I don't think it's appropriate to explicitly track interface status in TCP. If the packets get there you're up, if they don't you time out eventually and then presumably you're down.