Re: [multipathtcp] potential MPTCP proxy charter item

"Henderickx, Wim (Nokia - BE)" <wim.henderickx@nokia.com> Wed, 19 October 2016 04:05 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 4DFFA12943F for <multipathtcp@ietfa.amsl.com>; Tue, 18 Oct 2016 21:05:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.421
X-Spam-Level:
X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-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 32J2e92xHu4n for <multipathtcp@ietfa.amsl.com>; Tue, 18 Oct 2016 21:05:21 -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 D079D1293F4 for <multipathtcp@ietf.org>; Tue, 18 Oct 2016 21:05:20 -0700 (PDT)
Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id EFBDE2C334298; Wed, 19 Oct 2016 04:05:17 +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 u9J45IWS005731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Oct 2016 04:05:18 GMT
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u9J45HGm017771 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Oct 2016 06:05:17 +0200
Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.176]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Wed, 19 Oct 2016 06:05:17 +0200
From: "Henderickx, Wim (Nokia - BE)" <wim.henderickx@nokia.com>
To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= <mirja.kuehlewind@tik.ee.ethz.ch>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
Thread-Topic: [multipathtcp] potential MPTCP proxy charter item
Thread-Index: AQHSKLyB5UNJQfueOkOQCZciJSJaMQ==
Date: Wed, 19 Oct 2016 04:05:16 +0000
Message-ID: <F5B9F91E-23D1-4B1B-8963-684EA7C10AD9@nokia.com>
References: <CCD1A987-0F3C-4775-8B0E-5232965E7E22@nokia.com> <787AE7BB302AE849A7480A190F8B933009D945B7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <428609FE-DE79-45CD-B668-EF95F409B593@tik.ee.ethz.ch>
In-Reply-To: <428609FE-DE79-45CD-B668-EF95F409B593@tik.ee.ethz.ch>
Accept-Language: nl-BE, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1b.0.161010
x-originating-ip: [135.239.27.38]
Content-Type: text/plain; charset="utf-8"
Content-ID: <43767A0D4CA91D44BCF800AD05DBF305@exchange.lucent.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/oSsH1ls1d0De0zm9idzgN2FFEqA>
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: Wed, 19 Oct 2016 04:05:23 -0000

Case 1 is a mandatory 
I would like to see case 2 as well, but I agree on coordination

On 18/10/2016, 17:46, "Mirja Kühlewind" <mirja.kuehlewind@tik.ee.ethz.ch> wrote:

    Hi Med, hi all,
    
    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
    
    2) you tunnel other traffic over MPTCP
    
    Case two is using TCP as a tunneling mechanism. This is discussed in several working groups for different purposes and is not very straight-forward in a lot of cases. Such an approach definitely needs coordination and transport as well as tunnel expertise.
    
    Which case are you talking about? While Phil’s proposal sounded rather like case 1, your proposal sounds very much like case 2.
    
    Mirja
    
    
    > Am 18.10.2016 um 07:52 schrieb mohamed.boucadair@orange.com:
    > 
    > Hi Wim,
    >  
    > Yes, this can be main stream.
    >  
    > Cheers,
    > Med
    >  
    > De : Henderickx, Wim (Nokia - BE) [mailto:wim.henderickx@nokia.com] 
    > Envoyé : lundi 17 octobre 2016 23:22
    > À : BOUCADAIR Mohamed IMT/OLN; philip.eardley@bt.com; multipathtcp@ietf.org
    > Objet : Re: [multipathtcp] potential MPTCP proxy charter item
    >  
    > Sorry for the late reply, but more in-line
    >  
    > From: multipathtcp <multipathtcp-bounces@ietf.org> on behalf of "mohamed. boucadair" <mohamed.boucadair@orange.com>
    > Date: Friday, 7 October 2016 at 09:08
    > To: "philip.eardley@bt.com" <philip.eardley@bt.com>om>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>
    > Subject: Re: [multipathtcp] potential MPTCP proxy charter item
    >  
    > Hi Phil,
    >  
    > Please see inline.
    >  
    > Cheers,
    > Med
    >  
    > De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de philip.eardley@bt.com
    > Envoyé : lundi 8 août 2016 11:50
    > À : multipathtcp@ietf.org
    > Objet : [multipathtcp] potential MPTCP proxy charter item
    >  
    > I had thought a potential charter item could be something on the lines of:
    > <Experimental Extensions to the MPTCP protocol to enable an MPTCP-aware middlebox to act as an MPTCP proxy for an end host, which runs TCP. One or both end hosts may be MPTCP-unaware, and the MPTCP proxy(s) is (are) not necessarily on the default routing path(s). The working group will also detail, in an Informational document, the use cases /deployment scenarios and the operational considerations.>
    >  
    > [Med] I would like to see the charter includes the following; “The working group will also edit Network-Assisted Multipath provisioning documents. In particular, the WG will specify DHCP options and RADIUS attributes for MPTCP.” 
    >  
    >  
    > WH> I am fine with this, but why do we state experimental extensions? Why is this not main stream?
    > However, if I get the discussion right, this is not quite right.
    > * assume a controlled environment (to avoid a problem where the message reaches the ‘wrong’ proxy) (IETF usually prefers generally applicable protocols)
    > * assume some (?additional) ‘header swapping’ protocol and a new signalling protocol (not an mptcp extension – so probably in INTAREA WG’s remit)
    > [Med] IMHO, it is not odd to document in the mptcp wg how a Network-Assisted MPTCP solution can also be applicable to other protocols (UDP in particular). This work can be done jointly/closely with other WGs. The important point is whether there is enough interest from the mptpcp WG members to work on this.
    > WH> indeed is to specify the means in MPTCP WG and other WG can be consulted to review the work. If you split it out it becomes less efficient from a protocol perspective.
    > If the above is roughly right, then I think some extra work is needed before we can get a clear charter item. Can some of the work that isn’t mptcp extensions be cleanly separated out? Can you be clear what deployment assumptions are being made (and preferably reduce them, so there is wider applicability). Personally I’d also find it very helpful if the plain/transparent ‘merged’ draft could try and follow the guidance about protocol models in RFC4101 (personally I found the plain mode doc difficult to understand).
    >  
    > Thanks
    > phil
    >  
    >  
    >  
    > _______________________________________________
    > multipathtcp mailing list
    > multipathtcp@ietf.org
    > https://www.ietf.org/mailman/listinfo/multipathtcp