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

<christian.jacquenet@orange.com> Fri, 22 July 2016 06:55 UTC

Return-Path: <christian.jacquenet@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 53D8E12D918 for <multipathtcp@ietfa.amsl.com>; Thu, 21 Jul 2016 23:55:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.205
X-Spam-Level:
X-Spam-Status: No, score=-3.205 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, 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 7g07PfXVq--G for <multipathtcp@ietfa.amsl.com>; Thu, 21 Jul 2016 23:55:17 -0700 (PDT)
Received: from relais-inet.orange.com (relais-nor34.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 76A2212D660 for <multipathtcp@ietf.org>; Thu, 21 Jul 2016 23:55:17 -0700 (PDT)
Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id EDA82C0565 for <multipathtcp@ietf.org>; Fri, 22 Jul 2016 08:55:15 +0200 (CEST)
Received: from localhost.localdomain (unknown [127.0.0.1]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id DFBA34007B for <multipathtcp@ietf.org>; Fri, 22 Jul 2016 08:55:15 +0200 (CEST)
Received: from opfednr04.rouen.francetelecom.fr by opfednr04.rouen.francetelecom.fr with queue id 186560-11 for multipathtcp@ietf.org; Fri, 22 Jul 2016 06:55:15 GMT
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.57]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id BFDE140078; Fri, 22 Jul 2016 08:55:15 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0301.000; Fri, 22 Jul 2016 08:55:15 +0200
From: <christian.jacquenet@orange.com>
To: "philip.eardley@bt.com" <philip.eardley@bt.com>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Thread-Topic: towards a potential work item on two-ended proxy
Thread-Index: AdHjZ4nHkoHVP9v7Rwqgdt1DLC/zlgAfHeEw
Date: Fri, 22 Jul 2016 06:55:15 +0000
Message-ID: <4913_1469170515_5791C353_4913_2200_1_88132E969123D14D9BD844E1CD516EDE130B0F00@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <b779dd12f1bb412c96c800eddaaf0247@rew09926dag03b.domain1.systemhost.net>
In-Reply-To: <b779dd12f1bb412c96c800eddaaf0247@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_88132E969123D14D9BD844E1CD516EDE130B0F00OPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/JIeYzvISxCZ8bSFENUKYOBcJrrU>
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jul 2016 06:55:20 -0000

Hello Philip, all,

I believe the mptcp WG charter should evolve to include MPTCP proxy-related work. As you rightfully mention in your message below, this would be a timely effort (besides what's being cooked by the BBF) that is primarily motivated by the existing and forthcoming development of so-called hybrid access service offerings in Europe and Asia, and possibly in other regions of the world.

I also think that the proposed approaches (namely draft-boucadair and draft-peirens) that have been presented during the mptcp WG session are rather meant to foster massive MPTCP adoption rather than hindering it.

As for the charter update, I would encourage the documentation of a problem statement with companion use cases, as well as the standardization of the corresponding solution, presumably based upon the merging of the aforementioned drafts to accommodate all use cases.

Let me also second Med's recent reply to this message. I too volunteer to contribute to the updated charter text, assuming there's hopefully consensus to move towards that direction.

Cheers,

Christian.

De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de philip.eardley@bt.com
Envoyé : jeudi 21 juillet 2016 18:13
À : multipathtcp@ietf.org
Objet : [multipathtcp] towards a potential work item on two-ended proxy

We started the discussion yesterday on a potential new work item on "two-ended proxy scenario" - where there's an MPTCP proxy in both the CPE and an aggregation point (for instance). The current charter is that one end host is MPTCP.

If I can try and summarise the brief discussion yesterday (plus some side discussions) (please correct my inaccuracies):

-          there are now deployments & products with an MPTCP proxy at each end, plus planned Broadband Forum work (WT-348 is about to be made public, with subsequent work to follow). So IETF work is timely (eg help allow an operator to buy CPE from one vendor and aggregation gateway from another vendor).

-          However, some people object to going beyond the current charter's "one-ended proxy scenario" (since the "two-ended proxy" discourages deployment of MPTCP to all the end hosts, which is the ultimate goal)

-          There are two proposals (transparent & plain mode: draft-boucadair-mptcp-plain-mode-08 & draft-peirens-mptcp-transparent-00). Are these addressing different use cases, or do we need to choose between them? would a (potential) charter item be to standardise existing draft(s), or to solve a problem /scenario?

-          I think there was mention (by Wim??) that there's a third proposal - how does this fit in, or did I get it wrong?

-          One aspect of the plain mode draft is to allow transport of UDP traffic as well as TCP traffic. I think this is a proposal that should be discussed separately  - for instance it needs INT-area expertise.

I think it would be good to have more discussion before attempting to write some potential charter text (and then seeing if there's consensus for it).

Thanks!
Philip Eardley
Research and Innovation
This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.