From nobody Wed Dec 7 05:15:16 2016 Return-Path: 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 C24741299DF for ; Wed, 7 Dec 2016 05:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.515 X-Spam-Level: X-Spam-Status: No, score=-5.515 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, RP_MATCHES_RCVD=-2.896, 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 0p3vudhXtYHV for ; Wed, 7 Dec 2016 05:15:13 -0800 (PST) Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 349241299C3 for ; Wed, 7 Dec 2016 05:11:35 -0800 (PST) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id C2A84C0497 for ; Wed, 7 Dec 2016 14:11:33 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.13]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 955261A006D for ; Wed, 7 Dec 2016 14:11:33 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6D.corporate.adroot.infra.ftgroup ([fe80::54f9:a6c3:c013:cbc7%19]) with mapi id 14.03.0319.002; Wed, 7 Dec 2016 14:11:33 +0100 From: To: "multipathtcp@ietf.org" Thread-Topic: I-D Action: draft-nam-mptcp-deployment-considerations-01.txt Thread-Index: AQHSUIpONQuBaGyH2UCmYp8DkH9OnqD8c/EQ Date: Wed, 7 Dec 2016 13:11:33 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DCA6F6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <148111579370.13598.17631444757073795074.idtracker@ietfa.amsl.com> In-Reply-To: <148111579370.13598.17631444757073795074.idtracker@ietfa.amsl.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.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] TR: I-D Action: draft-nam-mptcp-deployment-considerations-01.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 13:15:14 -0000 Dear all,=20 A new version of this draft is available online. This version integrates th= e comments raised on the mailing list, in particular: =20 * Add a new section to cover the DC proxy case * Clarify the need to distinguish proxied MPTCP connections vs. native ones= .=20 * Add a new section to discuss how the proxy can be offloaded in favor of e= 2e communications.=20 * Add some text to document complications that may arise if the proxy is re= moved blindly for the path when both client and server are MPTCP-capable.=20 I would like to thank Alan for many offline discussions. Much appreciated! I do think this version is stable to consider WG adoption.=20 As always comments, questions and suggestions are more than welcome. Cheers, Med > -----Message d'origine----- > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de > internet-drafts@ietf.org > Envoy=E9=A0: mercredi 7 d=E9cembre 2016 14:03 > =C0=A0: i-d-announce@ietf.org > Objet=A0: I-D Action: draft-nam-mptcp-deployment-considerations-01.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : Network-Assisted MPTCP: Use Cases, Deployment > Scenarios and Operational Considerations > Authors : Mohamed Boucadair > Christian Jacquenet > Olivier Bonaventure > Wim Henderickx > Robert Skog > Filename : draft-nam-mptcp-deployment-considerations-01.txt > Pages : 29 > Date : 2016-12-07 >=20 > Abstract: > Network-Assisted MPTCP deployment models are designed to facilitate > the adoption of MPTCP for the establishment of multi-path > communications without making any assumption about the support of > MPTCP by the communicating peers. MPTCP Conversion Points (MCPs) > located in the network are responsible for establishing multi-path > communications on behalf of endpoints, thereby taking advantage of > MPTCP capabilities to achieve different goals that include (but are > not limited to) optimization of resource usage (e.g., bandwidth > aggregation), of resiliency (e.g., primary/backup communication > paths), and traffic offload management. >=20 > This document describes Network-Assisted MPTCP uses cases, deployment > scenarios, and operational considerations. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-nam-mptcp-deployment- > considerations/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-01 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-nam-mptcp-deployment- > considerations-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Dec 7 06:41:11 2016 Return-Path: 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 88C99129EDD for ; Wed, 7 Dec 2016 06:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.707 X-Spam-Level: X-Spam-Status: No, score=-3.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, 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 OMsfZTLPWled for ; Wed, 7 Dec 2016 06:41:08 -0800 (PST) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73007129F53 for ; Wed, 7 Dec 2016 06:40:30 -0800 (PST) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id A0EDE1001C4; Wed, 7 Dec 2016 15:40:28 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.75]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 7EF9D4004C; Wed, 7 Dec 2016 15:40:28 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%18]) with mapi id 14.03.0319.002; Wed, 7 Dec 2016 15:40:23 +0100 From: To: "draft-ietf-mptcp-rfc6824bis@tools.ietf.org" Thread-Topic: draft-ietf-mptcp-rfc6824bis Thread-Index: AdJQl9RXHVIAAVm+Qiyr4JQGcXkqlw== Date: Wed, 7 Dec 2016 14:40:22 +0000 Message-ID: <81bb9dea-ea02-420e-b4de-3ffe4c72e685@OPEXCLILMA4.corporate.adroot.infra.ftgroup> 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: multipart/alternative; boundary="_000_81bb9deaea02420eb4de3ffe4c72e685OPEXCLILMA4corporateadr_" MIME-Version: 1.0 Archived-At: Cc: "multipathtcp@ietf.org" Subject: [multipathtcp] draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 14:41:10 -0000 --_000_81bb9deaea02420eb4de3ffe4c72e685OPEXCLILMA4corporateadr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alan, all, It seems that some fixes are needed in https://tools.ietf.org/html/draft-ie= tf-mptcp-rfc6824bis-07#section-3.1 given that C-bit has now a meaning: =3D=3D D through H: The remaining bits, labeled "C" through "H", are used for crypto algorithm negotiation. Currently only the rightmost bit, labeled "H", is assigned. Bit "H" indicates the use of HMAC- SHA1 (as defined in Section 3.2). An implementation that only supports this method MUST set bit "H" to 1, and bits "C" through "G" to 0. A crypto algorithm MUST be specified. If flag bits C through H are all 0, the MP_CAPABLE option MUST be treated as invalid and ignored (that is, it must be treated as a regular TCP handshake). .. =3D=3D=3D=3D Also, https://tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis-07#section-8.= 2 needs to be updated. Thank you. Cheers, Med --_000_81bb9deaea02420eb4de3ffe4c72e685OPEXCLILMA4corporateadr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alan, all,

 

It seems that some fixes are needed in https://tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis-07#section-3.1 = given that C-bit has now a meaning:

 

=3D=3D

   D through H:  The remaining bit=
s, labeled "C" through "H", are used<=
/pre>

      for crypto algorit=
hm negotiation.  Currently only the rightmost


      bit, labeled "=
;H", is assigned.  Bit "H" indicates the use of HMAC-


      SHA1 (as defined i=
n Section 3.2).  An implementation that only


      supports this meth=
od MUST set bit "H" to 1, and bits "C" through


      "G&quo=
t; to 0.


 


   A crypto algorithm MUST be specified=
.  If flag bits C through H are


   all 0, the MP_CAPABLE option MUST be=
 treated as invalid and ignored


   (that is, it must be treated as a re=
gular TCP handshake).


..


=3D=3D=3D=3D


 


Also,
https://tools.ietf.org/html/draft-ietf-mptcp-=
rfc6824bis-07#section-8.2
needs to be updated.


 


Thank you.


 


Cheers,


