Re: [multipathtcp] potential MPTCP proxy charter item

<> Tue, 08 November 2016 08:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B052E129440 for <>; Tue, 8 Nov 2016 00:08:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.115
X-Spam-Status: No, score=-3.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MEoFWZn-8Ghj for <>; Tue, 8 Nov 2016 00:08:29 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 601A11293D8 for <>; Tue, 8 Nov 2016 00:08:29 -0800 (PST)
Received: from (unknown [xx.xx.xx.66]) by (ESMTP service) with ESMTP id AE4912032D; Tue, 8 Nov 2016 09:08:27 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by (ESMTP service) with ESMTP id 7693B120079; Tue, 8 Nov 2016 09:08:27 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0319.002; Tue, 8 Nov 2016 09:08:27 +0100
To: Alan Ford <>, "" <>
Thread-Topic: [multipathtcp] potential MPTCP proxy charter item
Thread-Index: AQHSORUenemdljzUmEGiGID3gGUCC6DOuRdw
Date: Tue, 08 Nov 2016 08:08:26 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009DADF3F@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <> <> <> <787AE7BB302AE849A7480A190F8B933009D9577B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <22907_1476946228_58086934_22907_5464_1_a7bca8d2-7656-4ff0-9f01-cf307f017148@OPEXCLILM42.corporate.adroot.infra.ftgroup> <> <> <b8bfd5c6-21eb-4c4f-879a-851c3a71792a@OPEXCLILM31.corporate.adroot.infra.ftgroup> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009DADF3FOPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [multipathtcp] potential MPTCP proxy charter item
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: Tue, 08 Nov 2016 08:08:30 -0000

Hi Alan,

Please see inline.


De : Alan Ford []
Envoyé : lundi 7 novembre 2016 17:37
À :
Objet : Re: [multipathtcp] potential MPTCP proxy charter item

Hi Olivier,

On 7 Nov 2016, at 07:50, Olivier Bonaventure <<>> wrote:

Why is it an /option/, however? When you are explicitly targeting a
proxy node, surely the proxy is just as capable of pulling the data out
of the payload here?

Because the addressing information that is used for the proxy is part of the control plane and not part of the bytestream. I think that it is very important from an architectural viewpoint to maintain a clean separation between the byte stream that is exchanged between the applications and all control information that should be placed inside options.

We explore the possibility of adding information in the bytestream for MPTCP and eventually decided to place all control information in options. If you look at HTTP, proxy-related information is part of the HTTP headers and not part of the payload. This is the same type of problem.

And this appears to be where we fundamentally disagree. I don’t see this as part of the control plane, I see proxying (at least in explicit mode) as an application of MPTCP, and should be at the application layer.

[Med] I still don’t understand this subtlety between “application of MPTCP” (you claim) and “MPTCP-specific use case” (we claim). If we extrapolate your argument, one can object that multi-pathing is an “application of TCP” (not even specific to TCP), and should not be defined as a TCP option. But the reality is that there is a TCP option for multi-pathing.

It seems too specific an application to be embedded in the protocol. This does not seem equivalent to NAT, since it is requiring additional signalling.

[Med] FWIW, instructing NAT state with in-band signaling information is specified by the IETF and widely deployed:




Similarly I don’t see it compares like-for-like with HTTP headers and payload; HTTP is an application-layer protocol.

Having said that, data can now be tunnelled in HTTP e.g. by using WebSockets. I see this as an application-layer negotiation: negotiate the escalation to WebSockets, then you have a bidirectional socket in operation. This is closer to the tunnelling you propose; however, I see this very much as a negotiation at the first few bytes of the payload, followed by the data.