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

"Henderickx, Wim (Nokia - BE)" <wim.henderickx@nokia.com> Tue, 02 August 2016 19:38 UTC

Return-Path: <wim.henderickx@nokia.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 4FBBE12D8BB for <multipathtcp@ietfa.amsl.com>; Tue, 2 Aug 2016 12:38:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 fkg_MaiGh5SD for <multipathtcp@ietfa.amsl.com>; Tue, 2 Aug 2016 12:38:14 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 039CE12D8F7 for <multipathtcp@ietf.org>; Tue, 2 Aug 2016 12:32:47 -0700 (PDT)
Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id F05D0D4D46CE4; Tue, 2 Aug 2016 19:32:42 +0000 (GMT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u72JWjEv020297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Aug 2016 19:32:46 GMT
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u72JVYWm008100 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Aug 2016 21:32:43 +0200
Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.82]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 2 Aug 2016 21:31:56 +0200
From: "Henderickx, Wim (Nokia - BE)" <wim.henderickx@nokia.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "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: AQHR7PSH+H5KVobs2E61DPJLQEiUPQ==
Date: Tue, 2 Aug 2016 19:31:56 +0000
Message-ID: <B32077BE-B7E9-4E89-BEAF-75E62C8A1AB2@nokia.com>
References: <b779dd12f1bb412c96c800eddaaf0247@rew09926dag03b.domain1.systemhost.net> <e2aa6ac517194af4b8c25c07f8e469fb@rew09926dag03b.domain1.systemhost.net> <9cafc779-502e-cc7f-676c-f6659e207c81@uclouvain.be> <5fadd9cfcc01401b84db03052e165c69@rew09926dag03b.domain1.systemhost.net> <787AE7BB302AE849A7480A190F8B933008DF164A@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933008DF164A@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Accept-Language: nl-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/0.0.0.151008
x-originating-ip: [135.239.27.41]
Content-Type: text/plain; charset="utf-8"
Content-ID: <09C78CCC9D0CD34EA93F428EFF2EB642@exchange.lucent.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/Cs0GsJC4uy-H4PTWadkF3345RQA>
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 19:38:16 -0000





On 02/08/16 08:33, "multipathtcp on behalf of mohamed.boucadair@orange.com" <multipathtcp-bounces@ietf.org on behalf of mohamed.boucadair@orange.com> wrote:

>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".  

WH> Indeed Network-assisted MPTCP proxy seems like a good terminology
>
>  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.  
WH> agreed, we should have the charter focus on single ended MP-TCP and network assisted MP-TCP proxies e.g.
>     
>
>> 
>> 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.
WH> agreed
> 
>
>> 
>> 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>om>;
>> 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
>
>_______________________________________________
>multipathtcp mailing list
>multipathtcp@ietf.org
>https://www.ietf.org/mailman/listinfo/multipathtcp