Re: [multipathtcp] Multipath deployment and fate sharing

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

On 15 dec 2009, at 1:51, Joe Touch wrote:

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

Not sure what the issue is... Obviously we don't want the user to micro-manage. The way I see it, all of this is pretty similar to the V6ONLY socket option which obviated the need to manually mess with the availability of IPv4-mapped addresses with the IPv6 socket API.

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

This is easier to do with TCP options than with knocking at a door that may or may not be there, in that case you need a timeout, adding delay, or try to set up an old style and a new style session at the same time, adding overhead.

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

Actually middleboxes don't seem to be too hard on TCP options.

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

I was specifically addressing the situation where the applications are ok with the new semantics. If you feel that even under those circumstances changes to TCP semantics can't be made, my conclusion would have to be that you won't be able to support ANY type of multipath TCP.