Re: [multipathtcp] potential MPTCP proxy charter item

<mohamed.boucadair@orange.com> Thu, 20 October 2016 05:59 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 F0D1A129441 for <multipathtcp@ietfa.amsl.com>; Wed, 19 Oct 2016 22:59:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 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, 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 o1vFDyyLAMSc for <multipathtcp@ietfa.amsl.com>; Wed, 19 Oct 2016 22:59:00 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0E8412943F for <multipathtcp@ietf.org>; Wed, 19 Oct 2016 22:58:59 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 5A55432542A; Thu, 20 Oct 2016 07:58:58 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.57]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 36D58238072; Thu, 20 Oct 2016 07:58:58 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0319.002; Thu, 20 Oct 2016 07:58:57 +0200
From: mohamed.boucadair@orange.com
To: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, "Olivier.Bonaventure@uclouvain.be" <Olivier.Bonaventure@uclouvain.be>
Thread-Topic: [multipathtcp] potential MPTCP proxy charter item
Thread-Index: AQHSKkDmbcpIYSt9B0aTZVhfvo8tF6CwGuEAgAC5iJA=
Date: Thu, 20 Oct 2016 05:58:58 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009D95743@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <CCD1A987-0F3C-4775-8B0E-5232965E7E22@nokia.com> <787AE7BB302AE849A7480A190F8B933009D945B7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <428609FE-DE79-45CD-B668-EF95F409B593@tik.ee.ethz.ch> <8bed05c5-9f6f-04aa-8aa8-690aa3ce30f4@uclouvain.be> <D5421B70-5A2B-43C9-966E-632FE5A452EB@tik.ee.ethz.ch>
In-Reply-To: <D5421B70-5A2B-43C9-966E-632FE5A452EB@tik.ee.ethz.ch>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.3]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.10.20.51517
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/nUHyoxqFNavCY7GKA9Kr2aBUMEs>
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: Thu, 20 Oct 2016 05:59:02 -0000

Hi Mirja, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Mirja Kühlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch]
> Envoyé : mercredi 19 octobre 2016 22:36
> À : Olivier.Bonaventure@uclouvain.be
> Cc : BOUCADAIR Mohamed IMT/OLN; multipathtcp@ietf.org
> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
> 
> Hi Olivier,
> 
> I think both cases are valid and interesting for the IETF. The questions
> is where to address them. As I said case 1 could be in scope for MPTCP or
> actually is probably already with the current charter.
> 
> The other question however is, what does the IETF need to do here. I
> believe most of this use case can just be done right now without any
> further actions of the IETF.

[Med] Yes, there are some implementations and even deployments. The feedback from some of these deployments is that, for example, they are suffering from long setup delays of MPTCP connections vs. TCP. For non-TCP solutions, most of deployments require that the same vendor provide both the CPE and the concentrator located in the network side! ... 

Because existing solutions are not optimized and suffer from interoperability issues, there is a need for IETF protocol extensions.   

> 
> I know there is a proposal for an MPTCP extension to support this use
> case. I would recommend to separate this out from the operational
> consideration because specifying the extension is clearly in scope for the
> working group.

[Med] I agree that this should be separated. My take on this is that we need this set of documents: 

* MPTCP extension: Specify the MPTCP option and its usage
* An Informational document on use cases/deployment scenarios and the operational considerations
* MPTCP provisioning DHCP/RADIUS documents. 

> 
> My 2c.
> Mirja
> 
> 
> > Am 19.10.2016 um 21:42 schrieb Olivier Bonaventure
> <Olivier.Bonaventure@uclouvain.be>:
> >
> > Mirja,
> >>
> >> there are two cases to distinguish here:
> >>
> >> 1) you have one or two MPTCP proxies that terminate the TCP connection
> and open a new MPTCP connection
> >
> > There is a very clear demand for this type of solution and there are
> various implementations that are available or are being developped.
> Several deployments exist and there is a large demand for this type of
> services. It would be silly for the IETF to ignore this use case after
> having spent years to specify the Multipath TCP protocol.
> >
> >
> >
> > Olivier