Re: [multipathtcp] Multipath deployment and fate sharing

[Joe Touch <[e-mail]>]

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



Costin Raiciu wrote:
...
> Coming back to fate sharing of multipath connection and initial
> subflow: I would assume fate sharing will be a sysctl flag on the host,
> telling the stack whether the connection should go down or not with the
> first subflow. I imagine three settings here:
>
> a) connection doesn't go down with first subflow
> b) connection dies when local interface dies
> c) connection dies when subflow times out (this implies b)

These are interesting configuration parameters from an implementation
view, but from a protocol view, if we're talking about TCP, there are
only two cases:

	a) connection goes down when the whole set of subflows goes down

	b) connection goes down when the first subflow goes down

What makes a subflow go down shouldn't be defined separately; it's
exactly whatever would make that connection go down if it were a single,
stand-alone TCP connection.

The remaining question will be whether (a) is still TCP, or more
specifically how to make (b) look more like (a).

One way is to say "first subflow packets are tunneled over other
subflows". If that is actually how things are done, then you can claim
that the original subflow is actually still up, and make progress.

However, anything that would cause the original subflow to fail even
when tunneled over other interfaces still, IMO, needs to cause the whole
set to go down. The key example is loss of the IP address associated
with the original flow - either when the interface goes down, or when
it's lost via failed DHCP renewals, or when it's otherwise explicitly
reconfigured.

Provided this latter case is defined clearly enough, this might be a way
to proceed. However, if you start a connection with an address you're
given by an ISP, you can't continue that after the address is revoked.
If you do, you could interfere with other connections from other hosts
to which that address is (re)assigned.

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

iEYEARECAAYFAksNUtUACgkQE5f5cImnZrtUmACgqpgS4b3rQcKNxJDujaFtA8dk
/GQAnAqzdrCrydyRFz40fiNb6DKx4hoa
=Ybic
-----END PGP SIGNATURE-----