Med
--_000_81bb9deaea02420eb4de3ffe4c72e685OPEXCLILMA4corporateadr_-- From nobody Tue Dec 13 07:05:31 2016 Return-Path: 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 7081C129B6F for ; Tue, 13 Dec 2016 07:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.497 X-Spam-Level: X-Spam-Status: No, score=-5.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.896, 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 OsMDHbgEABQ4 for ; Tue, 13 Dec 2016 07:05:23 -0800 (PST) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66D16129B70 for ; Tue, 13 Dec 2016 07:05:20 -0800 (PST) Received: from EVHUB03-UKBR.domain1.systemhost.net (193.113.108.185) by EVMED01-UKBR.bt.com (10.216.161.31) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 13 Dec 2016 15:05:16 +0000 Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by EVHUB03-UKBR.domain1.systemhost.net (193.113.108.185) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 13 Dec 2016 15:05:18 +0000 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 13 Dec 2016 15:05:17 +0000 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1210.000; Tue, 13 Dec 2016 15:05:17 +0000 From: To: Thread-Topic: Charter text and milestones for MPTCP proxy item Thread-Index: AdJVTEY2l+NJqVnfS1angU0KZ9RsbA== Date: Tue, 13 Dec 2016 15:05:17 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.202.243] Content-Type: multipart/alternative; boundary="_000_d64594e63a984c35b74f97baccea5ba0rew09926dag03bdomain1sy_" MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] Charter text and milestones for MPTCP proxy item X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 15:05:30 -0000 --_000_d64594e63a984c35b74f97baccea5ba0rew09926dag03bdomain1sy_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorry for the delay, coming back to this. We worked a bit more on the chart= er, here's the current proposal - and to check that the timings for the mil= estones are ok. << MPTCP is now seeing widespread deployment in networks to bond together t= wo accesses, such as fixed and mobile broadband, by using an MPTCP-specific= proxy or proxies. There are two scenarios. The first involves two proxies,= one in the home gateway or Customer Premises Equipment and one in the netw= ork, both under the control of the operator. The other scenario involves an= MPTCP-enabled smartphone, with LTE and WiFi, plus a proxy in the operator'= s network. The WG analyses proposed solutions for both the single and dual proxy scena= rios and agrees on the favoured solution approach (or possibly a solution f= or each scenario). The solution(s) may require changes to RFC6824bis, and m= ay require a means of configuring set-up information in the proxy, which wo= uld be done in coordination with other IETF WGs such as DHC. Support for no= n-TCP traffic is out of scope. >> July 2017 - Consensus on favoured solution approach for single and dual MPT= CP proxy scenarios March 2018 - Definition of the favoured solution for MPTCP proxy scenarios,= which may require changes to RFC6824bis March 2018 - Definition of configuration of MPTCP proxy, in coordination wi= th appropriate IETF WGs such as DHC WG This is supposed to make it clear: - Single & two ended proxy in scope - Proxy(s) are under control of operator - Only TCP traffic considered - Open for solution proposals. First step is to analyse propos= als and reach consensus on one we go ahead with. Most likely not an RFC. - Hopefully just one solution, but possibly need different sol= ution for 1 & 2 ended scenarios. Not multiple solutions for each scenario. - May (but may not) require changes to rfc6284 (for instance, = is it an extension to the protocol, or using the existing protocol) - If it does require a change to 6824, then prefer to include = the change in the bis, in order have one version of the protocol. - "appropriate IETF WGs" includes any WG arising from the bana= na BoF Best wishes, Phil & Yoshi From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: 17 November 2016 06:28 To: Eardley,PL,Philip,TUB8 R ; multipathtcp@ietf.org Subject: RE: Proposed charter text for MPTCP proxy item Hi Phil, Please see inline. Cheers, Med De : philip.eardley@bt.com [mailto:philip.ear= dley@bt.com] Envoy=E9 : mercredi 16 novembre 2016 17:38 =C0 : BOUCADAIR Mohamed IMT/OLN; multipathtcp@ietf.org Objet : RE: Proposed charter text for MPTCP proxy item On the question of single-ended proxy as well as 2-ended. Why is the former= considered by operators? - surely it needs MPTCP in end hosts or servers, = which unfortunately isn't there yet? Or do you mean 'today the operators wa= nt to deploy 2-ended proxy solution, and make sure the solution will work i= n the future for 1-ended, without any great changes' [Med] Please consider reading this: 1-proxy: https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerati= ons-00.html#section-4.1 2- proxies: https://tools.ietf.org/html/draft-nam-mptcp-deployment-consider= ations-00.html#section-4.2 Happy to add 1-ended if operators really want it. [Med] Ok, thanks. It clearly adds work to make sure that the solution works in both cases, as= well as protocol work for the first proxy to discover whether a 2nd proxy = exists for this particular receiving end host. [Med] Proxy discovery is similar in both cases, but the means to achieve it= may be different. It looks like we need to add something on configuration. [Med] Great! Thanks for the pointer to the objectives. We'll think about that later (aft= er re-chartering) [Med] As you agreed to have the 1-2 proxies and also on the configuration p= art, I'm reoffering this proposed text charter so that we can have somethin= g concrete to discuss: Many operators now contemplate the use of MPTCP to optimize resource usage in the various access networks (both wired and wireless) they operate. Corresponding designs assume MPTCP proxy capabilities that may be embedded in CPE devices and/or in the operator's network. No assumption is made about the location of the MPTCP proxy inside an operator's network. The WG will investigate solutions to address these target deployments. Deployment considerations as well as means to provision configuration information to MPTCP proxies will also be documented by the WG. From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: 16 November 2016 15:27 To: Eardley,PL,Philip,TUB8 R >; multipathtcp@ietf.org Subject: RE: Proposed charter text for MPTCP proxy item Hi Phil, Thank you for the feedback. Please see inline. Cheers, Med De : philip.eardley@bt.com [mailto:philip.ear= dley@bt.com] Envoy=E9 : mercredi 16 novembre 2016 16:03 =C0 : BOUCADAIR Mohamed IMT/OLN; multipathtcp@ietf.org Objet : RE: Proposed charter text for MPTCP proxy item Assessment criteria - not an RFC. Perhaps it doesn't need saying in the cha= rter. [Med] I don't think we need to say that in the charter. The point is that the process will follow this approach: discuss criteria; = gets proposals against these criteria. [Med] That's one way to proceed, but not the only one. I prefer a more prag= matic approach that we start with a candidate document that will be updated= to record any consensus from the WG. We can progress in // as suggested by= the recent IESG statement: "When the problem scope is well understood and agreed upon, charters focused on solutions work are extremely efficient." Don't want to presume there won't be other proposals and starting points. T= he discussion so far seems to suggest there are other ideas [Med] Ideas do not mean necessarily new solutions or documents. As I mentio= ned earlier, the current merged draft is not frozen, inputs/comments/sugges= tions are more than welcome. Target design objectives - please can you point me to where the objectives = of your proposal are listed. That will be useful input for me & Yoshi to pr= oduce an initial version of the assessment criteria. [Med] This is mentioned in the Introduction of the draft: o No encapsulation required (no tunnels, whatsoever). o No out-of-band signaling for each MPTCP subflow is required. o Avoids interference with native MPTCP connections. o Targets both on-path and off-path MCPs. o Accommodates various deployment contexts, such as those that require the preservation of the source IP address and others characterized by an address sharing design. I'm putting aside this one as I believe it is contentious: o Carries any protocol for the benefit of massive MPTCP adoption. I think the charter text should be explicit about two-ended proxy - as I un= derstand it, that's what matches the current deployments (not 1-ended), so = that's what I think the focus should be. [Med] Both single and two-ended proxies are considered by operators. That's= why I'm suggesting to cite both. Discussion would be useful on two of your points: Firstly, deployment considerations. What do people think would be useful he= re? Experiences from deployments? Implementation advice? What information h= as to be configured (in some unspecified way) on the proxies? Something els= e? [I think it would be useful to capture at least some of this information] [Med] What I have in mind is the kind of details included in https://tools.= ietf.org/html/draft-nam-mptcp-deployment-considerations-00.html. Second, provision of configuration information to MPTCP proxies. As I under= stand it, this will be done by manual configuration, or DHCP extensions, or= something else. My initial reaction is that I think these things are outsi= de the scope of the WG. But the WG can help motivate work elsewhere. [Med] The problem is that the DHC WG charter is explicit about this: "Definitions of new DHCP options that are delivered using standard mechanisms with documented semantics are not considered a protocol extension and thus are outside of scope for the DHC WG. Such options ^^^^^^^^^^^^ should be defined within their respective WGs and reviewed by DHCP ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ experts in the Internet Area Directorate. However, if such options require protocol extensions or new semantics, the protocol extension work must be done in the DHC WG." I'm reiterating my request to include those in the updated charter. Thanks. Thanks [Med] Thank you. phil From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: 16 November 2016 10:06 To: Eardley,PL,Philip,TUB8 R >; multipathtcp@ietf.org Subject: RE: Proposed charter text for MPTCP proxy item Hi Phil, Thank you for sharing this text. I would like to make several comments: * I don't think that assessment criteria and analysis are to be con= sidered as deliverables (hinted by "producing" wording in the proposed text= ). This is IMHO part of the normal handling of proposals within WGs. The an= alysis may be more or less formal, but we don't need to say it explicitly i= n a charter. * At this stage, I only see one merged proposal that is endorsed by= a group of people who have the energy to work on this. This group is ready= to lead this work to capture and record the consensus of the WG when it co= mes to technical design choices. Like any IETF draft, that merged proposal = is not frozen. * From where I sit, I didn't hear objections about the target desig= n objectives of the Network-assisted MPTCP solution (0-RTT proxying, avoid = interference with native MPTCP connection, encourage the establishment of e= 2e MPTCP connections, etc.) but some disagreements about how to structure t= he additional data to be supplied during the 3WHS. Those are fair objection= s that can be handled using the normal IETF procedure (i.e., consensus). * There was also some interest in the deployment document as a comp= anion material to have a big picture of the Network-Assisted MPTCP models. In summary, I would like to charter to be more explicit/clear the MPTCP pro= xy work is definitely in scope. Below a text proposal: Many operators now contemplate the use of MPTCP to optimize resource usage in the various access networks (both wired and wireless) they operate. Corresponding designs assume MPTCP proxy capabilities that may be embedded in CPE devices and/or in the operator's network. Typically, an MPTCP proxy may be embedded in the Customer Premises Equipment (CPE) and/or in the operator's network. No assumption is made about the location of the MPTCP proxy inside an operator's network. The WG will investigate solutions to address these target deployments. Deployment considerations as well as means to provision configuration information to MPTCP proxies will also be documented by the WG. Thank you. Cheers, Med De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de phil= ip.eardley@bt.com Envoy=E9 : mardi 15 novembre 2016 17:24 =C0 : multipathtcp@ietf.org Objet : [multipathtcp] Proposed charter text for MPTCP proxy item Hi, Following our discussion on yesterday's WG meeting, here is some proposed t= ext for the charter:- MPTCP is now seeing widespread deployment in networks to bond together two = accesses, such as fixed and mobile broadband. The scenario typically featur= es two proxies, one in the home gateway ('CPE') and one in the network, bot= h under the control of the operator. The WG will analyse proposed solutions= for this scenario by producing:- * assessment criteria for solutions; support of non-TCP traffic is not a cr= iteria. The WG Chairs will produce the initial version. * analysis of proposed solutions against these criteria, as well as what up= dates they would require to RFC6824bis. As a result, the WG may agree to g= o forward with the favoured solution. Comments? Thanks Phil & Yoshi --_000_d64594e63a984c35b74f97baccea5ba0rew09926dag03bdomain1sy_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Sorry for the delay, coming back to = this. We worked a bit more on the charter, here’s the current proposa= l – and to check that the timings for the milestones are ok.

