Re: [multipathtcp] potential MPTCP proxy charter item

<mohamed.boucadair@orange.com> Mon, 07 November 2016 08:15 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 E631F129A58 for <multipathtcp@ietfa.amsl.com>; Mon, 7 Nov 2016 00:15:57 -0800 (PST)
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 Z9kuAPKHU0hm for <multipathtcp@ietfa.amsl.com>; Mon, 7 Nov 2016 00:15:56 -0800 (PST)
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 3F1DB1298B1 for <multipathtcp@ietf.org>; Mon, 7 Nov 2016 00:15:56 -0800 (PST)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 619EF2642C2; Mon, 7 Nov 2016 09:15:53 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.18]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 3A9A923806C; Mon, 7 Nov 2016 09:15:53 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0319.002; Mon, 7 Nov 2016 09:15:53 +0100
From: <mohamed.boucadair@orange.com>
To: "cpaasch@apple.com" <cpaasch@apple.com>
Thread-Topic: [multipathtcp] potential MPTCP proxy charter item
Thread-Index: AQHSNseHayJRa0DxWkKm1qMiPvLa9aDNLzzQ
Date: Mon, 7 Nov 2016 08:15:52 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009DAD3FC@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> <B7D8197F-D833-41BB-A4A4-D6F31A3B8993@tik.ee.ethz.ch> <787AE7BB302AE849A7480A190F8B933009DAC5DE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <EBFA61A5-4A9E-4B41-BDC1-4F9056241D70@gmail.com> <20161104181615.GP40488@Chimay.local>
In-Reply-To: <20161104181615.GP40488@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
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/GnQA0IEStHqPsy6_A3nAj5bil9w>
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: Mon, 07 Nov 2016 08:15:58 -0000

Hi Christoph, 

The point is that we need to meet the following requirements to signal that information:
* avoid extra delay to establish the MPTCP connections
* allow for variable data to be exchanged
* multiple instances of the same data structure to be included
* no interference with TFO
* ensure interoperability between MPTCP host/proxy, or MPTCP proxy/proxy

Defining the data structure as an option allows up to deterministically treat them as part of the connection control, not part of the data to be delivered to an application.

Cheers,
Med

> -----Message d'origine-----
> De : cpaasch@apple.com [mailto:cpaasch@apple.com]
> Envoyé : vendredi 4 novembre 2016 19:16
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : multipathtcp@ietf.org; Alan Ford
> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
> 
> Hello,
> 
> On 04/11/16 - 11:02:02, Alan Ford wrote:
> > > On 4 Nov 2016, at 10:12, <mohamed.boucadair@orange.com>
> <mohamed.boucadair@orange.com> wrote:
> > >> -----Message d'origine-----
> > >> De : Mirja Kühlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch]
> > >> Envoyé : vendredi 4 novembre 2016 10:34
> > >> À : BOUCADAIR Mohamed IMT/OLN; Alan Ford
> > >> Cc : multipathtcp@ietf.org
> > >> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
> > >>
> > >> Hi all,
> > >>
> > >> first, I agree with Alan that such a signal does not need to/should
> not be
> > >> part of the MPTCP protocol.
> > >
> > > [Med] Defining another channel to carry the signal "I want to be
> MPTCP-proxied" outside the MPTCP normal channel will import the same set
> of hindrances we had with MPTCP design for middlebloxes traversal. The use
> of MPTCP to convey the "I want to be MPTCP-proxied" leverages on base
> MPTCP to detect "unfriendly MPTCP" in-path nodes. That's a pragmatic
> engineering design.
> >
> > The MP_CONVERT signal has multiple purposes. When signalled with a
> target IP address in explicit mode, it is a pure application-layer signal,
> and is separate from the MPTCP connection entering the MCP.
> >
> > In implicit mode this is indeed at a slightly different layer, and yes,
> you are asking the network to do something. But it’s still not a necessary
> part of the MPTCP protocol to make this happen. This is similar to a
> transparent HTTP proxy, or to a NAT - neither requires any changes to HTTP
> or TCP/IP to work.
> >
> > You could detect MPTCP SYNs and see if your signal is present. If you
> don’t want to be inspecting every MPTCP SYN in implicit mode, use an
> existing standard - I suggest RAO. Given this is a controlled environment,
> you shouldn’t have any deployment concerns here.
> >
> > If RAO is not appropriate for some reason, I might be persuaded that a
> flag in the MP_CAPABLE that says “proxies should inspect this” could be
> added to the base protocol. However, the rest of the protocol - i.e. the
> MP_CONVERT signal - is application-layer and outside MPTCP.
> >
> > Ultimately MPTCP Proxying is an application of MPTCP and should be
> defined as such.
> 
> I'm also late on this thread. But just want to reiterate what I already
> mentioned before in July.
> 
> I also think that proxying between different transport-layer protocols is
> not
> an MPTCP-specific operation and as such should not be tied to MPTCP.
> Making it independent of MPTCP would be much better as it allows to proxy
> across any kind of transport protocol. So, let's just put it (as already
> suggested) in the payload, without linking it to MPTCP.
> 
> 
> Christoph