Re: [multipathtcp] potential MPTCP proxy charter item

<> Fri, 04 November 2016 09:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA2BB1293FC for <>; Fri, 4 Nov 2016 02:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.618
X-Spam-Status: No, score=-1.618 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, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0ltBecYuC3Yf for <>; Fri, 4 Nov 2016 02:43:31 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DC414129411 for <>; Fri, 4 Nov 2016 02:43:29 -0700 (PDT)
Received: from (unknown [xx.xx.xx.2]) by (ESMTP service) with ESMTP id 6984E264267; Fri, 4 Nov 2016 10:43:27 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown []) by (ESMTP service) with ESMTP id 3778E27C0A1; Fri, 4 Nov 2016 10:43: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; Fri, 4 Nov 2016 10:43:26 +0100
To: Alan Ford <>
Thread-Topic: [multipathtcp] potential MPTCP proxy charter item
Thread-Index: AQHSNdzSQgvumHnbm0arzSIWTM7lXaDIjnDg
Date: Fri, 04 Nov 2016 09:43:26 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009DAC5B0@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <> <787AE7BB302AE849A7480A190F8B933009D945B7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <> <> <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> <> <787AE7BB302AE849A7480A190F8B933009D9CA84@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009DAAA88@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_787AE7BB302AE849A7480A190F8B933009DAC5B0OPEXCLILMA3corp_"
MIME-Version: 1.0
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2016.11.4.90616
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: Fri, 04 Nov 2016 09:43:33 -0000

Hi Alan,

Please see inline.


De : Alan Ford []
Envoyé : jeudi 3 novembre 2016 15:16
Cc :
Objet : Re: [multipathtcp] potential MPTCP proxy charter item

Hi Med,

Comments inline...

On 3 Nov 2016, at 09:26,<> wrote:

-----Message d'origine-----
De : Alan Ford []
Envoyé : mercredi 2 novembre 2016 15:07
Cc :<>
Objet : Re: [multipathtcp] potential MPTCP proxy charter item
By the diagrams,

it needs to now that a destination is not MPTCP capable - how does it

this knowledge?

[Med] The default behavior is that it does convert the MPTCP connection
into a TCP connection without requiring any knowledge about the
destination. This default behavior is motivated by the current support of
MPTCP at the servers side. The text can deal with optimization like the
one you suggested, but we left those out of scope for the moment.

Should it actually be intercepting the SYN/ACK from RM and

making adjustments there?

[Med] See above. (various optimization triggers can be considered:
inspect SYN/ACK, configured servers whitelist, etc.)

This continues in the discussion - what is the purpose of
MP_CONVERT in the implicit mode?

[Med] It is there to distinguish native MPTCP connections that can be
established from an MPTCP host from those that are required to be proxied.
If the option is not included, this flow will experienced:

  _________________MULTIPLE PATH CLIENT/SERVER___________
 /                                                       \
              |                              |
  |           |                              |           |
  |src:c2@    |src:uMCP@1             dst:s1@|src:uMCP@1 |
  |<=MPTCP====|=============================>|<-TCP Leg->|
  |    dst:s2@|                              |    dst:s2@|
  |           |                              |           |
 +--+      +-----+                         +-----+      +--+
 |C2|      | MCP |                         | MCP |      |S2|
 +--+      +-----+                         +-----+      +--+
           Upstream                     Downstream

     Example of a Broken E2E MPTCP Connection (On-path)

While we wanted to achieve this:

  _________________MULTIPLE PATH CLIENT/SERVER___________
 /                                                       \
              |                              |
  |           |                              |           |
  |src:c2@    |src:uMCP@1             dst:s1@|src:uMCP@1 |
  |    dst:s2@|                              |    dst:s2@|
  |           |                              |           |
 +--+      +-----+                         +-----+      +--+
 |C2|      | MCP |                         | MCP |      |S2|
 +--+      +-----+                         +-----+      +--+
           Upstream                      Downstream

   Example of a Successful E2E MPTCP Connection (On-path)

OK, so this is saying “I’ve already been proxied, don’t proxy me again”.

[Med] Yes.

You corrected this later to “No” … So what does it mean? In fact, “please proxy me” ?
[Med] The presence of the option is an indication to be proxied.

However, I don’t understand the scenario you’ve drawn above.

[Med] The scenario is about an MPTCP-capable host located behind a CPE(MCP). This is typically an iPhone connected behind a CPE. We want that MPTCP communications issued from this host are forwarded as such to their destination without soliciting the downstream MCP.

OK I understand this scenario now, it is special for implicit mode, since if the CPE was acting in explicit mode, it would address the packets to the MCP.

What are the benefits of using implicit mode in this scenario? This is so you can target it to an MCP without knowing the target address. Are there any other reasons why this would be used rather than explicit mode?
[Med] The document avoids on purpose to compare “implicit” vs. “explicit”; this is left to the taste of each operator. That said, the only difference I see compared to the explicit mode for the case we are discussing, is that the CPE does not need to modify the initial subflow to be directly sent to the downstream MCP. I don’t consider that to be a “benefit” because this rewriting will be done for subsequent flows.

And what sort of deployment would this scenario exist in?
[Med] A deployment scenario would be a cluster of MCPs at the operator’s network; the MCP instance (i.e., IP address of MCP) that will be solicited to handle a given connection will be determined based on the real-time load distribution, for instance. Once an instance is elected to process a new MPTCP connection, the corresponding IP address will be advertised to steer subsequent subflows. I’m not arguing in favor of this deployment case, but I’m just sketching something that may be considered.