Re: [multipathtcp] potential MPTCP proxy charter item

<mohamed.boucadair@orange.com> Fri, 28 October 2016 06:45 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 9C53A129464 for <multipathtcp@ietfa.amsl.com>; Thu, 27 Oct 2016 23:45:02 -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 NWYCroeSrFIt for <multipathtcp@ietfa.amsl.com>; Thu, 27 Oct 2016 23:44:59 -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 4A6D112945A for <multipathtcp@ietf.org>; Thu, 27 Oct 2016 23:44:59 -0700 (PDT)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 1E9EA3B406F; Fri, 28 Oct 2016 08:44:57 +0200 (CEST)
Received: from localhost.localdomain (unknown [127.0.0.1]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 105C935C070; Fri, 28 Oct 2016 08:44:57 +0200 (CEST)
Received: from omfedm05.si.francetelecom.fr by omfedm05.si.francetelecom.fr with queue id 878065-31; Fri, 28 Oct 2016 06:44:56 GMT
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.41]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id E880A35C061; Fri, 28 Oct 2016 08:44:56 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0319.002; Fri, 28 Oct 2016 08:44:54 +0200
From: <mohamed.boucadair@orange.com>
To: "philip.eardley@bt.com" <philip.eardley@bt.com>, "mirja.kuehlewind@tik.ee.ethz.ch" <mirja.kuehlewind@tik.ee.ethz.ch>, JACQUENET Christian IMT/OLN <christian.jacquenet@orange.com>
Thread-Topic: [multipathtcp] potential MPTCP proxy charter item
Thread-Index: AQHSKLyB5UNJQfueOkOQCZciJSJaMaCttfyggACVTQCAAdRHAIAAFN6AgACb3ACAAAnwAIAINA6AgAFX9TCAAxN9cA==
Date: Fri, 28 Oct 2016 06:44:53 +0000
Message-ID: <b8bfd5c6-21eb-4c4f-879a-851c3a71792a@OPEXCLILM31.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> <22907_1476946228_58086934_22907_5464_1_a7bca8d2-7656-4ff0-9f01-cf307f017148@OPEXCLILM42.corporate.adroot.infra.ftgroup> <57543A7A-1542-4C60-A5D3-E1658354BE5A@tik.ee.ethz.ch> <73a1c0dd64a843a5baa645d960c82886@rew09926dag03b.domain1.systemhost.net>
In-Reply-To: <73a1c0dd64a843a5baa645d960c82886@rew09926dag03b.domain1.systemhost.net>
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="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.6.17.114517
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/_xIUUfmUYutnztSkCrJFlIrSHG0>
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: Fri, 28 Oct 2016 06:45:02 -0000

Hi Phil, 

I remember, as well :-)

The drafts were completely rewritten to take into considerations the comments and also to help the chartering effort. Here is the set of the Network-Assisted MPTCP documents:

* An MPTCP Option for Network-Assisted MPTCP: https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-09 
* Network-Assisted MPTCP: Use Cases, Deployment Scenarios and Operational Considerations: https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-00 
* DHCP Options for Network-Assisted Multipath TCP: https://tools.ietf.org/html/draft-boucadair-mptcp-dhc-06 
* RADIUS Extensions for Network-Assisted Multipath TCP: https://tools.ietf.org/html/draft-boucadair-mptcp-radius-03 

Questions, comments and suggestions are more than welcome!

Cheers,
Med

> -----Message d'origine-----
> De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de
> philip.eardley@bt.com
> Envoyé : mercredi 26 octobre 2016 10:13
> À : mirja.kuehlewind@tik.ee.ethz.ch; JACQUENET Christian IMT/OLN
> Cc : multipathtcp@ietf.org
> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
> 
> Hi,
> I remember in Berlin discussion about a new /merged version of Med and
> Olivier's drafts - with a nice description of the protocol model to make
> it easier to understand (both the high-level approach, and the assumptions
> - especially as these are different to those of RFC6824). I think this
> would make it easier to write text for a new charter item. (at least my
> attempt to write a new charter item a while back was inaccurate
> /inadequate).  Is this possible please?
> I agree we want this work to happen - it's great to see MPTCP being widely
> used and we want standardisation.
> 
> Best wishes
> Phil.
> 
> -----Original Message-----
> From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of
> Mirja Kühlewind
> Sent: 25 October 2016 13:07
> To: christian.jacquenet@orange.com
> Cc: multipathtcp@ietf.org
> Subject: Re: [multipathtcp] potential MPTCP proxy charter item
> 
> Hi all, hi Christian,
> 
> see below.
> 
> > Am 20.10.2016 um 08:50 schrieb christian.jacquenet@orange.com:
> >
> > 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 agree that these use case are interesting and work is needed here. See
> further below.
> 
> >
> > I also believe MPTCP is the right solution to address such use cases.
> 
> As I mention previously there are two very different deployment scenarios:
> a connection-terminating MPTCP proxy or a MPTCP tunnel solution. In
> general using TCP as a tunneling technology is challenging and has a
> broader scope than just MPTCP.
> 
> 
> > 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.
> 
> An MPTCP extension specification is clearly in scope for MPTCP and can be
> done right now without a charter change.
> 
> I’m not sure if deployment scenarios need to be documented (in an RFC). As
> you said above there are already prototype and some real deployments as
> well. Not sure why we need additional documentation here.
> 
> Operational consideration might or might not below in the MPTCP working
> group. However, there is the BANANA BoF in Seoul that will discuss hybrid-
> access services (and different approach to provide this service).
> Depending where this effort goes that might be a better home or some wg in
> intarea.
> 
> DHCP/RADIUS extension go into the DHC working group. They are charter to
> specify these kind of extensions and you can start this work there
> immediately.
> 
> I’m not saying we shouldn’t do this work; I’m just saying that MPTCP might
> not be the right group for all parts of this work. This is my
> recommendation as transport AD but I’m sure a rechartering discussion in
> the IESG would provide similar feedback.
> 
> Mirja
> 
> 
> 
> >
> > 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.
> >
> > _______________________________________________
> > multipathtcp mailing list
> > multipathtcp@ietf.org
> > https://www.ietf.org/mailman/listinfo/multipathtcp
> 
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp