Re: [multipathtcp] towards a potential work item on two-ended proxy

<mohamed.boucadair@orange.com> Thu, 04 August 2016 06:22 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 1D9C212B01D for <multipathtcp@ietfa.amsl.com>; Wed, 3 Aug 2016 23:22:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level:
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 Nqk11G1IhqBu for <multipathtcp@ietfa.amsl.com>; Wed, 3 Aug 2016 23:22:38 -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 8F77C126FDC for <multipathtcp@ietf.org>; Wed, 3 Aug 2016 23:22:37 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id A5E242DC3FC; Thu, 4 Aug 2016 08:22:35 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.41]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 832DC238073; Thu, 4 Aug 2016 08:22:35 +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.0301.000; Thu, 4 Aug 2016 08:22:35 +0200
From: <mohamed.boucadair@orange.com>
To: Tommy Pauly <tpauly@apple.com>, "Henderickx, Wim (Nokia - BE)" <wim.henderickx@nokia.com>
Thread-Topic: [multipathtcp] towards a potential work item on two-ended proxy
Thread-Index: AQHR6/78+H5KVobs2E61DPJLQEiUPaA0T3oAgAAn1gCAARlmAIAAeo6AgACqOQCAAOR5AIAANaSAgACCsGA=
Date: Thu, 4 Aug 2016 06:22:34 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933008DFEBF8@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <b779dd12f1bb412c96c800eddaaf0247@rew09926dag03b.domain1.systemhost.net> <e2aa6ac517194af4b8c25c07f8e469fb@rew09926dag03b.domain1.systemhost.net> <9cafc779-502e-cc7f-676c-f6659e207c81@uclouvain.be> <3100ff74-0c7d-1815-03a1-aa4cec36d1e4@oracle.com> <3D8D4118-39CA-46A6-BFBD-026376C02058@nokia.com> <811b2c78-0976-6994-d759-8cac5fa58864@oracle.com> <0084773F-53E5-41A4-A244-430DAF12322A@nokia.com> <E0278B51-F3D8-4762-B597-41959E7BCF12@gmail.com> <08A92759-0446-440B-A76E-2E89518E1336@nokia.com> <F9F23B1F-D802-4971-857F-4BF455EDCF5D@gmail.com> <FCC775C9-EA48-4E7D-A48D-3059C255569A@nokia.com> <4221AE86-54DA-4177-91B5-D1A03C101F71@apple.com>
In-Reply-To: <4221AE86-54DA-4177-91B5-D1A03C101F71@apple.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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008DFEBF8OPEXCLILMA3corp_"
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/cLUX6gxETxzRDUd6uilXzyxrge4>
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy
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, 04 Aug 2016 06:22:45 -0000

Dear Tommy,

The problem we have is how to glue multiple TCP connections established among multiple access networks while avoiding making any assumptions about the capabilities of end-users terminals and remote servers: This is a ** multipath TCP ** problem that we called “Network-assisted MPTCP”.

In addition to that problem, we have additional requirements such as:

·         Avoid extra delay to establish TCP sessions among multiple access networks compared to legacy TCP connections.

·         Optimize the load on the network-assisted Proxy (avoid chatty protocols, in particular)

·         Avoid interfering with native MPTCP connections.

·         Have one solution for both IPv4 and IPv6 + Do not make any assumption about the addressing scheme of available network attachment

·         …

Our MPTCP solution to this MPTCP problem is to define a dedicated MPTCP option.

We have investigated various tracks but we believe the MPTCP option is the right MPTCP solution to our MPTCP problem, e.g.,

·         One can optimize SOCKS to reduce the amount of exchanges, but still this out-of-band signaling and at least one RTT will be required to create a new MPTCP connection.

·         One can define an IP option to carry the information we have in the plain-mode but as you know “IP Options are not an option”!

·         One can define an IPv6 Extension Header but this extension imposes certain addressing schemes on access networks. This is not a starting point.

·         One can define an SDP extension but this is specific to that application: https://tools.ietf.org/html/draft-ietf-avtcore-mprtp-03

FWIW, the charter of the MPTCP WG already cites the proxy work.

Cheers,
Med

