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

<> Fri, 22 July 2016 06:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8AC0212D68B for <>; Thu, 21 Jul 2016 23:04:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.205
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jSlbKLVPwhCm for <>; Thu, 21 Jul 2016 23:04:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 459B812D589 for <>; Thu, 21 Jul 2016 23:04:25 -0700 (PDT)
Received: from (unknown [xx.xx.xx.70]) by (ESMTP service) with ESMTP id CD978405BF for <>; Fri, 22 Jul 2016 08:04:23 +0200 (CEST)
Received: from localhost.localdomain (unknown []) by (ESMTP service) with ESMTP id BF0961A0065 for <>; Fri, 22 Jul 2016 08:04:23 +0200 (CEST)
Received: from by with queue id 176446-13 for; Fri, 22 Jul 2016 06:04:23 GMT
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by (ESMTP service) with ESMTP id 97AA61A0057; Fri, 22 Jul 2016 08:04:23 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0301.000; Fri, 22 Jul 2016 08:04:23 +0200
From: <>
To: "" <>, "" <>
Thread-Topic: towards a potential work item on two-ended proxy
Thread-Index: AdHjZ4nHkoHVP9v7Rwqgdt1DLC/zlgAcsE6Q
Date: Fri, 22 Jul 2016 06:04:22 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933008DEB133@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_787AE7BB302AE849A7480A190F8B933008DEB133OPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy
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: Fri, 22 Jul 2016 06:04:27 -0000

Hi Phil,

Please see inline.


De : multipathtcp [] De la part de
Envoyé : jeudi 21 juillet 2016 18:13
À :
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).

[Med] Indeed! Endorsing this activity in the MPTCP WG is the natural way to assist in defining interoperable MPTCP proxies. There is a real need expressed by operators and vendors to work on this.

-          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)

[Med] Both one-ended proxy and two-ended proxy makes sense. These are covered for example in the plain-mode draft. The proposed solution allows to differentiate between native MPTCP connections from proxied connections to help e2e MPTCP connection establishment if both the client and server are MPTCP-capable. Please note that network operators do not have control on the terminals connected behind a CPE, and that those terminals are not even aware of the presence of a proxy in the path.

-          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?

[Med] As mentioned during the meeting, all these deployment use cases make use of the same option. It is up to the taste of each operator to decide about its own deployment mode. As a WG, we don't need to decide about that.

-          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.

[Med] That's a fair point. Cross area reviews can always be managed, but the point is to have a starting home for the activity.

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 foro it).
[Med] I have other sub-items that I would like to see included in the (hopefully) proposed charter update. I will share that when a text proposal is on the table.

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