Re: [multipathtcp] q about on-path proxy

Yoshifumi Nishida <> Thu, 23 March 2017 22:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 204A912948D for <>; Thu, 23 Mar 2017 15:37:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PuVHGL06_E-3 for <>; Thu, 23 Mar 2017 15:37:53 -0700 (PDT)
Received: from ( [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 04396129B0F for <>; Thu, 23 Mar 2017 15:37:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id 9FA5D29C163 for <>; Fri, 24 Mar 2017 07:37:45 +0900 (JST)
Received: by with SMTP id a12so127824229ota.0 for <>; Thu, 23 Mar 2017 15:37:45 -0700 (PDT)
X-Gm-Message-State: AFeK/H3f0AYTXrKFU3RkEw9OOW0CAi65qg1iQy3rRB0B571iLbQ9AH8kEjICr69sxbeGGrvr3h1UWgxzomGBzQ==
X-Received: by with SMTP id l68mr2989920otc.242.1490308664330; Thu, 23 Mar 2017 15:37:44 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 23 Mar 2017 15:37:43 -0700 (PDT)
In-Reply-To: <>
References: <> <> <787AE7BB302AE849A7480A190F8B933009E37584@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009E3C5EC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <>
From: Yoshifumi Nishida <>
Date: Thu, 23 Mar 2017 15:37:43 -0700
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: "" <>,
Cc: multipathtcp <>
Content-Type: multipart/alternative; boundary="001a11492f9a8b38e9054b6d86be"
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: Thu, 23 Mar 2017 22:37:56 -0000

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.

This makes me wonder why the sender needs to set MP_PREFER_PROXY.
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.
Also, even when on-path MCP is not there, the sender might put
MP_PREFER_PROXY. This looks the waste of resource.


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

> Yoshifumi,
>> Thanks for the response. I think I got basic idea.  Now I have other
>> questions..
>> 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.
> Olivier