<&l= t; MPTCP is now seeing widespread deployment in networks to bond together t= wo accesses, such as fixed and mobile broadband, by using an MPTCP-specific= proxy or proxies. There are two scenarios. The first involves two proxies, one in the home gateway or Customer Premis= es Equipment and one in the network, both under the control of the operator= . The other scenario involves an MPTCP-enabled smartphone, with LTE and WiF= i, plus a proxy in the operator’s network.

The WG= analyses proposed solutions for both the single and dual proxy scenarios a= nd agrees on the favoured solution approach (or possibly a solution for eac= h scenario). The solution(s) may require changes to RFC6824bis, and may require a means of configuring set-up infor= mation in the proxy, which would be done in coordination with other IETF WG= s such as DHC. Support for non-TCP traffic is out of scope.

>&g= t; 

&= nbsp;

July 2= 017 – Consensus on favoured solution approach for single and dual MPT= CP proxy scenarios

March = 2018 - Definition of the favoured solution for MPTCP proxy scenarios, which= may require changes to RFC6824bis

March = 2018 – Definition of configuration of MPTCP proxy, in coordination wi= th appropriate IETF WGs such as DHC WG

&= nbsp;

This i= s supposed to make it clear:

- = ;             S= ingle & two ended proxy in scope

- = ;             P= roxy(s) are under control of operator

- = ;             O= nly TCP traffic considered

- = ;             O= pen for solution proposals. First step is to analyse proposals and reach co= nsensus on one we go ahead with. Most likely not an RFC.<= /p>

- = ;             H= opefully just one solution, but possibly need different solution for 1 &= ; 2 ended scenarios. Not multiple solutions for each scenario.

- = ;             M= ay (but may not) require changes to rfc6284 (for instance, is it an extensi= on to the protocol, or using the existing protocol)

- = ;             I= f it does require a change to 6824, then prefer to include the change in th= e bis, in order have one version of the protocol.

- = ;             &= #8220;appropriate IETF WGs” includes any WG arising from the banana B= oF

&= nbsp;

Best w= ishes,

Phil &= amp; Yoshi

 

From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: 17 November 2016 06:28
To: Eardley,PL,Philip,TUB8 R <philip.eardley@bt.com>; multipat= htcp@ietf.org
Subject: RE: Proposed charter text for MPTCP proxy item

 

Hi Phil,

 

Please see inline.

 

Cheers,

Med

 

De : philip.eardley@bt.commailto:philip.eardley@bt.com]
Envoy=E9 : mercredi 16 novembre 2016 17:38
=C0 : BOUCADAIR Mohamed IMT/OLN; multipathtcp@ietf.org=
Objet : RE: Proposed charter text for MPTCP proxy item

 

On the question of single-ended proxy as well as 2-ended. Why is the for= mer considered by operators? – surely it needs MPTCP in end hosts or servers, which unfortunately isn’t there= yet? Or do you mean ‘today the operators want to deploy 2-ended prox= y solution, and make sure the solution will work in the future for 1-ended,= without any great changes’

[Med] Please consider= reading this:  

1-proxy: https://= tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-00.html#secti= on-4.1

2- proxies: https://= tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-00.html#secti= on-4.2

Happy to add 1-ended if operators really want it.

