Re: [multipathtcp] Multipath deployment and fate sharing

[Joe Touch <[e-mail]>]

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



Iljitsch van Beijnum wrote:
...
> So this leaves the situation where we know an address is no longer
> valid and the application(s) are interested in the addresses. Eventually
> we need to move to a situation where applications need to register their
> wishes in this regard and allow MPTCP by default if they don't, because
> the opposite situation isn't workable. 

Pushing MPTCP on by default in the absence of knowing it won't change
TCP semantics is unworkable too.

There are two options:

	1- use TCP as the basis of this new thing
	2- use a new protocol number

(1) lets you traverse NATs and be backward compatible with legacy apps,
but *ONLY* if you don't change the semantics.

It isn't reasonable to pick an alternative that could break existing
apps, but to push forward because it furthers the agenda of this WG.

> However, it could be reasonable
> to have an interim period during which the default is to make MPTCP
> sessions bound to addresses that are no longer valid go down if the
> applications have expressed interest in those addresses

I disagree, as per above. You're playing with TCP by your choice. It's
your responsibility to "first do no harm", which means to leave things
in legacy mode (captain goes down with the ship) until you know better.

If this is that useful, apps. will override that mode explicitly.

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

iEYEARECAAYFAksmeDkACgkQE5f5cImnZrvwEgCffV3CMdyit+VtxW1JTQPXAG9i
K38AoP4S/u2UWZmMULS0E5pgtZazKob1
=2lEd
-----END PGP SIGNATURE-----