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

<> Thu, 04 August 2016 11:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E44BB12DDBE for <>; Thu, 4 Aug 2016 04:54:59 -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 1casFcDLGFXV for <>; Thu, 4 Aug 2016 04:54:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4818012DCF1 for <>; Thu, 4 Aug 2016 04:49:26 -0700 (PDT)
Received: from (unknown [xx.xx.xx.3]) by (ESMTP service) with ESMTP id C19953B4613; Thu, 4 Aug 2016 13:49:24 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown []) by (ESMTP service) with ESMTP id 9A1094C066; Thu, 4 Aug 2016 13:49:24 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0301.000; Thu, 4 Aug 2016 13:49:24 +0200
From: <>
To: Alan Ford <>
Thread-Topic: [multipathtcp] towards a potential work item on two-ended proxy
Thread-Index: AQHR7icRFBIp5cXRZ0uP6Cf/red946A4qgbA
Date: Thu, 4 Aug 2016 11:49:24 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933008E00D7D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <> <> <> <> <> <> <> <> <787AE7BB302AE849A7480A190F8B933008DF9BB5@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_787AE7BB302AE849A7480A190F8B933008E00D7DOPEXCLILMA3corp_"
MIME-Version: 1.0
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2016.6.17.114517
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: Thu, 04 Aug 2016 11:55:00 -0000


Please see inline.


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

Hi Med,

On 4 Aug 2016, at 06:53, <<>> <<>> wrote:

As I’ve said before, the plain mode option is not MPTCP-specific and is
simple a signal that says “everything that follows is actually targeted
for IP address a.b.c.d” - this is entirely transport-agnostic.

[Med] The plain mode allows for example to distinguish between native and proxied MPTCP connection.
I'm puzzled here since MPTCP allows to inform a remote peer about an IP address while this is not TCP-specific. Isn't that information transport-agnostic as per you argument? (not mine).

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.

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.

Your MPTCP proxy leverages MPTCP in order to apply new IP addresses to an existing MPTCP connection, which is great, but does not require any protocol extensions to do this. The only additional information it needs is the target, in the initial subflow, and this is provided by information in the payload.
[Med] It is in the payload because of the limited space and because of the lack of mature proposals to extend the SYN option space.

This information is carried in the payload, and does not carry any information which is specific to MPTCP.
[Med] It is specific to MPTCP as it allows, in addition to conveying a target/source IP address, to avoid interfering with native MPTCP connections. Also, the option allows to offload the MPTCP concentrator from the path if both endpoints are MPTCP-capable. All these aspects are specific to MPTCP.

To be clear on this - I am not opposed to doing this work, and indeed I would be entirely happy to see the charter clarified to support work on two-ended proxies. This is valuable work.
[Med] Ok. Let’s then agree on the charter update.

But in this WG, this work should be to the limit of “how you could use MPTCP between two proxies”
[Med] That should be part of the work, indeed. But there are other aspects that are important such as avoiding interfering with native MPTCP connections, offload an MPTCP proxy from the path if both endpoints are MPTCP-capable, avoid extra delays to establish network assisted MPTCP connections, etc.

… If you need a wire protocol defined which is not MPTCP-specific (which this does not appear to be),
[Med] I still disagree here. The proposal we have on the table is specific to MPTCP.

that work should be done somewhere like intarea or tsvarea and referenced by this work.