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
- [multipathtcp] mptcp quick Q: MP-TCP for address … Toerless Eckert
- Re: [multipathtcp] mptcp quick Q: MP-TCP for addr… Olivier Bonaventure
- Re: [multipathtcp] mptcp quick Q: MP-TCP for addr… Matthieu Baerts
- Re: [multipathtcp] mptcp quick Q: MP-TCP for addr… Toerless Eckert
- Re: [multipathtcp] mptcp quick Q: MP-TCP for addr… Olivier Bonaventure
- Re: [multipathtcp] mptcp quick Q: MP-TCP for addr… Toerless Eckert
- Re: [multipathtcp] mptcp quick Q: MP-TCP for addr… Olivier Bonaventure