Re: [multipathtcp] Multipath deployment and fate sharing

[Joe Touch <[e-mail]>]

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



Iljitsch van Beijnum wrote:
...
> 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.

DHCP assignments shouldn't override explicit interface actions.

> 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. 

IMO, you need to make the assumption that causes the least amount of
chnage to existing apps. I understand why you want to call this TCP and
use TCP's protocol number, but that comes with this cost.

> 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.

Yes - that's exactly the cost of playing with TCP.

> 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.

Not sure this is sufficient. You can bind to a set of addresses (or
ANY), and still care that the IP address doesn't change (e.g., in-band
info can be IP-address specific, such as access control, etc.).

...
> 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.

This presumes that you know the purpose of a log. If the log is just
informational, the above may be true. But if the log is used to verify
access, or to coordinate future responses, just knowing it's logged to a
file isn't sufficient.

> So I think what we need:
> 
> - mechanism to indicate that a session is bound to an address

I think you need the negative of this, i.e., to find out whether a
session is NOT bound to an address, that can respond, YES, NO, or DON'T
KNOW (which should behave like YES).

> - mechanism to indicate that an address has been removed
> - mechanism to indicate "no address agility" (default = agility)

As above, default = no agility.

> - mechanism to indicate "no MPTCP" (default = MPTCP)

Under what conditions would you want to set "no MPTCP"? If you think it
will ever change TCP semantics, then the default needs to be "no MPTCP".
If not, then why do you ever need this option?

> 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.

See RFC1122 Sec 3.3.4.3, which explicitly ties the transport selection
of a source address to an address selected based on the state of the
interface. I.e., your assertion changes an existing standard.

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

iEYEARECAAYFAksmeC0ACgkQE5f5cImnZrvmEACg7IxWzPLnWygF5rjh+2VfdMuV
sTsAoKpJpA9rlMZUUwE/R5IHEf+nPw2t
=8L7B
-----END PGP SIGNATURE-----