Re: [multipathtcp] q about on-path proxy

<> Fri, 24 March 2017 13:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D795E131463 for <>; Fri, 24 Mar 2017 06:57:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Status: No, score=-2.619 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 DTScuM6WA9wg for <>; Fri, 24 Mar 2017 06:57:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ED33C12940B for <>; Fri, 24 Mar 2017 06:57:31 -0700 (PDT)
Received: from (unknown [xx.xx.xx.66]) by (ESMTP service) with ESMTP id 4FE78404CA; Fri, 24 Mar 2017 14:57:30 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.57]) by (ESMTP service) with ESMTP id 592B2120055; Fri, 24 Mar 2017 14:57:29 +0100 (CET)
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.0319.002; Fri, 24 Mar 2017 14:57:28 +0100
To: "" <>, "" <>, "" <>
CC: "" <>
Thread-Topic: [multipathtcp] q about on-path proxy
Date: Fri, 24 Mar 2017 13:57:27 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E4011C@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <> <> <787AE7BB302AE849A7480A190F8B933009E37584@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009E3C5EC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <> <> <787AE7BB302AE849A7480A190F8B933009E3FE7E@OPEXCLILMA3.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_787AE7BB302AE849A7480A190F8B933009E4011COPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [multipathtcp] q about on-path proxy
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: Fri, 24 Mar 2017 13:57:35 -0000

Hi Phil,

Please see inline.


De : []
Envoyé : vendredi 24 mars 2017 14:11
Cc :
Objet : RE: [multipathtcp] q about on-path proxy

Forgot something, added in line

From: multipathtcp [] On Behalf Of<>
Sent: 24 March 2017 07:29
Subject: Re: [multipathtcp] q about on-path proxy

Following up on this.
I want to concentrate first **specifically** on the solution for this use case:

<<. The other scenario involves an MPTCP-enabled smartphone, with LTE and WiFi, plus a proxy in the operator’s network.>>
[Med] IMHO, the implicit mode is more suitable for the dual-proxy case rather than the single proxy…but let’s discuss this one.

Looking first at the solution using MP_PREFER_PROXY on the SYN  ("implicit mode" solution)

I think the assumption is:
* the smartphone knows that the other end point is not MPTCP enabled, or prefers to use a proxy even if the other end point is MPTCP enabled.

I don’t like this assumption as it hinders end-to-end deployment of MPTCP.
[Med] It doesn’t. The MCP can be removed from the path if the MP_CAPABLE is received from the RM.

Solution could be something on the lines you suggest below:
* the proxy tracks what end points are MPTCP enabled and which ones aren’t. I think this would run into scaling and DoS problems.
[Med] Scaling is not an issue here given that the implicit mode assumes that MCP inspects all TCP traffic. Tracking the 3WHS of the initial subflow and then get out from the connection if DST is MPTCP-capable is more optimal compared to systematically be inserted in all connections. Means to mitigate DoS problems are called out in the draft (rate-limit state creation, limit subflow creation, etc.).

* or the smartphone tracks what end points are enabled and which ones aren’t; it needs to do this by which interface it tries to reach the other end point. Could be quite a lot of info to track
[Med] A white list approach may be considered in early stages. That is always insert MP_PREFER_PROXY except for this list of servers.

Perhaps it’s possible to devise a solution where the proxy adds a  HI_I_AM_A_PROXY onto the SYN_ACK (assuming the SYN_ACK goes through the proxy). Not sure what the next step would be. I guess one approach is to give up on the first connection and immediately send a new SYN with a PROXY_PLEASE_INSERT_YOURSELF. Seems to be getting cumbersome?
[Med] This increases the delay of the connection establishment for non-obvious added value.

Another assumption, I think is:
* connection is initiated from the smartphone
It would be nice if the solution also worked for connections initiated by the other end point (and definitely nothing bad must happen)
[Med] For incoming connections (MCP-to-UE), there is no need to insert MP_PREFER_PROXY.

Do the currently deployed solutions for the smartphone scenario use MP_PREFER_PROXY, or do they use an “explicit mode” solution?
[Med] The deployments I’m aware of are using the explicit mode.


From: multipathtcp [] On Behalf Of<>
Sent: 24 March 2017 01:42
To: Yoshifumi Nishida <<>>;<>
Cc: multipathtcp <<>>
Subject: Re: [multipathtcp] q about on-path proxy

Hi Yoshi,

Please see inline.


De : Yoshifumi Nishida []
Envoyé : jeudi 23 mars 2017 23:38
Cc : multipathtcp
Objet : Re: [multipathtcp] q about on-path proxy

Hello Olivier, Med,

Thanks for providing detailed responses. I feel that things now got clearer than before.
In my understanding, the benefits for on-path mode is MCP can stop intercepting and splitting connection once it learns that both endpoints support MPTCP.  if there're other benefits, please point out.

One thing which is not very clear to me yet is MP_PREFER_PROXY.
Med explained that there is a way to learn the endpoints support MPTCP. I think MCPs can learn it through the method described in Figure 15, however I'm not sure how the sender can learn it.
[Med] An implementation example would look like the following :

•         A sends a SYN message with MP_CAPABLE+MP_PREFER_PROXY to B

