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

Alan Ford <> Thu, 04 August 2016 12:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 732C212D196 for <>; Thu, 4 Aug 2016 05:33:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NhAOnZc3BMIl for <>; Thu, 4 Aug 2016 05:33:30 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5487B12D15E for <>; Thu, 4 Aug 2016 05:33:27 -0700 (PDT)
Received: by with SMTP id o80so43836777wme.0 for <>; Thu, 04 Aug 2016 05:33:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=8jBBdnSOujvK0Iga1hMwgOMAPWKoMMSA3NXzHAP37/U=; b=B3p034fP7w19sPZu7gIgLoXlNrv3zaSY5pn5NR0TrjIZpcDy+MojsJCKBfqagZ9f0k Uz4C0rmcSQB+FrF//K5AyaUyiPdY+iwkNQzWbLwYAQf8Q8tCHZDuF8LvPyFkjvT+4X7W p/W6mOVFmd/IgdzKtoCyfZPflDWxAxKvQdmL2297FaR58JsO7+PgNtKV9ebWU2SCDWt3 EGXH71mgSv5A0sciNmbTiJRrlauntoZda8x4Giy6MqJm+w3LaNS5oh2ZZP7SW/oQrR7I lYopgBdCvJEgFM8S6W7pvMvTEHFu0DtOqDNbaUmc1TDc9B7XhpPZi6WZ1P9CxgJ0j0Gl L3Xw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=8jBBdnSOujvK0Iga1hMwgOMAPWKoMMSA3NXzHAP37/U=; b=gI3yLzihkUEkJd/2kbItDj/loz6NrleP3qKBo1SruC4tr54aIbuxQvhzFbkaZB5CIW YJ0wG2TBEy9/cg1HY4JQnNjzWcLfojPx2zbeyFSSLuXEpyDrPddCUfDcjyAtomuqw0x7 TkRoM1L0yT6JP9UMag//BwRHcLURsKlZ0pYiKRzv3c1i13qRZM3tJZKRTrGVpk25gIe0 nHuhTe9ypsBAyVf8E376SKhbw+QupMt7YZJjJR4t69pRqcr/8SsD+JVLFB4KNiS6jc+j IpxjIyafRdY1106Os31h8u43kiC+BZ152erOhbc6B7qfkn3mdRBXIixG6YTszdn4mVKr 5aXQ==
X-Gm-Message-State: AEkoouvak3UuRGS51ly/BslmqPio5UAUINfoLzylvUPN9QHqjOpv32jb0964cH6+TEsAIw==
X-Received: by with SMTP id f3mr28064575wma.31.1470314005776; Thu, 04 Aug 2016 05:33:25 -0700 (PDT)
Received: from alans-mbp.lan ( []) by with ESMTPSA id c16sm3486184wme.4.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 04 Aug 2016 05:33:24 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_59D0F21E-3BD6-42D1-B878-F1F777275757"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933008E00D7D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Date: Thu, 4 Aug 2016 13:33:23 +0100
Message-Id: <>
References: <> <> <> <> <> <> <> <> <787AE7BB302AE849A7480A190F8B933008DF9BB5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933008E00D7D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
X-Mailer: Apple Mail (2.3124)
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 12:33:33 -0000

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!

It is telling the proxy application, which sits above MPTCP, 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.

The proxy application defers to the MPTCP stack (or interacts with it, for finer control) in order to set up new subflows. This is all standard MPTCP behaviour and does not require any additional signalling.

> 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.  

I agree that something would be needed at a higher-layer for a true transparent proxy implementation, since it needs to know which traffic to intercept and which to let through. However, this does not necessarily need to be at the MPTCP layer. IP Router Alert Option is one alternative possibility here (RFCs 2113 / 2711) - given this is proposed for use in a controlled network, I would hope that deployment issues for RAO are not of such a concern here.

For plain mode where an explicit proxy address is given, there is no need for any network alert, since the packets will either be addressed to the proxy, or they won’t.

> 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.

Your proposal uses MPTCP as a multipath transport, however the protocol you have specified for signalling target address is not an MPTCP extension, it is a separate protocol.

However, we are arguing over a non-existent proposal right now. At IETF96 it was said a combined draft would be issued which brought everything together. I await this with interest so we can see how this combined proposal fits with MPTCP.