Re: [multipathtcp] potential MPTCP proxy charter item

Alan Ford <> Mon, 07 November 2016 16:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 620CF1299D7 for <>; Mon, 7 Nov 2016 08:36:48 -0800 (PST)
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 GkuGmRjTh5rR for <>; Mon, 7 Nov 2016 08:36:46 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 73B2A1299D1 for <>; Mon, 7 Nov 2016 08:36:46 -0800 (PST)
Received: by with SMTP id t196so118679430lff.3 for <>; Mon, 07 Nov 2016 08:36:46 -0800 (PST)
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=EtCOByxJtBnnENRgwRP6LWORQNEllfcNvxZeg99ezwE=; b=YmNV8Es9Ow++8jq0Hri2NM9ggpjXdFkvjAtZNWBdXeF5QFmvZxi9taLEGWu8nKW5jp FCnCju7/dJXB93EHscFk1nQLUSlAOcpdqyXhoi5X0uiWPXaMfjcoHdz2r7zkoSoToWs2 62QDFn4zl2X31Uy45aukc5WJUMRzRyeGdrmiQpWdd6gHyDZuNvvBD1s2elNcIGemhKki H3FDbcVQXgr2uPc8V6VTLehnXYAavug+tpjEo0dy/66TUhTco2LqH+RVD5vNoBYvDTxq XeKGjEumWlGe5KQFZCT9awlGoPUwIrFYdihqX/hW/x5voWEDtM9olNrUw9JFhyCxK4i4 gTtg==
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=EtCOByxJtBnnENRgwRP6LWORQNEllfcNvxZeg99ezwE=; b=OwJBP65BDWxWyD3LIrCF9WkicgKfTzDnr46OiGvyIboClkecxvYWV0iqD8/r9Bt2nn +xu+Bg5X75RWXjYeWlsF0GDe6t1idw6VL/oH9CWgyeC5IxRIg+3CCvHc1rmi12e92p+3 WAP6sC1tSR/RqEkltauHUxea6LJ96mbElHSJgRcZl7yDsVShK6pd+OJ3yJ4MnSeS5mew ytnVHGy0XAUmxm6HE9mNKUTjWSDC8tKD6L2sBO4wnosrYa6JtgN17vl2So9eedVztEu/ z417CBLWoMDKKS/ps2t74xjN2FCvuadSnVweSxNTXEEY04psrUQtTUkXTPJ3R0iVrbk9 tBEg==
X-Gm-Message-State: ABUngveaOkVudmbWsVM+KN+K30YYXkerd57qpXLFZkom04YRQvahcwq0JXorveuMeT1qng==
X-Received: by with SMTP id u85mr4141461lff.69.1478536604642; Mon, 07 Nov 2016 08:36:44 -0800 (PST)
Received: from ([]) by with ESMTPSA id a20sm4524001ljb.22.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 07 Nov 2016 08:36:43 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_33553277-F6F7-4BF7-8A2D-4548A51AD4FE"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <>
In-Reply-To: <>
Date: Mon, 07 Nov 2016 16:36:42 +0000
Message-Id: <>
References: <> <> <> <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> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3124)
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: Mon, 07 Nov 2016 16:36:48 -0000

Hi Olivier,

> On 7 Nov 2016, at 07:50, Olivier Bonaventure <> wrote:
>> Why is it an /option/, however? When you are explicitly targeting a
>> proxy node, surely the proxy is just as capable of pulling the data out
>> of the payload here?
> Because the addressing information that is used for the proxy is part of the control plane and not part of the bytestream. I think that it is very important from an architectural viewpoint to maintain a clean separation between the byte stream that is exchanged between the applications and all control information that should be placed inside options.
> We explore the possibility of adding information in the bytestream for MPTCP and eventually decided to place all control information in options. If you look at HTTP, proxy-related information is part of the HTTP headers and not part of the payload. This is the same type of problem.

And this appears to be where we fundamentally disagree. I don’t see this as part of the control plane, I see proxying (at least in explicit mode) as an application of MPTCP, and should be at the application layer. It seems too specific an application to be embedded in the protocol. This does not seem equivalent to NAT, since it is requiring additional signalling.

Similarly I don’t see it compares like-for-like with HTTP headers and payload; HTTP is an application-layer protocol.

Having said that, data can now be tunnelled in HTTP e.g. by using WebSockets. I see this as an application-layer negotiation: negotiate the escalation to WebSockets, then you have a bidirectional socket in operation. This is closer to the tunnelling you propose; however, I see this very much as a negotiation at the first few bytes of the payload, followed by the data.