•         This SYN is intercepted by an MCP which tracks the connection, that is: it removes the MP_PREFER_PROXY and add filters to intercept relevant incoming SYN/ACK. The SYN (MP_CAPABLE) is then forwarded to the next hop and so on, until it reaches B.

•         If the SYN/ACK received from B includes MP_CAPABLE, the MCP will forward it to A. A is now aware that B is MPTCP-capable and they can establish subsequent subflows directly. The MCP does not announce explicitly itself to A.

This makes me wonder why the sender needs to set MP_PREFER_PROXY.
[Med] The entity that sets the MP_PREFER_PROXY is likely to be an MCP. This is the typical dual-proxy case. This signal is set so that native MPTCP connections received from hosts of a LAN are distinguished from the connections the MCP transforms into MPTCP. An MCP located at the network side will intercept those connections that are proxied; not the ones that can be managed by endhosts.

This signal is motivated also by the requirements from MCP operators to control the usage of their MCP resources: only proxied MPTCP connections are assisted by an MCP.
The signal is also a guard against MCPs that will by default transform an MPTCP connection into a TCP connection. Allowing native connections to bypass that MCP is good to have.

Instead, I am thinking that using a certain option or flag that indicates "MCP has intercepted this flow" may look more reasonable. This seems to be more explicit signal to the downstream MCP.
[Med] Thank you for sharing your preference. I’m personally neutral on the structure of the MP_PREFER_PROXY signal. The most important point at this stage is to assess whether we need it or not.

Also, even when on-path MCP is not there, the sender might put MP_PREFER_PROXY. This looks the waste of resource.
[Med] This is a fair enough.


On Thu, Mar 23, 2017 at 1:11 AM, Olivier Bonaventure <<>> wrote:

Thanks for the response. I think I got basic idea.  Now I have other
I feel on-path mode a bit more complex than off-path mode.

1:  I am thinking that when uMCP intercept the packet from C, we can
send MP_Convert Information Element to dMCP.
    (and dest will be dMCP instead of S)
    We don't need to use source routing and spoofing techniques on dMCP
in this approach, which looks simpler to me.

There are three abstract ways to ensure that the packets from the uMCP reach the dMCP.

- influence the control plane (e.g. routing tables by using source specific routing) of the network between the uMCP and the dMCP to ensure that the packets reach the dMCP
- change all network packets (e.g. by using source routing)
- change the destination address of all flows initiated by the client

An advantage of the fist solution is that there is no per-packet overhead. A disadvantage of this solution is that it can be costly in a large network to implement and maintain this source specific routing.

An advantage of the second solution is that the IP addresses of the endpoints are preserved. A drawback of this solution is that there is a per packet overhead.

A drawback of the latter solution is that the network operator does not have visibility anymore on the traffic between the uMCP and the dMCP. All traffic appears as TCP connections to the dMCP. An advantage of this solution is that its overhead is minimised since only the SYN carries an additional TCP option.

There is no clear winner among these solutions and we should let the operators select the approach that better suits their deployment and operational concerns.

2: I am wondering how a sender will use MP_PREFER_SIGNAL.
    In my understanding, the possible use cases would be:
         a) A sender knows the receiver doesn't support MPTCP, but it
still wants to utilize MPTCP in some portions of path.
             In this case, it seems to me that we presume the existence
of MCP.
             If so, why we cannot use explicit mode (off-path mode) here?

         b) A sender not sure if the receiver supports MPTCP or not.
But, even if the receiver doesn't support MPTCP, it wants to use MPTCP
in some portions of path at least.
            In this case, uMCP will intercept packets and split the
connection regardless of whether the receiver supports MPTCP.
            The sender cannot know if the receiver supports MPTCP or not
because MCP works transparently.
            So, it can never learn about the receiver.
            If I think this way, it seems MP_PREFER_SIGNAL is not
beneficial when the receiver supports MPTCP.

Currently, the main usage is the following in transparent mode

C --- uMCP ------ R1 ------ dMCP -------- R2 ------ S

The client wants to create a Multipath TCP connection towards S. A typical example is that C is an iPhone using the Siri application and S is Apple's server.

The uMCP and dMCP are useful when either the Client or the Server does not support Multipath TCP. If they both support Multipath TCP, it could be useful to allow the connection to pass through the uMCP and dMCP without terminating it. To achieve this in transparent mode, the dMCP must be able to distinguish between :

- a SYN containing an MP_CAPABLE option that was added by the uMCP and that must be terminated by the dMCP
- a SYN containing an MP_CAPABLE option that was inserted by the Client and should not be terminated by the dMCP

This is basically one bit of information. The MP_PREFER_PROXY option indicates that the MP_CAPABLE option was added by an upstream MCP and the connection should be terminated by a downstream MCP.

There are other use cases where the uMCP does not want the dMCP to terminate the Multipath TCP connections for policy reasons or because the uMCP knows that the server directly supports Multipath TCP.

I'm not a big fan of using an entire Multipath TCP option to carry one bit of information in the SYN. I would prefer to define a Proxy flag inside the MP_CAPABLE option as proposed several years ago on this list. This would be a clean solution with a very small overhead. We have spare bits in the MP_CAPABLE option.