Re: [multipathtcp] Charter text and milestones for MPTCP proxy item

<mohamed.boucadair@orange.com> Tue, 13 December 2016 15:39 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 CF426129B56 for <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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 <multipathtcp@ietf.org>; 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: mohamed.boucadair@orange.com
To: "philip.eardley@bt.com" <philip.eardley@bt.com>, "multipathtcp@ietf.org" <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: <d64594e63a984c35b74f97baccea5ba0@rew09926dag03b.domain1.systemhost.net>
In-Reply-To: <d64594e63a984c35b74f97baccea5ba0@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.3]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009DCC91COPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/WQzJOE9V0VAnCxNlW6teDh2Olg4>
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 <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, 13 Dec 2016 15:39:48 -0000

Hi Phil,

Thank you for the updated text.

Please see inline.

Cheers,
Med

De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de philip.eardley@bt.com
Envoyé : mardi 13 décembre 2016 16:05
À : 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 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-specific proxy or proxies/ by using one or two MPTCP-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 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.



, plus a proxy in the operator's network.

The WG analyses proposed solutions for both the single and dual proxy scenarios and agrees on the favoured solution approach (or possibly a solution 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 other IETF WGs such as DHC. Support for non-TCP traffic is out of scope.

>>



July 2017 - Consensus on favoured solution approach for single and dual MPTCP 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:

·         I don't see the need to mention "which may require changes to RFC6824bis"

·         I suggest we adopt an aggressive timeline for finalizing the spec: December 2017.



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 proposals and reach consensus on one we go ahead with. Most likely not an RFC.

-              Hopefully just one solution, but possibly need different solution 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 banana BoF



Best wishes,

Phil & Yoshi

From: mohamed.boucadair@orange.com<mailto: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<mailto:philip.eardley@bt.com>>; multipathtcp@ietf.org<mailto: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.eardley@bt.com> [mailto:philip.eardley@bt.com]
Envoyé : mercredi 16 novembre 2016 17:38
À : BOUCADAIR Mohamed IMT/OLN; multipathtcp@ietf.org<mailto: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 want to deploy 2-ended proxy 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#section-4.1
2- proxies: https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-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 (after re-chartering)
[Med] As you agreed to 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:
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<mailto:mohamed.boucadair@orange.com> [mailto:mohamed.boucadair@orange.com]
Sent: 16 November 2016 15:27
To: Eardley,PL,Philip,TUB8 R <philip.eardley@bt.com<mailto:philip.eardley@bt.com>>; multipathtcp@ietf.org<mailto: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.eardley@bt.com> [mailto:philip.eardley@bt.com]
Envoyé : mercredi 16 novembre 2016 16:03
À : BOUCADAIR Mohamed IMT/OLN; multipathtcp@ietf.org<mailto: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 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 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. The discussion so far seems to suggest there are other ideas
[Med] Ideas do not mean necessarily new solutions or documents. As I mentioned earlier, the current merged draft is not frozen, inputs/comments/suggestions 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 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 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 understand 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 here? Experiences from deployments? Implementation advice? What information has to be configured (in some unspecified way) on the proxies? Something else?
[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 understand it, this will be done by manual configuration, or DHCP extensions, or something 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 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<mailto:mohamed.boucadair@orange.com> [mailto:mohamed.boucadair@orange.com]
Sent: 16 November 2016 10:06
To: Eardley,PL,Philip,TUB8 R <philip.eardley@bt.com<mailto:philip.eardley@bt.com>>; multipathtcp@ietf.org<mailto: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 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.

*         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 comes 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 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.) but some disagreements about how to structure the additional data to be supplied during the 3WHS. Those are fair objections that can be handled using the normal IETF procedure (i.e., consensus).

*         There was also some interest in the deployment document as a companion 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 proxy 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 philip.eardley@bt.com<mailto:philip.eardley@bt.com>
Envoyé : mardi 15 novembre 2016 17:24
À : multipathtcp@ietf.org<mailto: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 text 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 features two proxies, one in the home gateway ('CPE') and one in the network, both 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 criteria. The WG Chairs will produce the initial version.

* analysis of proposed solutions 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 favoured solution.

Comments?
Thanks
Phil & Yoshi