Re: [multipathtcp] potential MPTCP proxy charter item

Christoph Paasch <cpaasch@apple.com> Mon, 07 November 2016 16:48 UTC

Return-Path: <cpaasch@apple.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E900F12986F for <multipathtcp@ietfa.amsl.com>; Mon, 7 Nov 2016 08:48:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.799
X-Spam-Level:
X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8c6PnDE0Q78 for <multipathtcp@ietfa.amsl.com>; Mon, 7 Nov 2016 08:48:32 -0800 (PST)
Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBE2E129648 for <multipathtcp@ietf.org>; Mon, 7 Nov 2016 08:48:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1478537312; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=hFon42b92Lo0tgH1lqPUzLUwXCcRnV6/G3+dIW8J/+Q=; b=youpERN3w6mA+8NaGe4uSYWXQbNNo6IE4t1NiLyTpsoZJqoLUYx07l7m5LDdLt8j ds4bC5L8KEx8SDQRVJMIP7cvUi5zW3mbQKBHLG8TfIvEejgpb7VYK4ue6v7IBv6Q iMT2czHerV1OvWkqGI+YHKTKAbEPt3flBNAjWZjN1IsNT+GqPXqFFlGUvOEtCePu 1gccTAby7ID4CYSIcbKoyWiPk48esy25GinCsczE3Y3xnH2F1TjcqSA8+gkQs2Tu bo7zNkHArAoYp+aqwY6oUYnxJL1hxze3uWoW/JO6HxrFSe2mrdpOOhp+ejDb6QIE FxZUW5RucBaghLwIP2pFwQ==;
Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 0E.1C.09085.060B0285; Mon, 7 Nov 2016 08:48:32 -0800 (PST)
X-AuditID: 11973e11-0d5e19a00000237d-26-5820b060a5ac
Received: from chive.apple.com (chive.apple.com [17.128.115.15]) by relay6.apple.com (Apple SCV relay) with SMTP id AE.BF.23613.060B0285; Mon, 7 Nov 2016 08:48:32 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 8BIT
Content-disposition: inline
Content-type: text/plain; charset=utf-8
Received: from localhost ([17.149.231.155]) by chive.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OGA00EKW6OWVD80@chive.apple.com>; Mon, 07 Nov 2016 08:48:32 -0800 (PST)
Sender: cpaasch@apple.com
Date: Mon, 07 Nov 2016 08:48:31 -0800
From: Christoph Paasch <cpaasch@apple.com>
To: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Message-id: <20161107164831.GK3546@Chimay.local>
References: <56CE164A-9A62-4B57-9CFF-33DBD45BA8B2@gmail.com> <787AE7BB302AE849A7480A190F8B933009D9CA84@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <85D52AE4-FE5F-4977-8927-6BDB72614D07@gmail.com> <787AE7BB302AE849A7480A190F8B933009DAAA88@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <D2630820-7586-4361-A626-3278F22C319C@gmail.com> <B7D8197F-D833-41BB-A4A4-D6F31A3B8993@tik.ee.ethz.ch> <787AE7BB302AE849A7480A190F8B933009DAC5DE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <EBFA61A5-4A9E-4B41-BDC1-4F9056241D70@gmail.com> <20161104181615.GP40488@Chimay.local> <010bba5d-dea0-8268-897e-ff7399abd41b@uclouvain.be>
In-reply-to: <010bba5d-dea0-8268-897e-ff7399abd41b@uclouvain.be>
User-Agent: Mutt/1.7.1 (2016-10-04)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUi2FAYpZuwQSHCoP2FusXht0/ZLT6vvs5m caPhB4sDs8eSJT+ZPFqenWTzeHXsO0sAcxSXTUpqTmZZapG+XQJXxrmHS1kK7stUvFlxnamB sV28i5GTQ0LARGLZypUsXYxcHEICexkldr54wgSTWN+xkw0isZFRYsWXWewgCV4BQYkfk+8B dXBwMAvISxy5lA0SZhaQlnj0dwY7RFhdYsqUXIjW14wSe+Y9ZwGpERaQlOi+c4cZxGYRUJU4 tf4O2C42AS2Jt7fbWUFsEQEriVOnp7NDzAyWuH1nBTNEr53EusffwebzChhI3LqqCzH/M4vE 8e27wGo4BRwkXrZ3gM0RFVCW+Hv4HthjEgJr2CR+7vzLMoFRZBaSF2YhvDALyQuzEF5YwMiy ilEoNzEzRzczz0gvsaAgJ1UvOT93EyMoNqbbCe5gPL7K6hCjAAejEg+vgI18hBBrYllxZe4h RmkOFiVx3k38shFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGM8nKK37+SA46FrOsfbPKQ6z a5o7zs+37RWzV6g7v1Bxq6BrSkZeya4FxqZ73jtEdBf4bzM/w2WQ/4jdYfbVC//L2Vyzur/4 tK/7v4Hll5inTm3b3HUP3zr26Ihs2HNxzeO1QdJrbv48o7GjQnT6gtd39Bb2OMofOnc3OG+W 6sTlU/Ki9ZWv1yqxFGckGmoxFxUnAgDz+yDkbgIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUi2FDMr5uwQSHCYNE6RYvDb5+yW3xefZ3N 4kbDDxYHZo8lS34yebQ8O8nm8erYd5YA5igum5TUnMyy1CJ9uwSujHMPl7IU3JepeLPiOlMD Y7t4FyMnh4SAicT6jp1sELaYxIV764FsLg4hgY2MEiu+zGIHSfAKCEr8mHyPpYuRg4NZQF7i yKVskDCzgLTEo78z2CHC6hJTpuRCtL5mlNgz7zkLSI2wgKRE9507zCA2i4CqxKn1d5hAbDYB LYm3t9tZQWwRASuJU6ens0PMDJa4fWcFM0SvncS6x9/B5vMKGEjcuqoLMf8zi8Tx7bvAajgF HCRetneAzREVUJb4e/geywRGoVlIrp6FcPUsJFfPQrh6ASPLKkaBotScxEozvcSCgpxUveT8 3E2M4BAvjNrB2LDc6hCjAAejEg/vi36FCCHWxLLiytxDjBIczEoivCnrgUK8KYmVValF+fFF pTmpxYcYpTlYlMR5r3XIRwgJpCeWpGanphakFsFkmTg4pRoYpZkXzr6lq7Rpz3+LmhfhcjES qfe+cU2dyLqo4Kibg8++JemxjU2O8323by484aH+fx3HpEbtu0pP74RP6jZYoTTjoZBna8wV ga8rtXfLT1/3iV1T5u9WjtkFP13vPBHTkcjbddVq+8NlXxXl+rcrdeu+fh4reWn6wpxz+6Md BJ8UF8q0SZ0tUWIpzkg01GIuKk4EAAaKlTVtAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/k2SabFnQM1lT4PIY4tmMv_BECjQ>
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Subject: Re: [multipathtcp] potential MPTCP proxy charter item
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Nov 2016 16:48:34 -0000

