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

Toerless Eckert <tte@cs.fau.de> Thu, 11 June 2020 16:29 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 4F6053A087B for <multipathtcp@ietfa.amsl.com>; Thu, 11 Jun 2020 09:29:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Status: No, score=-1.651 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] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Eo9fPX93r_5T for <multipathtcp@ietfa.amsl.com>; Thu, 11 Jun 2020 09:29:09 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49C4E3A0A5F for <multipathtcp@ietf.org>; Thu, 11 Jun 2020 09:29:08 -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 11DF8548045 for <multipathtcp@ietf.org>; Thu, 11 Jun 2020 18:29:05 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 05989440043; Thu, 11 Jun 2020 18:29:05 +0200 (CEST)
Date: Thu, 11 Jun 2020 18:29:04 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: multipathtcp@ietf.org
Message-ID: <20200611162904.GO16371@faui48f.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/K-tkVuU3johYiONZHxughc33uEY>
Subject: [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 16:29:11 -0000

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.

Q1: Can MP-TCP survive that ? That being general case of N addresses
on client/server and N-1 address failures simulateneously.

Q2: If so, does it require full-mesh of subflows or any other setup
of subflows ?