Re: [multipathtcp] Multipath deployment and fate sharing

[Joe Touch <[e-mail]>]

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



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

You didn't care what it was when you started, but you may care during a
connection (if you read it out).

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

They might know, but you might not. I.e., how do you know without
looking at the source code?

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

I'm not sure - is that the only place we differ?

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

Why is it necessary to use an old one? If you want an old one, why not
use UDP?

For any reason you want to stay with TCP, that's a reason to stick with
TCP semantics or realize you're redefining semantics TCP for everyone.
Given it's place as a core protocol, I don't think redefining semantics
ought to be on the table.

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

iEYEARECAAYFAksmn7IACgkQE5f5cImnZrvhhACg5VhFyAGu38trilbhYGjqbyAM
hS8AoN6m/51zWqYjucNlr3qSA8+bPwia
=DQNL
-----END PGP SIGNATURE-----