Re: [multipathtcp] towards a potential work item on two-ended proxy

<> Fri, 05 August 2016 05:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D66312D5D1 for <>; Thu, 4 Aug 2016 22:44:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.905
X-Spam-Status: No, score=-2.905 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.287, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0h9rwfj6ki_r for <>; Thu, 4 Aug 2016 22:44:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DD8D112D110 for <>; Thu, 4 Aug 2016 22:44:15 -0700 (PDT)
Received: from (unknown [xx.xx.xx.64]) by (ESMTP service) with ESMTP id 20CE840FC4; Fri, 5 Aug 2016 07:44:14 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.57]) by (ESMTP service) with ESMTP id E26D71A0071; Fri, 5 Aug 2016 07:44:13 +0200 (CEST)
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.0301.000; Fri, 5 Aug 2016 07:44:13 +0200
From: <>
To: Alan Ford <>
Thread-Topic: [multipathtcp] towards a potential work item on two-ended proxy
Thread-Index: AQHR7kxmEBiWsnqUxUy1x0/Akb3h2aA51Nxw
Date: Fri, 5 Aug 2016 05:44:13 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933008E021AE@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <> <> <> <> <> <> <> <> <787AE7BB302AE849A7480A190F8B933008DF9BB5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933008E00D7D@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_787AE7BB302AE849A7480A190F8B933008E021AEOPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy
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, 05 Aug 2016 05:44:19 -0000

Hi Alan,

Please see inline.


De : Alan Ford []
Envoyé : jeudi 4 août 2016 14:33
Cc : Henderickx, Wim (Nokia - BE);
Objet : Re: [multipathtcp] towards a potential work item on two-ended proxy

Hi Med,


De : Alan Ford []
Envoyé : jeudi 4 août 2016 10:06
Cc : Henderickx, Wim (Nokia - BE);<>
Objet : Re: [multipathtcp] towards a potential work item on two-ended proxy

 I don’t get this argument…
[Med] My point is about “transport-agnostic” part of your comment. One would argue that communication an IP address in a TCP option (which MPTCP is doing) is also “transport-agnostic” but no one is objecting to define such (MP)TCP option.

No, it is not transport-agnostic, it is integral to how MPTCP operates.

You keep referring to “plain mode option” but this is not - in the current draft - a MPTCP option, this is simply something in the payload.
[Med] The PM option is in the payload because of the limited option space. In early versions of the draft, the option can be inserted in the dedicated TCP option space if there is enough space, payload, etc. but we abandoned that design to simply the implementations.

But this information doesn’t need to be read or understood by a MPTCP stack!
[Med] It needs to be read by the “MPTCP proxy” stack.

It is telling the proxy application, which sits above MPTCP,
[Med] This is implementation-specific. We are defining a new functional entity called “MPTCP Proxy”. The internal structure of such element is really implementation-specific.

where to forward the following payload data to.

This signal is a protocol which is not specific to MPTCP, and is in no way integrated with the rest of the MPTCP protocol.
[Med] I still don’t understand this argument as we are defining something “NEW”: Network-assisted MPTCP in addition to the existing end-to-end MPTCP.

The proxy application defers to the MPTCP stack (or interacts with it, for finer control) in order to set up new subflows.
[Med] I don’t parse what is meant by “defers” and “stack” here although I suspect those are implementation details that may or may not be followed by a given implementation.

[ Snip]