Re: [multipathtcp] q about off-path proxy (explicit mode)

<> Tue, 28 March 2017 12:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 484471294E8 for <>; Tue, 28 Mar 2017 05:20:23 -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 vrTQpSkhzK9c for <>; Tue, 28 Mar 2017 05:20:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EE9921294F0 for <>; Tue, 28 Mar 2017 05:20:20 -0700 (PDT)
Received: from (unknown [xx.xx.xx.5]) by (ESMTP service) with ESMTP id CB37212017E; Tue, 28 Mar 2017 14:20:19 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by (ESMTP service) with ESMTP id AA79F18006C; Tue, 28 Mar 2017 14:20:19 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0319.002; Tue, 28 Mar 2017 14:20:19 +0200
To: Yoshifumi Nishida <>
CC: multipathtcp <>
Thread-Topic: [multipathtcp] q about off-path proxy (explicit mode)
Thread-Index: AQHSpz+qcm3cqKOvxUyUCpDXyxL9OKGqKhNg
Date: Tue, 28 Mar 2017 12:20:18 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E41E30@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <> <787AE7BB302AE849A7480A190F8B933009E41157@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009E41571@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_787AE7BB302AE849A7480A190F8B933009E41E30OPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [multipathtcp] q about off-path proxy (explicit mode)
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: Tue, 28 Mar 2017 12:20:23 -0000

Hi Yoshi,

Please see inline.


De : Yoshifumi Nishida []
Envoyé : lundi 27 mars 2017 16:18
Cc : Yoshifumi Nishida; multipathtcp
Objet : Re: [multipathtcp] q about off-path proxy (explicit mode)

Hi Med,

On Mon, Mar 27, 2017 at 12:32 PM, <<>> wrote:

Please see inline.


De : Yoshifumi Nishida [<>]
Envoyé : lundi 27 mars 2017 13:21
Cc : Yoshifumi Nishida; multipathtcp
Objet : Re: [multipathtcp] q about off-path proxy (explicit mode)

Hi Olivier, Med,

Thanks for the response. I have been thinking that it would be better if we can classify our use cases so that we can have clear vision for what to solve. Things I may want to classify is:
   a) solutions requires changes in only MPTCP or in TCP general
   b) solutions requires proxies to be on-path or solutions that work with off-path proxy.

We can think about the solutions for a) if we think it's necessary, but I am thinking that the proper venue for the discussion might not be this WG.

I think the approach Med mentioned requires the proxy to be on-path, so I would like to classify it as an on-path solution.
[Med] I’m not sure to follow you here. What I described is aligned with the target dual proxy case ( the first proxy is embedded on a CPE. There is no technical problem there to intercept the traffic to be proxyied given that the CPE sees all the traffic.

Well, this classification might be a bit different from the way described in the draft.
What I meant for off-path (explicit) case is the cases where the proxy is not on the path between client and server. No more and no less.
[Med] I see. As you can read in the plain mode draft, implicit/explicit thing is drawn from the perspective of the MCP located at the network provider side.

So, the dest address of the packets from client should be proxy's address. (Otherwise, there's no way for proxies to fetch the packets)
[Med] It shouldn’t because we don’t want to require any specific function at the client side for the dual proxy case. Network providers do not have any control on the hosts. The description text in the plain mode is clear about the src/dst addresses for this case:

   The Client sends a SYN segment addressed to the Server and it is
   intercepted by the upstream MCP which in turns initiates an MPTCP
   connection towards its downstream MCP that includes the MP_CONVERT
   Information Element described in Figure 4.  The destination address
   of the SYN segment is the IP address of the downstream MCP.  The
   MP_CONVERT Information Element included in the SYN contains the IP
   address and optionally the destination port of the Server; this
   information is extracted from the SYN message received over the
   upstream TCP connection.

I have thought it may be simpler if we think in this way rather than thinking about CPEs.
[Med] It is much simpler at this stage to focus on the target use case for the dual proxy deployment: MCP in the CPE + MCP at the network side.

I had some hard time to comprehend the proxy drafts and I think one reason for that is it somehow mixes up on-path and off-path cases. I start thinking separating docs for on-path and off-path solutions might be helpful.
[Med] There are a lot of commonalities between these two modes. The main difference is how to make involve the MCP into a connection.

This is just an idea. If we think we can proceed proxy ideas in the current form, it's fine. But, I just would like to explore several possibilities.