Re: [multipathtcp] Proposed charter text for MPTCP proxy item

<mohamed.boucadair@orange.com> Wed, 16 November 2016 10:06 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 7FAE71296F3 for <multipathtcp@ietfa.amsl.com>; Wed, 16 Nov 2016 02:06:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.115
X-Spam-Level:
X-Spam-Status: No, score=-4.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 3B0kUN6yxFwH for <multipathtcp@ietfa.amsl.com>; Wed, 16 Nov 2016 02:06:18 -0800 (PST)
Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D4D61296D2 for <multipathtcp@ietf.org>; Wed, 16 Nov 2016 02:06:18 -0800 (PST)
Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id D2BDA40301 for <multipathtcp@ietf.org>; Wed, 16 Nov 2016 11:06:16 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.33]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 99F291A005B; Wed, 16 Nov 2016 11:06:16 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM42.corporate.adroot.infra.ftgroup ([fe80::d5fd:9c7d:2ee3:39d9%19]) with mapi id 14.03.0319.002; Wed, 16 Nov 2016 11:06:16 +0100
From: <mohamed.boucadair@orange.com>
To: "philip.eardley@bt.com" <philip.eardley@bt.com>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Thread-Topic: Proposed charter text for MPTCP proxy item
Thread-Index: AdI/XEJXR/6DctdbSpOPmSDb5MGITgAi7PwA
Date: Wed, 16 Nov 2016 10:06:16 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009DB4C79@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <524e75d3f95d4b51892a8f54ad2f6edd@rew09926dag03b.domain1.systemhost.net>
In-Reply-To: <524e75d3f95d4b51892a8f54ad2f6edd@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.5]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009DB4C79OPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/hfoTtncrzJo6YY3BpmsaWV6VWL8>
Subject: Re: [multipathtcp] Proposed charter text 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: Wed, 16 Nov 2016 10:06:20 -0000

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
Envoyé : mardi 15 novembre 2016 17:24
À : 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