Re: [multipathtcp] Multipath deployment and fate sharing

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

On 14 dec 2009, at 21:27, Joe Touch wrote:

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

Absolutely. That's why either the ends must communicate to the other side the fact that they lost an address so the other side can take action if it cares, or they must indicate that they care at any time that they start caring about the specific addresses used for the session.

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

Is there any reason for the user to know? If the application uses a socket option to tell the system, the right thing will happen without user intervention.

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

The wg needs to come to rough consensus, if we can have that on everything but this point that provides a way forward.

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

Because of backward compatibility. If we start with TCP and only go to the new semantics when both ends agree this is readily deployable, but using a new protocol number or implementing TCPng on top of UDP means we need something to discover whether the other side supports the new protocol or not and of course middlebox issues.

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

How am I redefining it for everyone? I only execute the new semantics when both ends support them. (Remember that for the purposes of this sub-discussion I'm assuming that the applications at both ends have opted in to address agility etc.) This is no different from the TCP window scale option, in my opinion.

> Given it's place as a core protocol, I don't think redefining semantics
> ought to be on the table.

If we can redifine bits in the IP header with not even an opt in from the original sender of the packet (diffserv) why not TCP semantics...