[Med] Ok, thanks.

It clearly adds work to make sure that the solution works in both cases,= as well as protocol work for the first proxy to discover whether a 2nd proxy exists for this particula= r receiving end host.

[Med] Proxy discovery= is similar in both cases, but the means to achieve it may be different.

It looks like we need to add something on configuration.

[Med] Great!

Thanks for the pointer to the objectives. We’ll think about that l= ater (after re-chartering)

[Med] As you agreed t= o have the 1-2 proxies and also on the configuration part, I’m reoffering this proposed text charter so that we can have = something concrete to discuss:

Ma= ny operators now contemplate the use of MPTCP to optimize resource

us= age in the various access networks (both wired and wireless) they

op= erate. Corresponding designs assume MPTCP proxy capabilities that

ma= y be embedded in CPE devices and/or in the operator's network.

No= assumption is made about the location of the

MP= TCP proxy inside an operator’s network. 

 

Th= e WG will investigate solutions to address these

ta= rget deployments. Deployment considerations as well as means to<= /span>

pr= ovision configuration information to MPTCP proxies will also be<= /span>

do= cumented by the WG.

 

From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: 16 November 2016 15:27
To: Eardley,PL,Philip,TUB8 R <phil= ip.eardley@bt.com>; multipathtcp@ietf.org
Subject: RE: Proposed charter text for MPTCP proxy item

 

Hi Phil,

 

Thank you for the feedback.

 

Please see inline.

 

Cheers,

Med

 

De : philip.eardley@bt.commailto:philip.eardley@bt.com]
Envoy=E9 : mercredi 16 novembre 2016 16:03
=C0 : BOUCADAIR Mohamed IMT/OLN; multipathtcp@ietf.org=
Objet : RE: Proposed charter text for MPTCP proxy item

 

Assessment criteria &#= 8211; not an RFC. Perhaps it doesn’t need saying in the charter.

[Med] I don’t think we need to say that = in the charter.

 

The point is that the = process will follow this approach: discuss criteria; gets proposals against= these criteria.

[Med] That’s one way to proceed, but not= the only one. I prefer a more pragmatic approach that we start with a cand= idate document that will be updated to record any consensus from the WG. We can progress in // as suggested by the recent IESG stateme= nt:

 

“When the problem scop= e is well understood and agreed

upon, charters focused on so= lutions work are extremely efficient.”

 

Don’t want to pr= esume there won’t be other proposals and starting points. The discuss= ion so far seems to suggest there are other ideas

[Med] Ideas do not mean necessarily new soluti= ons or documents. As I mentioned earlier, the current merged draft is not f= rozen, inputs/comments/suggestions are more than welcome.

 

Target design objectiv= es – please can you point me to where the objectives of your proposal= are listed. That will be useful input for me & Yoshi to produce an ini= tial version of the assessment criteria.

[Med] This is mentioned in the Introduction of= the draft:

 

   o  No encapsulation=
 required (no tunnels, whatsoever).
   o  No out-of-band s=
ignaling for each MPTCP subflow is required.
   o  Avoids interfere=
nce with native MPTCP connections.
   o  Targets both on-=
path and off-path MCPs.
   o  Accommodates var=
ious deployment contexts, such as those that
      requir=
e the preservation of the source IP address and others

      charac=
terized by an address sharing design.


 


I’m putting aside this one as I=
 believe it is contentious: 


   o  Carries any=
 protocol for the benefit of massive MPTCP adoption.

 


I think the charter te=
xt should be explicit about two-ended proxy – as I understand it, tha=
t’s what matches the current deployments (not 1-ended), so that’=
;s what I think the focus should be.


[Med] Both single and two-ended proxies are co=
nsidered by operators. That’s why I’m suggesting to cite both.



 


Discussion would be us=
eful on two of your points:


 


Firstly, deployment co=
nsiderations. What do people think would be useful here? Experiences from d=
eployments? Implementation advice? What information has to be configured (i=
n some unspecified way) on the proxies?
 Something else?


[I think it would be u=
seful to capture at least some of this information]


[Med] What I have in mind is the kind of detai=
ls included in
https://tools.ietf.org/html/draft-nam-mptcp-deployment-cons=
iderations-00.html.
   


 


Second, provision of c=
onfiguration information to MPTCP proxies. As I understand it, this will be=
 done by manual configuration, or DHCP extensions, or something else. My in=
itial reaction is that I think these
 things are outside the scope of the WG. But the WG can help motivate work =
elsewhere.



[Med] The problem is that the DHC WG charter i=
s explicit about this:


 


"Definitions of new DHCP options that are delivered =
using standard


mechanisms with documented semantics are not considered a=
 protocol


extension and thus are outside of scope for the DHC WG. S=
uch options


         &nb=
sp;            =
            &nb=
sp;            =
         ^^^^^^^^^^^^


should be defined within their respective WGs and reviewe=
d by DHCP


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=



experts in the Internet Area Directorate. However, if suc=
h options


require protocol extensions or new semantics, the protoco=
l extension


work must be done in the DHC WG."<=
/p>

 


I’m reiterating my request to include th=
ose in the updated charter. Thanks.


 


Thanks


[Med] Thank you.


phil=



 


 


 






From:
mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]


Sent: 16 November 2016 10:06

To: Eardley,PL,Philip,TUB8 R <phil=
ip.eardley@bt.com>;
multipathtcp@ietf.org

Subject: RE: Proposed charter text for MPTCP proxy item






 


Hi Phil,


 


Thank you for sharing this text=
.



 


I would like to make several co=
mments:



=B7<=
span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:"Times New Ro=
man",serif;color:black">       &nbs=
p;
I don’t think that assessment criteria an=
d analysis are to be considered as deliverables (hinted by “producing=
” wording in the proposed text). This is IMHO part of the
 normal handling of proposals within WGs. The analysis may be more or less =
formal, but we don’t need to say it explicitly in a charter.


=B7<=
span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:"Times New Ro=
man",serif;color:black">       &nbs=
p;
At this stage, I only see one merged proposal t=
hat is endorsed by a group of people who have the energy to work on this. T=
his group is ready to lead this work to capture
 and record the consensus of the WG when it comes to technical design choic=
es. Like any IETF draft, that merged proposal is not frozen.



=B7<=
span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:"Times New Ro=
man",serif;color:black">       &nbs=
p;
From where I sit, I didn’t hear objection=
s about the target design objectives of the Network-assisted MPTCP solution=
 (0-RTT proxying, avoid interference with native MPTCP
 connection, encourage the establishment of e2e MPTCP connections, etc.) bu=
t some disagreements about how to structure the additional data to be suppl=
ied during the 3WHS. Those are fair objections that can be handled using th=
e normal IETF procedure (i.e., consensus).



=B7<=
span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:"Times New Ro=
man",serif;color:black">       &nbs=
p;
There was also some interest in the deployment =
document as a companion material to have a big picture of the Network-Assis=
ted MPTCP models.    


 


In summary, I would like to cha=
rter to be more explicit/clear the MPTCP proxy work is definitely in scope.=
 Below a text proposal:


 


Ma=
ny operators now contemplate the use of MPTCP to optimize resource


us=
age in the various access networks (both wired and wireless) they


op=
erate. Corresponding designs assume MPTCP proxy capabilities that


ma=
y be embedded in CPE devices and/or in the operator's network.


Ty=
pically, an MPTCP proxy may be embedded in the Customer Premises=



