Re: [multipathtcp] Consensus call on potential MPTCP proxy work

<> Tue, 18 April 2017 08:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D77C31292AE for <>; Tue, 18 Apr 2017 01:24:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.399
X-Spam-Status: No, score=-5.399 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_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U4tlqfDGB7-a for <>; Tue, 18 Apr 2017 01:24:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 37901131803 for <>; Tue, 18 Apr 2017 01:24:43 -0700 (PDT)
Received: from (unknown [xx.xx.xx.70]) by (ESMTP service) with ESMTP id DAE98202C8 for <>; Tue, 18 Apr 2017 10:24:41 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by (ESMTP service) with ESMTP id 9FE4B1A0062; Tue, 18 Apr 2017 10:24:41 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0319.002; Tue, 18 Apr 2017 10:24:41 +0200
To: "" <>, "" <>
Thread-Topic: Consensus call on potential MPTCP proxy work
Thread-Index: AdK4HBNY1jXzvDFKRxmRsHBM53IcbgAAOnRw
Date: Tue, 18 Apr 2017 08:24:40 +0000
Message-ID: <5406_1492503881_58F5CD49_5406_4781_1_88132E969123D14D9BD844E1CD516EDE142F90B5@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_88132E969123D14D9BD844E1CD516EDE142F90B5OPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Apr 2017 08:24:45 -0000

Hello WG,

I fully support the MPTCP proxy work.



De : multipathtcp [] De la part de
Envoyé : mardi 18 avril 2017 10:17
À :
Objet : [multipathtcp] Consensus call on potential MPTCP proxy work

During the MPTCP meeting in Chicago we did several hums about potential MPTCP proxy work. Our interpretation of these hums is that we should do a consensus call for the following work:
MPTCP is now seeing widespread deployment in networks to bond together two accesses, such as fixed and mobile broadband, by using two MPTCP proxies, one in the home gateway or Customer Premises Equipment and one in the network. The WG develops a solution where the proxies are both under the control of the operator and where it is assumed that they are not on the default path. The solution is based on using the payload of an MPTCP packet to transfer a signalling message between the proxies. It is believed the solution will not require changes to RFC6824bis. The solution may require a means of configuring set-up information in the proxies, which would be done in coordination with other IETF WGs such as DHC. The WG does not develop a mechanism for the two proxies to discover each other.
Please say whether you support, or don't support, such work - so we can see if there's consensus for it.
Phil & Yoshi

Hums during the meeting:

*         Should the MPTCP WG do any MPTCP proxy work, or do none - about 2:1 or 3:1 in favour of doing work

*         Should the MPTCP WG do proxy work based on option #1 in slide 12? Strongly more yes than no

*         Should the MPTCP WG do proxy work based on option #2 in slide 12? more no than yes

*         Should the MPTCP WG do proxy work based on option #3 in slide 12? Weak & roughly equal
We believe the work does not require an update to the MPTCP WG charter.


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.