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

Toerless Eckert <> Thu, 11 June 2020 19:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 819223A0964 for <>; Thu, 11 Jun 2020 12:58:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X5oHtrnfosBb for <>; Thu, 11 Jun 2020 12:58:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 209623A0956 for <>; Thu, 11 Jun 2020 12:58:29 -0700 (PDT)
Received: from ( [IPv6:2001:638:a000:4134::ffff:52]) by (Postfix) with ESMTP id D6C09548045; Thu, 11 Jun 2020 21:58:23 +0200 (CEST)
Received: by (Postfix, from userid 10463) id D1113440043; Thu, 11 Jun 2020 21:58:23 +0200 (CEST)
Date: Thu, 11 Jun 2020 21:58:23 +0200
From: Toerless Eckert <>
To: Olivier Bonaventure <>
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
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 19:58:32 -0000

Thanks, Olivier,

Not quite sure from your reply what applies to non-backup vs. backup subflows,
you did not say.

Also: Is it necessary to avoid loosing all sub-flows, or does
that only speed up recovery ?

Aka: If i start with one subflow, learn additional addresses, but
not create additional subflows (just announce addresses), and
now one of the peer has an interface failure and this only
sub-flow fails. Would it then still be able to create a new 
subflow from a different address ?

Sorry, even to me these questions sound 101, but really hard to read 
asnwers from the spec to the uninitiated...


On Thu, Jun 11, 2020 at 09:12:22PM +0200, Olivier Bonaventure wrote:

> This mainly depends on how the path manager is tuned. With MPTCP, you can do
> make before break or break before make. As mentionned by Mathieu, you can
> also use the backup bit to only use one primary subflow and leave the other
> as backups.
> Taking the router example, one could run iBGP sessions over MPTCP. The
> session would be established to one of the IP addresses of the routers and
> the others would be learned automatically, enabling a failover in case of
> failure of the initial one. The BGP session could initiate all subflows and
> select the one with the lowest rtt.
> > 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.
> If there is a second subflow, MPTCP can typically recover from a failure
> within one or a few rtts since it checks for an alternate subflow when it
> retransmits data. This can be tuned and some have proposed schedulers that
> duplicate packets.
> > 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" ?
> MPTCP does not need to maintain all the N² subflows. It can decide to only
> create a few subflows, say 3 or 4 over very diverse addresses. That's a path
> manager decision.
> With MPTCP, once an address fails, it is announced over one subflow using
> rm_addr and all the subflows that use this address fail immediately.
> > Would that be a fair statement - specifically of course for the
> > case when it is known that there is only one path.
> It is possible to tune MPTCP depending on the use case that you have. If you
> want fast failover, it is possible to create some additional subflows, use a
> redundant scheduler to reduce the failover time at the expense of more
> overhead
> Olivier