De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de Tommy Pauly
Envoyé : jeudi 4 août 2016 02:10
À : Henderickx, Wim (Nokia - BE)
Cc : multipathtcp@ietf.org
Objet : Re: [multipathtcp] towards a potential work item on two-ended proxy


On Aug 3, 2016, at 11:58 AM, Henderickx, Wim (Nokia - BE) <wim.henderickx@nokia.com<mailto:wim.henderickx@nokia.com>> wrote:

Alan, in-line

From: Alan Ford <alan.ford@gmail.com<mailto:alan.ford@gmail.com>>
Date: Wednesday 3 August 2016 at 09:20
To: Wim Henderickx <wim.henderickx@nokia.com<mailto:wim.henderickx@nokia.com>>
Cc: Rao Shoaib <rao.shoaib@oracle.com<mailto:rao.shoaib@oracle.com>>, "multipathtcp@ietf.org<mailto:multipathtcp@ietf.org>" <multipathtcp@ietf.org<mailto:multipathtcp@ietf.org>>
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy

Hi Wim, all,

Comment inline...

On 2 Aug 2016, at 20:11, Henderickx, Wim (Nokia - BE) <wim.henderickx@nokia.com<mailto:wim.henderickx@nokia.com>> wrote:
On 02/08/16 15:52, "Alan Ford" <alan.ford@gmail.com<mailto:alan.ford@gmail.com>> wrote:


I’m trying to distinguish the various use cases; can we confirm this is correct?

Transparent Mode
- Source address = real source address
WH> not always since NAT can be in the path

- Destination address = real destination address
- Transparent proxies create MPTCP functionality in the stream, adding and removing the MPTCP headers, mapping seq numa, etc
- Latest proposal is to add an indicator to say “this is proxied” so that a proxy can intercept it
WH> indeed or not intercept it based on the indication


Plain Mode
- Source address = real source
WH> could also be NATed in some use cases

- Destination address = proxy destination address
- Signalling protocol inside indicates real destination address
WH> or SRC address


So - please correct me if this is wrong - but the main difference is that Plain Mode is targeted towards a proxy server whereas the transparent mode does not change src/dst addresses?
WH> the main difference is mainly DST IP is changed to get explicit routing to the proxy versus being implicit in the transparent case

OK, so my understanding appears correct here.
WH> yes


The issue I see with a generic proxy bit is that it does not contain any context about what kind of proxy is being intercepted. You could be sending in good faith expecting it to be picked up by Proxy from Operator A, but in fact is picked up by Operator B.
WH> the network assisted proxy is mainly targeting single operator/controlled operator use cases to avoid these issues.


As I’ve said before, the plain mode option is not MPTCP-specific and is simple a signal that says “everything that follows is actually targeted for IP address a.b.c.d” - this is entirely transport-agnostic. If the HAG could know where to find a proxy (e.g. a well-known anycast address) then addresses could be rewritten and packets forwarded, with no need for any MPTCP protocol changes.
WH> you would still need to know the original destination IP@ that the application wanted to go to.

Which is the point of the signalling protocol - the proposed “plain mode option” which is actually carried in the payload. My issue with this is that this is _not MPTCP-specific_. This is simply a signal above the transport layer to inform a proxy what the real destination is.

WH> I hear, you and I understand but we have an explicit use case for this with MPTCP and so far not in any other protocol. Hence I think it is good to extend MPTCP with this capability and liase with other WG(s) about this.

While you may have a use-case for having proxies work with your MPTCP solution, it does not directly follow that the MPTCP protocol or WG is the best place to specify how the proxy works. This really does seem like a proxy solution that can be made more generic, and at the very least belongs as a protocol that is run within the MPTCP stream. This is what the SOCKS protocol does, and there is no reason you can't run SOCKS over MPTCP, or create a new variant of SOCKS or a similar protocol that you will run on top of MPTCP for your solution. Indeed, it could be seen as a benefit to work on the proxying solution independently from MPTCP, since that way it can be used for other transports. The end result will be the same, and the architecture will be cleaner.

Best,
Tommy Pauly



Regards,
Alan

_______________________________________________
multipathtcp mailing list
multipathtcp@ietf.org<mailto:multipathtcp@ietf.org>
https://www.ietf.org/mailman/listinfo/multipathtcp