Re: [multipathtcp] mptcp quick Q: MP-TCP for address redundancy

[Toerless Eckert <[e-mail]>]

Thanks, Olivier

I am trying to understand what overhead and delay in recovery incurred
when i am using MP-TCP not for what i think it was designed for,
but just to deal with address redundancy in IP.

Aka: Imagine two routers each with N interfaces, but
only one active IGP calculated path between them. In practice,
one always uses a loopback interface address and never the
N physical interface addresses. But that is just operational
practice, i have not seen a comparison in actual RFC text.

Aka: instead of the loopback i do use the N interface addresses,
how best would i characterize the redundancy (speed of recovery
from actively used interface loss) and overhead of MP-TCP.

I guess i can try to go with

"higher complexity and per-connection state
due to handling N^2 addresses and potentially slower recovery
loss of actively used failing remote peer addresses,
and/or overhead of maintaining as many as N^2
sub-flows to minimize loss of any address" ?

Would that be a fair statement - specifically of course for the
case when it is known that there is only one path.

Cheers
    Toerless

On Thu, Jun 11, 2020 at 06:41:00PM +0200, Olivier Bonaventure wrote:
> Hello,
> 
> > Could not easily find the answer to the following question:
> > 
> > Can i effectively use MP-TCP just to overcome possible loss of interfaces ?
> > 
> > E.g.: server and client each have two interfaces, connection is established
> > from client interface 1 address to server interface 1 address, the
> > additional addresses are exchanged via MP-TCP. Sometime during life-time
> > of both client interface 1 and server interface 1 fail in short order.
> 
> Yes, this works.
> 
> > Q1: Can MP-TCP survive that ? That being general case of N addresses
> > on client/server and N-1 address failures simulateneously.
> 
> Since MPTCP exchanges the different addresses, the client can try them in
> sequence to reach the server through the available one.
> 
> > Q2: If so, does it require full-mesh of subflows or any other setup
> > of subflows ?
> 
> A full-mesh would open all subflows. You might need a reactive path manager
> that reacts to changes in subflows to recreate new ones, see e.g. chapter 7
> of Viet Honag Tran thesis
> 
> https://inl.info.ucl.ac.be/publications/measuring-and-extending-multipath-tcp.html
> 
> 
> 
> Olivier