Re: [multipathtcp] towards a potential work item on two-ended proxy
<mohamed.boucadair@orange.com> Tue, 02 August 2016 06:33 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 0514912B035 for <multipathtcp@ietfa.amsl.com>; Mon, 1 Aug 2016 23:33:47 -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 S7tpKETyZ_aE for <multipathtcp@ietfa.amsl.com>; Mon, 1 Aug 2016 23:33:45 -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 1C14E12B004 for <multipathtcp@ietf.org>; Mon, 1 Aug 2016 23:33:45 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 2643022C838 for <multipathtcp@ietf.org>; Tue, 2 Aug 2016 08:33:43 +0200 (CEST)
Received: from localhost.localdomain (unknown [127.0.0.1]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 1905A2380A0 for <multipathtcp@ietf.org>; Tue, 2 Aug 2016 08:33:43 +0200 (CEST)
Received: from omfedm08.si.francetelecom.fr by omfedm08.si.francetelecom.fr with queue id 861931-34 for multipathtcp@ietf.org; Tue, 02 Aug 2016 06:33:43 GMT
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.33]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 0145823809E; Tue, 2 Aug 2016 08:33:43 +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.0301.000; Tue, 2 Aug 2016 08:33:42 +0200
From: mohamed.boucadair@orange.com
To: "philip.eardley@bt.com" <philip.eardley@bt.com>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Thread-Topic: [multipathtcp] towards a potential work item on two-ended proxy
Thread-Index: AdHjZ4nHkoHVP9v7Rwqgdt1DLC/zlgD5RCMAACN7ZwABC2yHYAAdaKBQ
Date: Tue, 02 Aug 2016 06:33:41 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933008DF164A@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <b779dd12f1bb412c96c800eddaaf0247@rew09926dag03b.domain1.systemhost.net> <e2aa6ac517194af4b8c25c07f8e469fb@rew09926dag03b.domain1.systemhost.net> <9cafc779-502e-cc7f-676c-f6659e207c81@uclouvain.be> <5fadd9cfcc01401b84db03052e165c69@rew09926dag03b.domain1.systemhost.net>
In-Reply-To: <5fadd9cfcc01401b84db03052e165c69@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.1]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.8.2.55417
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/KolWYCdSheIQ9RkTD0M2bXptMPQ>
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: Tue, 02 Aug 2016 06:33:48 -0000
Hi Phil, Please see inline. Cheers, Med > -----Message d'origine----- > De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de > philip.eardley@bt.com > Envoyé : lundi 1 août 2016 17:46 > À : multipathtcp@ietf.org > Objet : Re: [multipathtcp] towards a potential work item on two-ended > proxy > > Thanks. > So, for text for a potential work item, we could say something like "the > WG assumes that the HAG is not necessarily on the default routing path > between the end hosts". [Med] Yes, with some modifications to the wording: * Actually, there are many "default" forwarding path*S*; a default forwarding path per network attachment. These default forwarding paths may be completely disjoint. * I suggest to avoid using "HAG" term because it is tied to a specific use case while the proxy work is applicable to a variety of use cases. I prefer much more "MPTCP Concentrator" or "Network-Assisted MPTCP Proxy". This then leaves open whether we solve this > problem in the mptcp-based protocol (as per plain mode) or solve it in the > underlying layer (eg through a tunnel - transparent mode). > Do we assume that the other end of the mptcp segment is on the default > routing path? I suppose this is the case for the CPE example we usually > have in mind - but since we want a general protocol, it would be good if > this end also need not be on the default end-to-end path. [Med] Another approach for this one is the charter to be silent about it, i.e., we don't assume nor preclude it. > > It was also suggested to have a second (informational) document. > As a point of reference, our charter currently says (this is about one- > ended proxy): << The working group will detail what real problems an > MPTCP-enabled middlebox might solve, how it would impact the Multipath TCP > architecture (RFC6182), what proxy approach might be justified as compared > against alternative solutions to the problems, and the likely feasibility > of solving the technical and security issues.>> > So a potential work item may say something like: > The working group will detail the use cases /deployment scenarios, the > operational considerations and .... [anything else? Interaction with > endhost-to-endhost MPTCP?] [Med] I would add protocol extensions to differentiate native MPTCP connections from proxied ones. > > Incidentally, it may be possible to use some of the text from draft-deng- > mptcp-mobile-network-proxy ? > > I also note that draft-boucadair-mptcp-plain-mode has a very open-ended > ipr statement. Do you think it could be made more specific (at some > point)? [Med] FWIW, that IPR does not apply to the current version of the plain-mode draft since a step mentioned in the first claim of that patent deposit is not present in the draft. > > phil > > > -----Original Message----- > From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be] > Sent: 27 July 2016 09:43 > To: Eardley,PL,Philip,TUB8 R <philip.eardley@bt.com>; > multipathtcp@ietf.org > Subject: Re: [multipathtcp] towards a potential work item on two-ended > proxy > > Phil, > > > So far this discussion has made me a bit confused. Let me ask a > > specific > > question:- > > > > Why do we need both transparent and plain mode? If these are > > addressing different usage scenarios, please explain them (in a > > paragraph?) > > The two modes address different deployment scenarios. > > In the transparent mode, the HAG resides on the path to/from the client. > There are many ways in current networks to ensure that the HAG is on the > path of the clients that it serves. The transparent mode requires one > option to distinguish between end-to-end MPTCP connections (directly > established by the client using an MPTCP stack) and proxied connections. > During IETF96, the authors of plain-mode and transparent-mode agreed that > the transparent-mode draft would use an emply plain mode option to > indicate that a connection has been proxied. > > In the plain-mode, the HAG does not need to be on the path to/from the > client. The plain-mode option is used to signal the original > source/destination address of the connection depending on the usage. > > > > > Olivier > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp
- Re: [multipathtcp] towards a potential work item … philip.eardley
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Alan Ford
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … philip.eardley
- Re: [multipathtcp] towards a potential work item … Alan Ford
- Re: [multipathtcp] towards a potential work item … Christoph Paasch
- Re: [multipathtcp] towards a potential work item … David Allan I
- Re: [multipathtcp] towards a potential work item … Markus.Brunner3
- Re: [multipathtcp] towards a potential work item … mohamed.boucadair
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Christoph Paasch
- Re: [multipathtcp] towards a potential work item … Markus.Brunner3
- Re: [multipathtcp] towards a potential work item … mohamed.boucadair
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Alan Ford
- Re: [multipathtcp] towards a potential work item … Markus.Brunner3
- Re: [multipathtcp] towards a potential work item … mohamed.boucadair
- Re: [multipathtcp] towards a potential work item … mohamed.boucadair
- Re: [multipathtcp] towards a potential work item … Alan Ford
- Re: [multipathtcp] towards a potential work item … mohamed.boucadair
- Re: [multipathtcp] towards a potential work item … Christoph Paasch
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Tommy Pauly
- Re: [multipathtcp] towards a potential work item … philip.eardley
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Rao Shoaib
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Ivancic, William D. (GRC-LCA0)
- Re: [multipathtcp] towards a potential work item … philip.eardley
- Re: [multipathtcp] towards a potential work item … Alan Ford
- Re: [multipathtcp] towards a potential work item … mohamed.boucadair
- Re: [multipathtcp] towards a potential work item … Christoph Paasch
- Re: [multipathtcp] towards a potential work item … christian.jacquenet
- Re: [multipathtcp] towards a potential work item … mohamed.boucadair
- Re: [multipathtcp] towards a potential work item … mohamed.boucadair
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Yoshifumi Nishida
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Yoshifumi Nishida
- [multipathtcp] towards a potential work item on t… philip.eardley
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Rao Shoaib
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Rao Shoaib
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Rao Shoaib
- Re: [multipathtcp] towards a potential work item … philip.eardley
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Rao Shoaib
- Re: [multipathtcp] towards a potential work item … Olivier Bonaventure
- Re: [multipathtcp] towards a potential work item … mohamed.boucadair
- Re: [multipathtcp] towards a potential work item … Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] towards a potential work item … Olivier Bonaventure