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

Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> Thu, 11 June 2020 19:12 UTC

Return-Path: <olivier.bonaventure@uclouvain.be>
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 69F083A00AD for <multipathtcp@ietfa.amsl.com>; Thu, 11 Jun 2020 12:12:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level:
X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be
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 FGKaYitrruNk for <multipathtcp@ietfa.amsl.com>; Thu, 11 Jun 2020 12:12:26 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30114.outbound.protection.outlook.com [40.107.3.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC493A0061 for <multipathtcp@ietf.org>; Thu, 11 Jun 2020 12:12:26 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K+Myc2BZeJumESvBJ412P/jlfSb533E0xvO3P0j807tk/4j4gmqmXIe7PpfI5tnapAAL/WcHe+coamDMC0q9NxfJ7NfTqaZmnuqroh7z3EOUA2na4FE3ny2kpsFhdBft+hVJwBzsHjRuFVu7Lyq7gQJyxD6o4PSd0kaKWFjCyOWOVO74XE35LbCMLdJ8rYGqQdG2gIwPJ/J/rnJ9RnD1qKk7tkvT4Q3+xxH6e8u09y8pq1UL7XV9pOcEQkgPIDIdROIMr49GeToxq3ywsGvbDg5LCdX0NxdHw+a2YNsp4Ts7e8nH9y2Kujk7oPeHN6eLnwkGxlJJBMgKAguBKHBrXA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E1mwXDq2Jz1sVzATsMpebd3manIFGZQeI2kXfXGpOXY=; b=S7hKDXKBUALFLm2Cc9ZAP/xwnQPEHqigaWzZf4UAQqfA58VhxnC1iDbjZ22dnvdl2pPbz6yzHl7hTifLuX27l05FGxMFoPy5WDaRN36Fs9XybCXkN76GYSIGuI+UhsVi49b+M0vEKUCh0sBKc4s7rw3oRK81DVuUHQjFtBenGrkIdZBR9Z+gYh6fo8bPV39MEwGYE7zYtH03CY7EAMlb8g8BibXFNaxXfKoSikJb+RuuxORgxhf1+60oZlSTgOKO8E/7Bh+hC1tQGGBTqMRF0otafP3q57VluZ97+tT0NyYcEVGXyL7HKj8b1SIuvrJRl/URMegIrIkHLpsiWApWRA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uclouvain.be; dmarc=pass action=none header.from=uclouvain.be; dkim=pass header.d=uclouvain.be; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uclouvain.be; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E1mwXDq2Jz1sVzATsMpebd3manIFGZQeI2kXfXGpOXY=; b=snwYIfkdMT5aUTipXXWJajqUFiFNTwXzpyAYHJym6FwMcQ+RwC7BN9pmUib7aSGyvvL6oox/OeK9BNtwD5IYtBLrTKwBwHoy6AMNHH4zXE74afZ/s5hL3tcpDPtoBUnGn/j6dZhrk6yejGJ+9SQ0TlE5uOJs/15XCO2vh5Cc6PU=
Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=uclouvain.be;
Received: from AM7PR03MB6642.eurprd03.prod.outlook.com (2603:10a6:20b:1bf::6) by AM7PR03MB6168.eurprd03.prod.outlook.com (2603:10a6:20b:140::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.21; Thu, 11 Jun 2020 19:12:23 +0000
Received: from AM7PR03MB6642.eurprd03.prod.outlook.com ([fe80::fcc2:e19d:eec3:15e6]) by AM7PR03MB6642.eurprd03.prod.outlook.com ([fe80::fcc2:e19d:eec3:15e6%7]) with mapi id 15.20.3088.018; Thu, 11 Jun 2020 19:12:23 +0000
To: Toerless Eckert <tte@cs.fau.de>
Cc: multipathtcp@ietf.org
References: <20200611162904.GO16371@faui48f.informatik.uni-erlangen.de> <c3a6428e-7351-fab4-31c7-3cf909bdd6e9@uclouvain.be> <20200611174810.GR16371@faui48f.informatik.uni-erlangen.de>
From: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Message-ID: <fbd4fb80-b608-d81a-f292-ef26d41ab665@uclouvain.be>
Date: Thu, 11 Jun 2020 21:12:22 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
In-Reply-To: <20200611174810.GR16371@faui48f.informatik.uni-erlangen.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: AM0PR04CA0001.eurprd04.prod.outlook.com (2603:10a6:208:122::14) To AM7PR03MB6642.eurprd03.prod.outlook.com (2603:10a6:20b:1bf::6)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [IPv6:2a02:2788:484:b4f:d1c9:4168:417c:2fb6] (2a02:2788:484:b4f:d1c9:4168:417c:2fb6) by AM0PR04CA0001.eurprd04.prod.outlook.com (2603:10a6:208:122::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Thu, 11 Jun 2020 19:12:23 +0000
X-Originating-IP: [2a02:2788:484:b4f:d1c9:4168:417c:2fb6]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 701879da-5751-4416-8455-08d80e3b5f15
X-MS-TrafficTypeDiagnostic: AM7PR03MB6168:
X-Microsoft-Antispam-PRVS: <AM7PR03MB6168C0EA58411E9E5CAE346B86800@AM7PR03MB6168.eurprd03.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-Forefront-PRVS: 0431F981D8
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: Dmcj+KXYjTQdDq3GqHRLkyyc5LPXJ6DqX5axUGEPqmwYO9uKnQnHjDtka+p7tDdjgKdWXzqmOHy3pm4afGWuZRoRzLJAwqfbE+EX+Hubq0x0Xxkm7MEsfM86RRiPCVZd9eu0n2gHPxoZgw1tHYA+LAH4xVNzFbHaMkYVzOhK9e/k+9xD6slplg6xUQEwnM23qXSCvYyR1eiItBU8D/uwpx93SScdTnwI1THj5LdXB+nTB6fc3DUbhYXOLlQXGQ97MwQP5QPcVE+JL/NojurE8614X99P8m8m9PI4naR1eZ8T6eaZ9TPEnYz56+ondrlBEFLuwbWxQm6spdgrIIUoDdO2vmdg7KXZRfoqqxETNnT12JtFRISXtnjpoX343OVO
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR03MB6642.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(346002)(396003)(376002)(366004)(2906002)(316002)(786003)(186003)(31696002)(478600001)(2616005)(52116002)(66476007)(16526019)(6916009)(66556008)(66946007)(4326008)(86362001)(8676002)(31686004)(83380400001)(66574014)(8936002)(6486002)(5660300002)(36756003)(43740500002); DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData: 9ug+cjOOLz2vasUOQLxYyDDXfwy8gVkcN2uc7E7ejvhgVUCxqTFzMdUWtxXwLME0zWzB1ueo5BDQIVz9pF47BHEB30wwEscg6qqBWppFk2LWWHxEmq7TEekyhOmmYKDkxUCumBWFpPHA9xsKMZ+umz+EpMfEF+D/gAAgRYVMNJiw258bNSjnv/P050Y59byOL8uYSz6/91XMwzvQEiVF6WXvsBWIEFrXk9eQ4I4OFzVBuqh0hPYJqJAO1aI3QzhCajtLFw1COTXJ0B9+Oh0XCU4lXAYRUrHZ1mWadgfcXhPY/e2aUz19Kr9Xs9ZMoQxpBmO3T2PJNhM1PyKpItJFqsb53kNWNcEStUwIONDuzbcSl4ojTUpHx4pJ5ejawZ3dZZ0NW2/Q5AgJ79nMwoEgkQ7JmiVKY2Y1rIrWa6aAYI61dabnpnQ/+YiCOqIBVmeYsVjXmA1unMDoIxTjMcCNScFw0jP4nqsUXpFZsLMtOmUQHsS4MgOVmVe/J71vMedLS+gkgfwvIRCSxl5hD19S3E2TGBb0kykG/0ETida2mGE2OA4a1QyaEZpK2x3s58Wr
X-OriginatorOrg: uclouvain.be
X-MS-Exchange-CrossTenant-Network-Message-Id: 701879da-5751-4416-8455-08d80e3b5f15
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2020 19:12:23.5424 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 7ab090d4-fa2e-4ecf-bc7c-4127b4d582ec
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: xXQo8s1D52Zd5YfAv4XONfymbiUEA+fGUJQfxlW9BknVhPgvtGVDXLRjTlK4YlP8D1y/RKwdAT1VSoM9OHuHPsyGqnjzTWQlxVyYLhPkeIN5kIPCFvxgixLWNPcDYfL4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR03MB6168
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/AFZaANQy6vCifc-nPxa3-vwbLVQ>
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:12:29 -0000

Hello,
> 
> 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.

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.

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

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