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

"Henderickx, Wim (Nokia - BE)" <> Sat, 23 July 2016 07:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 933FE12D755 for <>; Sat, 23 Jul 2016 00:16:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xv3GtHw4EWK5 for <>; Sat, 23 Jul 2016 00:16:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A90BA12D660 for <>; Sat, 23 Jul 2016 00:16:11 -0700 (PDT)
Received: from (unknown []) by Websense Email Security Gateway with ESMTPS id CDDE197F59E33; Sat, 23 Jul 2016 07:16:07 +0000 (GMT)
Received: from ( []) by (GMO-o) with ESMTP id u6N7G8pj010879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 23 Jul 2016 07:16:09 GMT
Received: from ( []) by (GMO) with ESMTP id u6N7G7TZ028394 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 23 Jul 2016 09:16:07 +0200
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Sat, 23 Jul 2016 09:16:07 +0200
From: "Henderickx, Wim (Nokia - BE)" <>
To: "" <>, "Christoph Paasch" <>, Philip Eardley <>
Thread-Topic: [multipathtcp] towards a potential work item on two-ended proxy
Thread-Index: AQHR4/oodDE8Hq+810K/F7XEsZLkuaAkLP6wgAFvNQA=
Date: Sat, 23 Jul 2016 07:16:07 +0000
Message-ID: <>
References: <> <> <787AE7BB302AE849A7480A190F8B933008DEB3EA@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933008DEB3EA@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Accept-Language: nl-BE, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_CF22A0EDE6754C9C974BBA3E0C623774nokiacom_"
MIME-Version: 1.0
Archived-At: <>
Cc: MultiPath TCP - IETF WG <>
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: Sat, 23 Jul 2016 07:16:14 -0000

In-line WH>

From: multipathtcp <<>> on behalf of "mohamed. boucadair" <<>>
Date: Friday 22 July 2016 at 11:41
To: Christoph Paasch <<>>, Philip Eardley <<>>
Cc: MultiPath TCP - IETF WG <<>>
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy

Hi Christoph,

Please see inline.


De : multipathtcp [] De la part de Christoph Paasch
Envoyé : vendredi 22 juillet 2016 11:19
À : Philip Eardley
Cc : MultiPath TCP - IETF WG
Objet : Re: [multipathtcp] towards a potential work item on two-ended proxy


On Jul 21, 2016, at 6:12 PM,<> wrote:
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 the proxy-work is built of two items:

1. The documentation of how a deployment of one-ended and two-ended proxies look a like and the things that one should consider when doing so.

2. The plain-mode-option.

The point 1) is specific to MPTCP and probably useful to include in the charter.

For the point 2), I agree with Alan's comment in that this is entirely independent from MPTCP.
[Med] I don’t quite understand this argument, but fwiw the plain mode option is there to address various goals such as:

·         Allow to distinguish native MPTCP connections from proxied MPTCP connections. Without this PM signal, native MPTCP connections may be “broken” by an upstream proxy that will revert them into a TCP connection!

·         Avoid breaking IPv6 applications that make use of address referrals, as the source IPv6 of the terminal located behind a CPE is preserved even when MPTCP proxies are in path.

·         Avoid encapsulation and out of band signaling that will degrade the overall connection setup delay.

BTW, if the argument that signaling an IP address in a TCP option has nothing to do with TCP (which is supposed to deal with layer 4) was made for MPTCP, MPTCP would never been RFCed!

It is basically a mechanism for 0-RTT proxying, by communicating the relevant IP-addresses between the proxies.
[Med] This is ** one ** of the features that is offered by the option in addition to those I mentioned above.

Thus, I don't think that we should specify the plain-mode option in the MPTCP working-group, as the same plain-mode option might be useful in any other transport-layer protocol. And we probably don't want a list of draft-sctp-plain-mode, draft-tcp-plain-mode, ...
[Med] TCP and SCTP were there before MPTCP for so long, so if there were cases in which a “plain mode”-like option is needed, it would have been specified since a while! The plain mode is proposed as an MPTCP solution to an MPTCP problem.

WH> On the option, which will be needed in the proxy, I understand it could be generic but we don’t have use cases in other scenario’s (like SCTP). So I propose we can inform people about this but keep the work in MPTCP since this is where the requirement, solution comes from.


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

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

multipathtcp mailing list<>