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

Toerless Eckert <> Thu, 11 June 2020 17:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 08C243A0BEC for <>; Thu, 11 Jun 2020 10:48:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.87
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y498uigqBcHW for <>; Thu, 11 Jun 2020 10:48:17 -0700 (PDT)
Received: from ( [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 714A53A0B2B for <>; Thu, 11 Jun 2020 10:48:17 -0700 (PDT)
Received: from ( [IPv6:2001:638:a000:4134::ffff:52]) by (Postfix) with ESMTP id 1F293548011; Thu, 11 Jun 2020 19:48:10 +0200 (CEST)
Received: by (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 <>
To: Olivier Bonaventure <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [multipathtcp] mptcp quick Q: MP-TCP for address redundancy
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


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