Re: [multipathtcp] Multipath deployment and fate sharing

[Joe Touch <[e-mail]>]

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



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

The user can use the socket option to get information, and then use it
to log or use it to open a new connection. You can't know the difference
just from the first option access.

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

I agree; I just was checking.

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

You need to know whether the other side supports the new protocol either
way. You save only the extra legacy TCP exchange for legacy backup.

As to middleboxes, good luck - I can't see any option-based system that
a middlebox won't mess up.

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

I think you're assuming that if the transport protocols agree, the
applications are OK with using the new semantics. I'm not.

You'd get application buy-in by making this default-off, with an option
to turn it on. I suspect many on this list won't accept that solution,
because:
	a) it means no benefit for legacy apps that aren't
	revised to support the new protocol

	b) if you have to revise the app, you might as well have
	it use a new protocol altogether.

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

Because IP is best effort, and diffserv doesn't break "best effort"
semantics.

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

iEYEARECAAYFAksm3YYACgkQE5f5cImnZrspNQCfVP8pb19pa1GjsoFVJ+g23YaU
UzkAmgLkUSMFdUdLbOpvL6RdPCbO4Txr
=oyKw
-----END PGP SIGNATURE-----