Eq=
uipment (CPE) and/or in the operator’s network.


No=
 assumption is made about the location of the


MP=
TCP proxy inside an operator’s network. 



 


Th=
e WG will investigate solutions to address these


ta=
rget deployments. Deployment considerations as well as means to<=
/span>


pr=
ovision configuration information to MPTCP proxies will also be<=
/span>


do=
cumented by the WG.


 


Thank you.

 


Cheers,


Med


 








De :<=
/span> multipathtcp [mailto:multipathtcp-bounces@ietf.org]
De la part de philip.eardley@bt.com

Envoy=E9 : mardi 15 novembre 2016 17:24

=C0 : multipathtcp@ietf.org

Objet : [multipathtcp] Proposed charter text for MPTCP proxy it=
em






 


Hi,


Following our discussion on yesterday’s WG mee=
ting, here is some proposed text for the charter:-


 


MPTCP is now seeing widespread deployment in netw=
orks to bond together two accesses, such as fixed and mobile broadband. The=
 scenario typically features two proxies, one in the home gateway (‘C=
PE’) and one in the network, both under
 the control of the operator. The WG will analyse proposed solutions for th=
is scenario by producing:-


* assessment criteria for solutions; support of n=
on-TCP traffic is not a criteria. The WG Chairs will produce the initial ve=
rsion.


* analysis of proposed solutions against these cr=
iteria, as well as what updates they would require to RFC6824bis.  As =
a result, the WG may agree to go forward with the favoured solution.


 


Comments?


Thanks


