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

Toerless Eckert <tte@cs.fau.de> Thu, 11 June 2020 17:48 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C243A0BEC for <multipathtcp@ietfa.amsl.com>; Thu, 11 Jun 2020 10:48:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.87
X-Spam-Level:
X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y498uigqBcHW for <multipathtcp@ietfa.amsl.com>; Thu, 11 Jun 2020 10:48:17 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 714A53A0B2B for <multipathtcp@ietf.org>; Thu, 11 Jun 2020 10:48:17 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 1F293548011; Thu, 11 Jun 2020 19:48:10 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 16426440043; Thu, 11 Jun 2020 19:48:10 +0200 (CEST)
Date: Thu, 11 Jun 2020 19:48:10 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Cc: multipathtcp@ietf.org
Message-ID: <20200611174810.GR16371@faui48f.informatik.uni-erlangen.de>
References: <20200611162904.GO16371@faui48f.informatik.uni-erlangen.de> <c3a6428e-7351-fab4-31c7-3cf909bdd6e9@uclouvain.be>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <c3a6428e-7351-fab4-31c7-3cf909bdd6e9@uclouvain.be>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/IqBIWG5TZcU_9UWlfOe1FA69Hus>
Subject: Re: [multipathtcp] mptcp quick Q: MP-TCP for address redundancy
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jun 2020 17:48:20 -0000

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