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

Toerless Eckert <tte@cs.fau.de> Thu, 11 June 2020 19:58 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 819223A0964 for <multipathtcp@ietfa.amsl.com>; Thu, 11 Jun 2020 12:58:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5oHtrnfosBb for <multipathtcp@ietfa.amsl.com>; Thu, 11 Jun 2020 12:58:29 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.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 209623A0956 for <multipathtcp@ietf.org>; Thu, 11 Jun 2020 12:58:29 -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 D6C09548045; Thu, 11 Jun 2020 21:58:23 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (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 <tte@cs.fau.de>
To: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Cc: multipathtcp@ietf.org
Message-ID: <20200611195823.GU16371@faui48f.informatik.uni-erlangen.de>
References: <20200611162904.GO16371@faui48f.informatik.uni-erlangen.de> <c3a6428e-7351-fab4-31c7-3cf909bdd6e9@uclouvain.be> <20200611174810.GR16371@faui48f.informatik.uni-erlangen.de> <fbd4fb80-b608-d81a-f292-ef26d41ab665@uclouvain.be>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <fbd4fb80-b608-d81a-f292-ef26d41ab665@uclouvain.be>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/faH-rtxhZsc9Em5Qccu_uoe1xHg>
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 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...

Cheers
    Toerless

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

-- 
---
tte@cs.fau.de