Phil & Yoshi
--_000_d64594e63a984c35b74f97baccea5ba0rew09926dag03bdomain1sy_-- From nobody Tue Dec 13 07:39:51 2016 Return-Path: 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 CF426129B56 for ; Tue, 13 Dec 2016 07:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.814 X-Spam-Level: X-Spam-Status: No, score=-4.814 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, 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 zUQXI93o8BZ0 for ; Tue, 13 Dec 2016 07:39:43 -0800 (PST) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 485B9129B46 for ; Tue, 13 Dec 2016 07:39:43 -0800 (PST) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 946E5160516 for ; Tue, 13 Dec 2016 16:39:41 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 686B7180050; Tue, 13 Dec 2016 16:39:41 +0100 (CET) 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.0319.002; Tue, 13 Dec 2016 16:39:41 +0100 From: To: "philip.eardley@bt.com" , "multipathtcp@ietf.org" Thread-Topic: Charter text and milestones for MPTCP proxy item Thread-Index: AdJVTEY2l+NJqVnfS1angU0KZ9RsbAACUuWQ Date: Tue, 13 Dec 2016 15:39:40 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DCC91C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: In-Reply-To: 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_787AE7BB302AE849A7480A190F8B933009DCC91COPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Charter text and milestones for MPTCP proxy item X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 15:39:48 -0000 --_000_787AE7BB302AE849A7480A190F8B933009DCC91COPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Phil, Thank you for the updated text. Please see inline. Cheers, Med De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de phil= ip.eardley@bt.com Envoy=E9 : mardi 13 d=E9cembre 2016 16:05 =C0 : multipathtcp@ietf.org Objet : [multipathtcp] Charter text and milestones for MPTCP proxy item Sorry for the delay, coming back to this. We worked a bit more on the chart= er, here's the current proposal - and to check that the timings for the mil= estones are ok. << MPTCP is now seeing widespread deployment in networks to bond together t= wo accesses, such as fixed and mobile broadband, by using an MPTCP-specific= proxy or proxies. [Med] s/ by using an MPTCP-specific proxy or proxies/ by using one or two M= PTCP-specific proxies. There are two scenarios. [Med] s/ There are two scenarios/ Two deployment scenarios are considered. The first involves two proxies, one in the home gateway or Customer Premise= s Equipment and one in the network, both under the control of the operator.= The other scenario involves an MPTCP-enabled smartphone, with LTE and WiFi [Med] Wifi is trademarked. You may use WLAN or IEEE 802.11 instead. , plus a proxy in the operator's network. The WG analyses proposed solutions for both the single and dual proxy scena= rios and agrees on the favoured solution approach (or possibly a solution f= or each scenario). The solution(s) may require changes to RFC6824bis, and m= ay require a means of configuring set-up information in the proxy, which wo= uld be done in coordination with other IETF WGs such as DHC. Support for no= n-TCP traffic is out of scope. >> July 2017 - Consensus on favoured solution approach for single and dual MPT= CP proxy scenarios [Med] I would suggest March 2017 for this step. March 2018 - Definition of the favoured solution for MPTCP proxy scenarios,= which may require changes to RFC6824bis [Med] I have two comments: =B7 I don't see the need to mention "which may require changes to R= FC6824bis" =B7 I suggest we adopt an aggressive timeline for finalizing the sp= ec: December 2017. March 2018 - Definition of configuration of MPTCP proxy, in coordination wi= th appropriate IETF WGs such as DHC WG [Med] I suggest "December 2017" as a deadline for this item. This is supposed to make it clear: - Single & two ended proxy in scope - Proxy(s) are under control of operator - Only TCP traffic considered - Open for solution proposals. First step is to analyse propos= als and reach consensus on one we go ahead with. Most likely not an RFC. - Hopefully just one solution, but possibly need different sol= ution for 1 & 2 ended scenarios. Not multiple solutions for each scenario. - May (but may not) require changes to rfc6284 (for instance, = is it an extension to the protocol, or using the existing protocol) - If it does require a change to 6824, then prefer to include = the change in the bis, in order have one version of the protocol. - "appropriate IETF WGs" includes any WG arising from the bana= na BoF Best wishes, Phil & Yoshi From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: 17 November 2016 06:28 To: Eardley,PL,Philip,TUB8 R >; multipathtcp@ietf.org Subject: RE: Proposed charter text for MPTCP proxy item Hi Phil, Please see inline. Cheers, Med De : philip.eardley@bt.com [mailto:philip.ear= dley@bt.com] Envoy=E9 : mercredi 16 novembre 2016 17:38 =C0 : BOUCADAIR Mohamed IMT/OLN; multipathtcp@ietf.org Objet : RE: Proposed charter text for MPTCP proxy item On the question of single-ended proxy as well as 2-ended. Why is the former= considered by operators? - surely it needs MPTCP in end hosts or servers, = which unfortunately isn't there yet? Or do you mean 'today the operators wa= nt to deploy 2-ended proxy solution, and make sure the solution will work i= n the future for 1-ended, without any great changes' [Med] Please consider reading this: 1-proxy: https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerati= ons-00.html#section-4.1 2- proxies: https://tools.ietf.org/html/draft-nam-mptcp-deployment-consider= ations-00.html#section-4.2 Happy to add 1-ended if operators really want it. [Med] Ok, thanks. It clearly adds work to make sure that the solution works in both cases, as= well as protocol work for the first proxy to discover whether a 2nd proxy = exists for this particular receiving end host. [Med] Proxy discovery is similar in both cases, but the means to achieve it= may be different. It looks like we need to add something on configuration. [Med] Great! Thanks for the pointer to the objectives. We'll think about that later (aft= er re-chartering) [Med] As you agreed to have the 1-2 proxies and also on the configuration p= art, I'm reoffering this proposed text charter so that we can have somethin= g concrete to discuss: Many operators now contemplate the use of MPTCP to optimize resource usage in the various access networks (both wired and wireless) they operate. Corresponding designs assume MPTCP proxy capabilities that may be embedded in CPE devices and/or in the operator's network. No assumption is made about the location of the MPTCP proxy inside an operator's network. The WG will investigate solutions to address these target deployments. Deployment considerations as well as means to provision configuration information to MPTCP proxies will also be documented by the WG. From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: 16 November 2016 15:27 To: Eardley,PL,Philip,TUB8 R >; multipathtcp@ietf.org Subject: RE: Proposed charter text for MPTCP proxy item Hi Phil, Thank you for the feedback. Please see inline. Cheers, Med De : philip.eardley@bt.com [mailto:philip.ear= dley@bt.com] Envoy=E9 : mercredi 16 novembre 2016 16:03 =C0 : BOUCADAIR Mohamed IMT/OLN; multipathtcp@ietf.org Objet : RE: Proposed charter text for MPTCP proxy item Assessment criteria - not an RFC. Perhaps it doesn't need saying in the cha= rter. [Med] I don't think we need to say that in the charter. The point is that the process will follow this approach: discuss criteria; = gets proposals against these criteria. [Med] That's one way to proceed, but not the only one. I prefer a more prag= matic approach that we start with a candidate document that will be updated= to record any consensus from the WG. We can progress in // as suggested by= the recent IESG statement: "When the problem scope is well understood and agreed upon, charters focused on solutions work are extremely efficient." Don't want to presume there won't be other proposals and starting points. T= he discussion so far seems to suggest there are other ideas [Med] Ideas do not mean necessarily new solutions or documents. As I mentio= ned earlier, the current merged draft is not frozen, inputs/comments/sugges= tions are more than welcome. Target design objectives - please can you point me to where the objectives = of your proposal are listed. That will be useful input for me & Yoshi to pr= oduce an initial version of the assessment criteria. [Med] This is mentioned in the Introduction of the draft: o No encapsulation required (no tunnels, whatsoever). o No out-of-band signaling for each MPTCP subflow is required. o Avoids interference with native MPTCP connections. o Targets both on-path and off-path MCPs. o Accommodates various deployment contexts, such as those that require the preservation of the source IP address and others characterized by an address sharing design. I'm putting aside this one as I believe it is contentious: o Carries any protocol for the benefit of massive MPTCP adoption. I think the charter text should be explicit about two-ended proxy - as I un= derstand it, that's what matches the current deployments (not 1-ended), so = that's what I think the focus should be. [Med] Both single and two-ended proxies are considered by operators. That's= why I'm suggesting to cite both. Discussion would be useful on two of your points: Firstly, deployment considerations. What do people think would be useful he= re? Experiences from deployments? Implementation advice? What information h= as to be configured (in some unspecified way) on the proxies? Something els= e? [I think it would be useful to capture at least some of this information] [Med] What I have in mind is the kind of details included in https://tools.= ietf.org/html/draft-nam-mptcp-deployment-considerations-00.html. Second, provision of configuration information to MPTCP proxies. As I under= stand it, this will be done by manual configuration, or DHCP extensions, or= something else. My initial reaction is that I think these things are outsi= de the scope of the WG. But the WG can help motivate work elsewhere. [Med] The problem is that the DHC WG charter is explicit about this: "Definitions of new DHCP options that are delivered using standard mechanisms with documented semantics are not considered a protocol extension and thus are outside of scope for the DHC WG. Such options ^^^^^^^^^^^^ should be defined within their respective WGs and reviewed by DHCP ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ experts in the Internet Area Directorate. However, if such options require protocol extensions or new semantics, the protocol extension work must be done in the DHC WG." I'm reiterating my request to include those in the updated charter. Thanks. Thanks [Med] Thank you. phil From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: 16 November 2016 10:06 To: Eardley,PL,Philip,TUB8 R >; multipathtcp@ietf.org Subject: RE: Proposed charter text for MPTCP proxy item Hi Phil, Thank you for sharing this text. I would like to make several comments: * I don't think that assessment criteria and analysis are to be con= sidered as deliverables (hinted by "producing" wording in the proposed text= ). This is IMHO part of the normal handling of proposals within WGs. The an= alysis may be more or less formal, but we don't need to say it explicitly i= n a charter. * At this stage, I only see one merged proposal that is endorsed by= a group of people who have the energy to work on this. This group is ready= to lead this work to capture and record the consensus of the WG when it co= mes to technical design choices. Like any IETF draft, that merged proposal = is not frozen. * From where I sit, I didn't hear objections about the target desig= n objectives of the Network-assisted MPTCP solution (0-RTT proxying, avoid = interference with native MPTCP connection, encourage the establishment of e= 2e MPTCP connections, etc.) but some disagreements about how to structure t= he additional data to be supplied during the 3WHS. Those are fair objection= s that can be handled using the normal IETF procedure (i.e., consensus). * There was also some interest in the deployment document as a comp= anion material to have a big picture of the Network-Assisted MPTCP models. In summary, I would like to charter to be more explicit/clear the MPTCP pro= xy work is definitely in scope. Below a text proposal: Many operators now contemplate the use of MPTCP to optimize resource usage in the various access networks (both wired and wireless) they operate. Corresponding designs assume MPTCP proxy capabilities that may be embedded in CPE devices and/or in the operator's network. Typically, an MPTCP proxy may be embedded in the Customer Premises Equipment (CPE) and/or in the operator's network. No assumption is made about the location of the MPTCP proxy inside an operator's network. The WG will investigate solutions to address these target deployments. Deployment considerations as well as means to provision configuration information to MPTCP proxies will also be documented by the WG. Thank you. Cheers, Med De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de phil= ip.eardley@bt.com Envoy=E9 : mardi 15 novembre 2016 17:24 =C0 : multipathtcp@ietf.org Objet : [multipathtcp] Proposed charter text for MPTCP proxy item Hi, Following our discussion on yesterday's WG meeting, here is some proposed t= ext for the charter:- MPTCP is now seeing widespread deployment in networks to bond together two = accesses, such as fixed and mobile broadband. The scenario typically featur= es two proxies, one in the home gateway ('CPE') and one in the network, bot= h under the control of the operator. The WG will analyse proposed solutions= for this scenario by producing:- * assessment criteria for solutions; support of non-TCP traffic is not a cr= iteria. The WG Chairs will produce the initial version. * analysis of proposed solutions against these criteria, as well as what up= dates they would require to RFC6824bis. As a result, the WG may agree to g= o forward with the favoured solution. Comments? Thanks Phil & Yoshi --_000_787AE7BB302AE849A7480A190F8B933009DCC91COPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Phil,

 

Thank you for the updated text.

 

Please see inline.

 

Cheers,

Med

 

De : multipathtcp [mailto:multipatht= cp-bounces@ietf.org] De la part de philip.eardley@bt.com
Envoy=E9 : mardi 13 d=E9cembre 2016 16:05
=C0 : multipathtcp@ietf.org
Objet : [multipathtcp] Charter text and milestones for MPTCP pr= oxy item

 

Sorry for the delay, = coming back to this. We worked a bit more on the charter, here’s the = current proposal – and to check that the timings for the milestones are ok.

<< MPTCP is now seeing widespread deployment in networks to = bond together two accesses, such as fixed and mobile broadband, by using an= MPTCP-specific proxy or proxies.

