Re: [multipathtcp] Multipath deployment and fate sharing

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

On 14 dec 2009, at 18:38, Joe Touch wrote:

> DHCP assignments shouldn't override explicit interface actions.

If you (as a TCP session) want to go down when the interface the address that you're bound to belongs to goes down, that is your choice. However, that is not current reality. First of all, there is no unambiguous up/down dichotomy for interfaces, and second, on many systems (FreeBSD, MacOS) TCP sessions will happily stick around when an interface is really, truly down, even to the degree that the address has been removed. (This is really nice because then the session is still there when the interface comes back up again.)

The point is the authority to use an address. If a DHCP server gives me a valid lifetime of 7200 seconds I get to use the address for two hours. Interface state has nothing to do with that. (How would the DHCP server know my interface is down? Or how would a router know the interface I configured from its RA is down?)

> 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 accept that requirement.

In the IETF, we get to change things. Even to the degree that the new instance does things that diverge significantly from the old instance. We do need to be prudent and cause the least possible amount of harm, but there is no requirement to stick to arbitrary old ways of doing things just because.

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

Yes, when you bind to an address you care. If you don't bind to an address (but ANY instead) apparently you don't care.

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

Well, these are applications that need to know about multiaddressing/multipath anyway, so presumably these apps know whether they just need logging or they need more.

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

Ok, I can go along with that at this point.

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

> As above, default = no agility.

Can we narrow down our differences to just this one?

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

> Under what conditions would you want to set "no MPTCP"?

Not sure if there is a large class of conditions that is incompatible with MPTCP, the only thing I can think of is speed tests. But as long as we're adding API calls we may as well err on the side of adding more than on the side of adding fewer, as the marginal cost of the extra ones is near-zero and the cost of producing and implementing an update are huge.

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

I can live with that.

By the way, about the protocol number: is that relevant? If two ends, including the applications on both sides, agree on different semantics, why would it be necessary to use a different protocol number?