Re: [multipathtcp] potential MPTCP proxy charter item

<mohamed.boucadair@orange.com> Thu, 20 October 2016 06:14 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 27C9112986E for <multipathtcp@ietfa.amsl.com>; Wed, 19 Oct 2016 23:14:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.031
X-Spam-Level:
X-Spam-Status: No, score=-3.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.431, 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 qGA3qKREdr_C for <multipathtcp@ietfa.amsl.com>; Wed, 19 Oct 2016 23:14:53 -0700 (PDT)
Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4992512952E for <multipathtcp@ietf.org>; Wed, 19 Oct 2016 23:14:53 -0700 (PDT)
Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 996FD20F18; Thu, 20 Oct 2016 08:14:51 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 7068E1A0066; Thu, 20 Oct 2016 08:14:51 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0319.002; Thu, 20 Oct 2016 08:14:51 +0200
From: mohamed.boucadair@orange.com
To: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>, "Olivier.Bonaventure@uclouvain.be" <Olivier.Bonaventure@uclouvain.be>
Thread-Topic: [multipathtcp] potential MPTCP proxy charter item
Thread-Index: AQHSKkDmbcpIYSt9B0aTZVhfvo8tF6CwIKGAgAC5KMA=
Date: Thu, 20 Oct 2016 06:14:50 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009D9577B@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> <CAO249ydpdtR53VBniDczSt4zj_kk32c2W_FoZKs2XED0Jzk7Jw@mail.gmail.com>
In-Reply-To: <CAO249ydpdtR53VBniDczSt4zj_kk32c2W_FoZKs2XED0Jzk7Jw@mail.gmail.com>
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
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/uyFoThUk3Z53MWqA2NIBfpvbTqg>
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 06:14:55 -0000

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