[= Med] s/ by using an MPTCP-sp= ecific proxy or proxies/ by using one or two = MPTCP-specific proxies.

<= o:p> 

There are two scenarios.

[= Med] s/ There are two scenar= ios/ Two deployment scena= rios are considered.

<= o:p> 

The first involves two proxies, one in the home gateway or Custome= r Premises Equipment and one in the network, both under the control of the = operator. The other scenario involves an MPTCP-enabled smartphone, with LTE and WiFi=

[= Med] Wifi is trademarked. You may use WLAN or IEEE 802.11 instead.

<= o:p> 

, plus a proxy in the operator’s network.<= /p>

The WG analyses proposed solutions for both the single and dual pr= oxy scenarios and agrees on the favoured solution approach (or possibly a s= olution for each scenario). The solution(s) may require changes to RFC6824bis, and may require a means of configuring = set-up information in the proxy, which would be done in coordination with o= ther IETF WGs such as DHC. Support for non-TCP traffic is out of scope.

>> 

 

July 2017 – Consensus on favoured solution approach for sing= le and dual MPTCP proxy scenarios

[= Med] I would suggest March 2017 for this step.

<= o:p> 

March 2018 - Definition of the favoured solution for MPTCP proxy s= cenarios, which may require changes to RFC6824bis

[= Med]  I have two comments:

=B7 &n= bsp;       I don’t see the need to mention “which may require changes to RFC6824bis”

=B7 &n= bsp;       I suggest we adopt an aggressive timeline for finalizing the spec: Dece= mber 2017.

<= o:p> 

March 2018 – Definition of configuration of MPTCP proxy, in = coordination with appropriate IETF WGs such as DHC WG

[= Med] I suggest “December 2017” as a deadline for this item.

 

This is supposed to make it clear:

-           = ;   Single & two ended proxy in scope

-           = ;   Proxy(s) are under control of operator

-           = ;   Only TCP traffic considered

-           = ;   Open for solution proposals. First step is to analyse proposa= ls and reach consensus on one we go ahead with. Most likely not an RFC.

-           = ;   Hopefully just one solution, but possibly need different solu= tion for 1 & 2 ended scenarios. Not multiple solutions for each scenari= o.

-           = ;   May (but may not) require changes to rfc6284 (for instance, i= s it an extension to the protocol, or using the existing protocol)

-           = ;   If it does require a change to 6824, then prefer to include t= he change in the bis, in order have one version of the protocol.

-           = ;   “appropriate IETF WGs” includes any WG arising fr= om the banana BoF

 

Best wishes,

Phil & Yoshi

&n= bsp;

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: 17 November 2016 06:28
To: Eardley,PL,Philip,TUB8 R <philip.eardley@bt.com>; multipathtcp@ietf.org
Subject: RE: Proposed charter text for MPTCP proxy item

 

Hi Phil,

 

Please see inline.

 

Cheers,

Med

 

De : philip.eardley@bt.com<= /span> [mailto:philip.eardley@bt.com]
Envoy=E9 : mercredi 16 novembre 2016 17:38
=C0 : BOUCADAIR Mohamed IMT/OLN; multipathtcp@ietf.org
Objet : RE: Proposed charter text for MPTCP proxy item

 

On the question of single-ended proxy as well as 2-ended. Why is the for= mer considered by operators? – surely it needs MPTCP in end hosts or servers, which unfortunately isn’t there= yet? Or do you mean ‘today the operators want to deploy 2-ended prox= y solution, and make sure the solution will work in the future for 1-ended,= without any great changes’

[Med] Please consider= reading this:  

1-proxy: https://tools.ietf.org/html/draft-nam-mptcp-deployment-conside= rations-00.html#section-4.1

2- proxies: https://tools.ietf.org/html/draft-nam-mptcp-deployment-conside= rations-00.html#section-4.2

Happy to add 1-ended if operators really want it.

[Med] Ok, thanks.

It clearly adds work to make sure that the solution works in both cases,= as well as protocol work for the first proxy to discover whether a 2nd proxy exists for this particula= r receiving end host.

[Med] Proxy discovery= is similar in both cases, but the means to achieve it may be different.

It looks like we need to add something on configuration.

[Med] Great!

Thanks for the pointer to the objectives. We’ll think about that l= ater (after re-chartering)

[Med] As you agreed t= o have the 1-2 proxies and also on the configuration part, I’m reoffering this proposed text charter so that we can have = something concrete to discuss:

Ma= ny operators now contemplate the use of MPTCP to optimize resource

us= age in the various access networks (both wired and wireless) they

op= erate. Corresponding designs assume MPTCP proxy capabilities that

ma= y be embedded in CPE devices and/or in the operator's network.

No= assumption is made about the location of the

MP= TCP proxy inside an operator’s network. 

 

Th= e WG will investigate solutions to address these

ta= rget deployments. Deployment considerations as well as means to<= /span>

pr= ovision configuration information to MPTCP proxies will also be<= /span>

do= cumented by the WG.

&n= bsp;

From: mohamed.boucadai= r@orange.com [m= ailto:mohamed.boucadair@orange.com]
Sent: 16 November 2016 15:27
To: Eardley,PL,Philip,TUB8 R <philip.eardley@bt.com>; multipathtcp@ietf.org<= br> Subject: RE: Proposed charter text for MPTCP proxy item

 

Hi Phil,

 

Thank you for the feedback.

 

Please see inline.

 

Cheers,

Med

 

De : philip.eardley@bt.com<= /span> [mailto:philip.eardley@bt.com]
Envoy=E9 : mercredi 16 novembre 2016 16:03
=C0 : BOUCADAIR Mohamed IMT/OLN; multipathtcp@ietf.org
Objet : RE: Proposed charter text for MPTCP proxy item

 

Assessm= ent criteria – not an RFC. Perhaps it doesn’t need saying in th= e charter.

[Med] I don’t think we ne= ed to say that in the charter.

 

The poi= nt is that the process will follow this approach: discuss criteria; gets pr= oposals against these criteria.

[Med] That’s one way to p= roceed, but not the only one. I prefer a more pragmatic approach that we st= art with a candidate document that will be updated to record any consensus from the WG. We can progress in // as suggested by th= e recent IESG statement:

 

“When the problem scop= e is well understood and agreed

upon, charters focused on so= lutions work are extremely efficient.”

&n= bsp;

DonR= 17;t want to presume there won’t be other proposals and starting poin= ts. The discussion so far seems to suggest there are other ideas=

[Med] Ideas do not mean necessa= rily new solutions or documents. As I mentioned earlier, the current merged= draft is not frozen, inputs/comments/suggestions are more than welcome.

&n= bsp;

Target = design objectives – please can you point me to where the objectives o= f your proposal are listed. That will be useful input for me & Yoshi to= produce an initial version of the assessment criteria.

[Med] This is mentioned in the = Introduction of the draft:

 

   o  No encapsulation=
 required (no tunnels, whatsoever).
   o  No out-of-band s=
ignaling for each MPTCP subflow is required.
   o  Avoids interfere=
nce with native MPTCP connections.
   o  Targets both on-=
path and off-path MCPs.
   o  Accommodates var=
ious deployment contexts, such as those that
      requir=
e the preservation of the source IP address and others

      charac=
terized by an address sharing design.


 


I’m putting aside this one as I=
 believe it is contentious: 


   o  Carries any=
 protocol for the benefit of massive MPTCP adoption.

 