Hello,

On 07/11/16 - 09:00:17, Olivier Bonaventure wrote:
> > > > [Med] Defining another channel to carry the signal "I want to be MPTCP-proxied" outside the MPTCP normal channel will import the same set of hindrances we had with MPTCP design for middlebloxes traversal. The use of MPTCP to convey the "I want to be MPTCP-proxied" leverages on base MPTCP to detect "unfriendly MPTCP" in-path nodes. That's a pragmatic engineering design.
> > > 
> > > The MP_CONVERT signal has multiple purposes. When signalled with a target IP address in explicit mode, it is a pure application-layer signal, and is separate from the MPTCP connection entering the MCP.
> > > 
> > > In implicit mode this is indeed at a slightly different layer, and yes, you are asking the network to do something. But it’s still not a necessary part of the MPTCP protocol to make this happen. This is similar to a transparent HTTP proxy, or to a NAT - neither requires any changes to HTTP or TCP/IP to work.
> > > 
> > > You could detect MPTCP SYNs and see if your signal is present. If you don’t want to be inspecting every MPTCP SYN in implicit mode, use an existing standard - I suggest RAO. Given this is a controlled environment, you shouldn’t have any deployment concerns here.
> > > 
> > > If RAO is not appropriate for some reason, I might be persuaded that a flag in the MP_CAPABLE that says “proxies should inspect this” could be added to the base protocol. However, the rest of the protocol - i.e. the MP_CONVERT signal - is application-layer and outside MPTCP.
> > > 
> > > Ultimately MPTCP Proxying is an application of MPTCP and should be defined as such.
> > 
> > I'm also late on this thread. But just want to reiterate what I already
> > mentioned before in July.
> > 
> > I also think that proxying between different transport-layer protocols is not
> > an MPTCP-specific operation and as such should not be tied to MPTCP.
> > Making it independent of MPTCP would be much better as it allows to proxy
> > across any kind of transport protocol. So, let's just put it (as already
> > suggested) in the payload, without linking it to MPTCP.
> 
> 
> From an architectural viewpoint, providing addressing information for a
> proxy is clearly outside the bytestream exchanged by the application. It is
> cleaner to place this control plane information inside options instead of
> messing up the bytestream and changing the first few bytes of each
> connection. I think that we should have a clean separation between the
> control plane and the data plane in MPTCP. We already use options to carry
> addressing information related to the endhosts (ADD_ADDR, REMOVE_ADDR), the
> addresses required by the proxy are the same type of information and they
> should also be exchanged as TCP options. Encoding them in the payload would
> likely create more problems in the long term.

Now I'm confused. I thought that the MCP-option already is in the SYN's payload.


Wrt to the layer-separation. I think that having a 0-RTT proxying protocol
in the payload, where the first few bytes of a bytestream indicate the
server's IP-address would be very beneficial. These few bytes would be
placed in the SYN, just like the MCP-option, but without the link to MPTCP.
This would address Med's concerns wrt to additional delay, not interfere
with TFO,...

This would allow for some interesting use-cases:

* I could do a SCTP-proxy where each stream goes to a different server
* I could do a Quic-proxy
* I could do a TCP-RACK proxy that allows me to use TCP-RACK as
  server-support is not there yet (besides Google)
* ...


Cheers,
Christoph