Re: [multipathtcp] potential MPTCP proxy charter item

<christian.jacquenet@orange.com> Thu, 20 October 2016 06:50 UTC

Return-Path: <christian.jacquenet@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 61119129518 for <multipathtcp@ietfa.amsl.com>; Wed, 19 Oct 2016 23:50:32 -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 gvOGUNEyTaNC for <multipathtcp@ietfa.amsl.com>; Wed, 19 Oct 2016 23:50:30 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE8BD1294F4 for <multipathtcp@ietf.org>; Wed, 19 Oct 2016 23:50:29 -0700 (PDT)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 371DE18CBD0; Thu, 20 Oct 2016 08:50:28 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.33]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 10CE427C064; Thu, 20 Oct 2016 08:50:28 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM42.corporate.adroot.infra.ftgroup ([fe80::d5fd:9c7d:2ee3:39d9%19]) with mapi id 14.03.0319.002; Thu, 20 Oct 2016 08:50:24 +0200
From: christian.jacquenet@orange.com
To: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>, "Olivier.Bonaventure@uclouvain.be" <Olivier.Bonaventure@uclouvain.be>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Thread-Topic: [multipathtcp] potential MPTCP proxy charter item
Thread-Index: AQHSKkDm5UNJQfueOkOQCZciJSJaMaCwIKGAgACb3QCAACXdwA==
Date: Thu, 20 Oct 2016 06:50:24 +0000
Message-ID: <22907_1476946228_58086934_22907_5464_1_a7bca8d2-7656-4ff0-9f01-cf307f017148@OPEXCLILM42.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> <CAO249ydpdtR53VBniDczSt4zj_kk32c2W_FoZKs2XED0Jzk7Jw@mail.gmail.com> <787AE7BB302AE849A7480A190F8B933009D9577B@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009D9577B@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.10.20.55417
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/lbiQ8Jtf03QB_ElRm6YiWsoBM8Q>
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 06:50:32 -0000

WG,

Let me second Med's recent replies to Yoshi, Mirja and Alan. 

I too believe the mptcp WG is the right placeholder to work on an MPTCP extension that can accommodate use cases which are currently being investigated, marketed and - yes - deployed (for some of them, with their procession of already-documented drawbacks (TCP-only communications) and flaws, like QoS-affecting signaling delays) by some operators.

These use cases mainly fall under the so-called hybrid access service offering umbrella, so that end-users can take advantage of various access network technologies for the sake of optimized resource usage, among other incentives.

I also believe MPTCP is the right solution to address such use cases. As I already mentioned a while ago, working on an extension that can facilitate the establishment of MPTCP connections in a network-assisted fashion as we call it in the current Plain Transport Mode option draft will not hinder MPTCP massive adoption but rather encourage it.

I also know there are already prototype implementations of such extension that are currently being tested.

I therefore support the adoption of the MPTCP proxy charter item by the mptcp WG, as this work addresses very concrete and short term use cases that have been publicized by several operators. 

And I think that this WG should start working asap on the set of deliverables mentioned by Med in his recent response to Mirja: MPTCP extension specification, deployment scenarios and operational considerations and DHCP/RADIUS-based provisioning means.

Cheers,

Christian.

-----Message d'origine-----
De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de mohamed.boucadair@orange.com
Envoyé : jeudi 20 octobre 2016 08:15
À : Yoshifumi Nishida; Olivier.Bonaventure@uclouvain.be
Cc : multipathtcp@ietf.org
Objet : Re: [multipathtcp] potential MPTCP proxy charter item

Hi Yoshi, 

The discussion I had with many operators is that they would like to see both TCP and UDP addressed with the ** same solution**. This is why we came up with the proposal to leverage MPTCP for other protocols (UDP, mainly).

So, what I would ideally like to see in the mptcp WG proposed charter is (with "X" being MPTCP):

> 1: Protocol X proxy:
>     It speaks protocol X on behalf of communicating endpoints .
>     From one end's point of view, it looks as if the other end speaks 
> protocol X.

And

> 3:  Protocol X-Y / Protocol Y-X gateway
>      Convert protocol X into protocol Y, or convert protocol Y into 
> protocol X for protocol connectivity/compatibility, etc.

I know Olivier/Stefano have a better name to denote both these cases. 

Cheers,
Med

> -----Message d'origine-----
> De : Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp] Envoyé : 
> mercredi 19 octobre 2016 22:57 À : Olivier.Bonaventure@uclouvain.be Cc 
> : Mirja Kühlewind; BOUCADAIR Mohamed IMT/OLN; multipathtcp@ietf.org 
> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
> 
> Hello,
> 
> On Wed, Oct 19, 2016 at 12:42 PM, Olivier Bonaventure 
> <Olivier.Bonaventure@uclouvain.be> wrote:
> > 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.
> 
> I also think we should not ignore the use case.
> But, I am somehow thinking that we might want to clarify the 
> terminologies a bit more so that we can have more clear focus.
> 
> I might be wrong, but these words give me the following impressions.
> 
> 1: Protocol X proxy:
>     It speaks protocol X on behalf of communicating endpoints .
>     From one end's point of view, it looks as if the other end speaks 
> protocol X.
> 
> 2: Tunneling over protocol X
>      Protocol X carries other protocol Y packets (by using
> encapsulation)  All info in protocol Y (headers, etc) will be 
> preserved.
> 
> 3:  Protocol X-Y / Protocol Y-X gateway
>      Convert protocol X into protocol Y, or convert protocol Y into 
> protocol X for protocol connectivity/compatibility, etc.
>      Some info in the original protocol might be lost due to the 
> conversion.
> 
> If I follow these impressions, it seems that some proposals are close 
> to 3. (again, I might be wrong) I might want to check if we want to 
> clarify this point in the charter or leave it ambiguous.
> I am just wondering if we might need to clarify the terminology or 
> adding some texts to avoid miscommunications.
> 
> Thanks,
> --
> Yoshi
_______________________________________________
multipathtcp mailing list
multipathtcp@ietf.org
https://www.ietf.org/mailman/listinfo/multipathtcp

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.