I think=
 the charter text should be explicit about two-ended proxy – as I und=
erstand it, that’s what matches the current deployments (not 1-ended)=
, so that’s what I think the focus should be.


[Med] Both single and two-ended=
 proxies are considered by operators. That’s why I’m suggesting=
 to cite both.



&n=
bsp;


Discuss=
ion would be useful on two of your points:


&n=
bsp;


Firstly=
, deployment considerations. What do people think would be useful here? Exp=
eriences from deployments? Implementation advice? What information has to b=
e configured (in some unspecified way)
 on the proxies? Something else?


[I thin=
k it would be useful to capture at least some of this information]


[Med] What I have in mind is th=
e kind of details included in
https://tools.ietf.org/html/draft-nam-=
mptcp-deployment-considerations-00.html.
   


&n=
bsp;


Second,=
 provision of configuration information to MPTCP proxies. As I understand i=
t, this will be done by manual configuration, or DHCP extensions, or someth=
ing else. My initial reaction is that
 I think these things are outside the scope of the WG. But the WG can help =
motivate work elsewhere.



[Med] The problem is that the D=
HC WG charter is explicit about this:


 


"Definitions of new DHCP options that are delivered =
using standard


mechanisms with documented semantics are not considered a=
 protocol


extension and thus are outside of scope for the DHC WG. S=
uch options


         &nb=
sp;            =
            &nb=
sp;            =
         ^^^^^^^^^^^^


should be defined within their respective WGs and reviewe=
d by DHCP


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=



experts in the Internet Area Directorate. However, if suc=
h options


require protocol extensions or new semantics, the protoco=
l extension


work must be done in the DHC WG."<=
/p>

 


I’m reiterating my reques=
t to include those in the updated charter. Thanks.


&n=
bsp;


Thanks<=
o:p>


[Med] Thank you.


phil


&n=
bsp;


&n=
bsp;


&n=
bsp;






From:
mohamed.boucadai=
r@orange.com [m=
ailto:mohamed.boucadair@orange.com]


Sent: 16 November 2016 10:06

To: Eardley,PL,Philip,TUB8 R <philip.eardley@bt.com>;
multipathtcp@ietf.org<=
br>
Subject: RE: Proposed charter text for MPTCP proxy item






 


Hi Phil,


 


Thank you for sharing this text=
.



 


I would like to make several co=
mments:



=B7<=
span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:"Times New Ro=
man","serif";color:black">     &nbs=
p;  
I don’t think that assessment criteria an=
d analysis are to be considered as deliverables (hinted by “producing=
” wording in the proposed text). This is IMHO part of the
 normal handling of proposals within WGs. The analysis may be more or less =
formal, but we don’t need to say it explicitly in a charter.


=B7<=
span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:"Times New Ro=
man","serif";color:black">     &nbs=
p;  
At this stage, I only see one merged proposal t=
hat is endorsed by a group of people who have the energy to work on this. T=
his group is ready to lead this work to capture
 and record the consensus of the WG when it comes to technical design choic=
es. Like any IETF draft, that merged proposal is not frozen.



=B7<=
span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:"Times New Ro=
man","serif";color:black">     &nbs=
p;  
From where I sit, I didn’t hear objection=
s about the target design objectives of the Network-assisted MPTCP solution=
 (0-RTT proxying, avoid interference with native MPTCP
 connection, encourage the establishment of e2e MPTCP connections, etc.) bu=
t some disagreements about how to structure the additional data to be suppl=
ied during the 3WHS. Those are fair objections that can be handled using th=
e normal IETF procedure (i.e., consensus).



=B7<=
span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:"Times New Ro=
man","serif";color:black">     &nbs=
p;  
There was also some interest in the deployment =
document as a companion material to have a big picture of the Network-Assis=
ted MPTCP models.    


 


In summary, I would like to cha=
rter to be more explicit/clear the MPTCP proxy work is definitely in scope.=
 Below a text proposal:


 


Ma=
ny operators now contemplate the use of MPTCP to optimize resource


us=
age in the various access networks (both wired and wireless) they


op=
erate. Corresponding designs assume MPTCP proxy capabilities that


ma=
y be embedded in CPE devices and/or in the operator's network.


Ty=
pically, an MPTCP proxy may be embedded in the Customer Premises=



Eq=
uipment (CPE) and/or in the operator’s network.


No=
 assumption is made about the location of the


MP=
TCP proxy inside an operator’s network. 



 


Th=
e WG will investigate solutions to address these


ta=
rget deployments. Deployment considerations as well as means to<=
/span>


pr=
ovision configuration information to MPTCP proxies will also be<=
/span>


do=
cumented by the WG.


 


Thank you.

 


Cheers,


Med


 








 m=
ultipathtcp
 [mailto:multipathtcp-=
bounces@ietf.org]
De la part de philip.ea=
rdley@bt.com

Envoy=E9 : mardi 15 novembre 2016 17:24

=C0 : multipathtcp@ie=
tf.org

Objet : [multipathtcp] Proposed charter text for MPTCP proxy it=
em






 


Hi,


Following our discussion on yes=
terday’s WG meeting, here is some proposed text for the charter:-


 


MPTCP is now seeing widespre=
ad deployment in networks to bond together two accesses, such as fixed and =
mobile broadband. The scenario typically features two proxies, one in the h=
ome gateway (‘CPE’) and one in the network,
 both under the control of the operator. The WG will analyse proposed solut=
ions for this scenario by producing:-


* assessment criteria for so=
lutions; support of non-TCP traffic is not a criteria. The WG Chairs will p=
roduce the initial version.


* analysis of proposed solut=
ions against these criteria, as well as what updates they would require to =
RFC6824bis.  As a result, the WG may agree to go forward with the favo=
ured solution.


 


Comments?


Thanks


Phil & Yoshi
--_000_787AE7BB302AE849A7480A190F8B933009DCC91COPEXCLILMA3corp_-- From nobody Tue Dec 13 08:54:52 2016 Return-Path: X-Original-To: multipathtcp@ietf.org Delivered-To: multipathtcp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEE512944C for ; Tue, 13 Dec 2016 08:54:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.39.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148164809157.29438.4056987757376658987.idtracker@ietfa.amsl.com> Date: Tue, 13 Dec 2016 08:54:51 -0800 From: IETF Secretariat Archived-At: Subject: [multipathtcp] Milestones changed for mptcp WG X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 16:54:51 -0000 Changed milestone "Use-cases and operational experiences (Informational) to IESG", resolved as "Done". Deleted milestone "MPTCP-enabled middleboxes (Informational) to IESG". Changed milestone "MPTCP standards track protocol to IESG", set due date to March 2018 from January 2015. Changed milestone "Re-charter or close", set due date to April 2018 from April 2015. URL: https://datatracker.ietf.org/wg/mptcp/charter/ From nobody Wed Dec 14 08:23:37 2016 Return-Path: X-Original-To: multipathtcp@ietf.org Delivered-To: multipathtcp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ADDB4129EB2 for ; Wed, 14 Dec 2016 08:23:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.39.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148173261570.16876.549374607616123839.idtracker@ietfa.amsl.com> Date: Wed, 14 Dec 2016 08:23:35 -0800 From: IETF Secretariat Archived-At: Subject: [multipathtcp] Milestones changed for mptcp WG X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 16:23:36 -0000 Changed milestone "Enhanced API (Informational) to IESG", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/mptcp/charter/