Re: [multipathtcp] potential MPTCP proxy charter item

<mohamed.boucadair@orange.com> Tue, 08 November 2016 07:31 UTC

Return-Path: <mohamed.boucadair@orange.com>
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 56932129412 for <multipathtcp@ietfa.amsl.com>; Mon, 7 Nov 2016 23:31:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.116
X-Spam-Level:
X-Spam-Status: No, score=-4.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 UjEJUlS-AN0x for <multipathtcp@ietfa.amsl.com>; Mon, 7 Nov 2016 23:31:24 -0800 (PST)
Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 631581293E4 for <multipathtcp@ietf.org>; Mon, 7 Nov 2016 23:31:24 -0800 (PST)
Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id CAEE520353; Tue, 8 Nov 2016 08:31:22 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.75]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 9AC891A0051; Tue, 8 Nov 2016 08:31:22 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%18]) with mapi id 14.03.0319.002; Tue, 8 Nov 2016 08:31:22 +0100
From: mohamed.boucadair@orange.com
To: Christoph Paasch <cpaasch@apple.com>, Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Thread-Topic: [multipathtcp] potential MPTCP proxy charter item
Thread-Index: AQHSORNZnemdljzUmEGiGID3gGUCC6DOrtig
Date: Tue, 08 Nov 2016 07:31:21 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009DADEF6@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <73a1c0dd64a843a5baa645d960c82886@rew09926dag03b.domain1.systemhost.net> <b8bfd5c6-21eb-4c4f-879a-851c3a71792a@OPEXCLILM31.corporate.adroot.infra.ftgroup> <56CE164A-9A62-4B57-9CFF-33DBD45BA8B2@gmail.com> <787AE7BB302AE849A7480A190F8B933009D9CA84@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <85D52AE4-FE5F-4977-8927-6BDB72614D07@gmail.com> <787AE7BB302AE849A7480A190F8B933009DAAA88@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <D2630820-7586-4361-A626-3278F22C319C@gmail.com> <87270f12-59ee-3caf-eeef-685195b35dcd@uclouvain.be> <A5256E6E-E2BA-4763-AEF9-3CC50EB432A2@gmail.com> <62c065c9-3ce5-5c46-91f4-41c2f4707f69@uclouvain.be> <20161107162402.GJ3546@Chimay.local>
In-Reply-To: <20161107162402.GJ3546@Chimay.local>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/q9Fv7tou0kQIU7BP7Hal945KY20>
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Subject: Re: [multipathtcp] potential MPTCP proxy charter item
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 08 Nov 2016 07:31:26 -0000

Re-,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de
> Christoph Paasch
> Envoyé : lundi 7 novembre 2016 17:24
> À : Olivier Bonaventure
> Cc : multipathtcp@ietf.org
> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
> 
> Hello,
> 
> On 07/11/16 - 08:56:07, Olivier Bonaventure wrote:
> > > > On 6 Nov 2016, at 21:06, Olivier Bonaventure
> > > > <Olivier.Bonaventure@uclouvain.be
> > > > <mailto:Olivier.Bonaventure@uclouvain.be>> wrote:
> > > >
> > > > The implicit mode was suggested by network operators. The MCP
> resides
> > > > on the path between the CPE and the destination server. The main
> > > > benefit of the implicit mode is that the MCP does not need to
> perform
> > > > any address translation. Given all the complications with NAT, this
> is
> > > > a huge benefit, in particular in IPv6 deployments. In IPv4
> > > > deployments, the CPE can use a single address and there is no need
> for
> > > > a pool of IPv4 addresses on the MCP.
> > > >
> > > > In implicit mode, the MCP needs to distinguish between an MP_CAPABLE
> > > > generated by the endhost and an MP_CAPABLE added by the CPE.
> > >
> > > Broad question - why?
> > >
> > > If the answer is simply “to know when to terminate the MPTCP
> connection”
> > > (i.e. if the end host does it you want it to run all the way to
> > > destination, but if the CPE has done it you want to handle at the
> > > proxy), then thinking out loud here, could the desired behaviour not
> be
> > > achieved by deciding to proxy only based on the SYN/ACK (i.e. based on
> > > the far end’s capabilities) and otherwise be transparently adding
> MPTCP
> > > to /everything/? That way you get even greater MPTCP coverage whilst
> not
> > > interfering with destinations which have already deployed it.
> >
> >
> > The problem is more complex than this because the connecitivity on the
> CPE
> > is not the same as connectivity on the endhost. Consider the following
> > scenario :
> >
> > laptop <-----------+
> >                    |
> > smartphone <----> cpe <-------> mcp <------> server
> >     +              +
> >  cellular1     cellular2
> >
> > The MCP resides on the DSL path between the CPE and the server.
> >
> > The laptop is connected over WiFi and the CPE converts the TCP
> connection
> > onto an MPTCP connection to bond DSL and cellular2.
> >
> > The smartphone is connected over wifi to the cpe which is connected over
> DSL
> > to the server via the MCP. When the smartphone uses MPTCP, it wants to
> use
> > WiFi and cellular1. It could start over WiFi and then moves and want to
> > switch to cellular1. The MCP has no idea of cellular1 and cannot
> terminate
> > an MPTCP connection created by the smartphone.
> 
> I'm not sure, why Alan's suggestion to only proxy based on the SYN/ACK
> doesn't work here.
> 
> There are two scenarios here:
> 
> 1. server supports MPTCP: Then, everything is fine. CPE and MCP will stay
>    out of the business and native MPTCP will be done from smartphone to
>    server.

[Med] Existing network-assisted MPCP documents already cover this case. Native MPTCP connections will be established by that smartphone without even being intercepted by an MCP. The MCP has not to inspect the SYN/ACK. The problem is more on the laptop side. 

Let's consider a TCP connection from that laptop. This TCP connections is relayed to MPTCP via the fixed line, and the intercepted by the MCP. If the MCP withdraws itself because it receives an MP_CAPBLE in the SYN/ACK from the ultimate server, the secondary subflow (via cellular2) may not be established because only private IPv4 addresses may be assigned in that leg (e.g., dedicated APN is used). In this case, the withdrawal of the MCP will lead to more failures. 

This is exactly why I'm advocating for a configurable parameter. 

> 2. server does not support MPTCP: In that case the MCP will announce its
>    public IP to the smartphone and this one can then create an MPTCP-
> subflow
>    via cellular1.
> 
> 
> Christoph
> 
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp