Re: [multipathtcp] potential MPTCP proxy charter item

Christoph Paasch <cpaasch@apple.com> Mon, 07 November 2016 16:24 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 18A8B1297CB for <multipathtcp@ietfa.amsl.com>; Mon, 7 Nov 2016 08:24:08 -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 09WHeX63h4Ri for <multipathtcp@ietfa.amsl.com>; Mon, 7 Nov 2016 08:24:02 -0800 (PST)
Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (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 1A74B129605 for <multipathtcp@ietf.org>; Mon, 7 Nov 2016 08:24:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1478535841; 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=KTpmUDx9yzkYxyj110A9z83Lyh5xmzPeC5t4LKPcKss=; b=t1S1NbuKoOd1yhURvLgOWDBmbxOlitbuiOZdQVCfCgnP3jRHtgRkcIVNFr8Nv4iB Wzz3GDvwfDENeKWDKuF3AG9fIs+qOrqu8BV9yTjhs6NmIdKbjMgLnsROBcESoV+p r1RBEmmt8QOrifxoThPHd4Vl7cPfihk8XHN1b0wp8kWBjF+/pWE/kkV5aEeZCWP8 hlgllrWXZVnU8wpziQ56/pTLnBrH/LdjxAWH2cVIkX4kIiHBk/K7YxwkgZ6KMSQQ 4kEJOiKZn/QveMX5JZz5FbiDv3WFF21R8dEe5kf2viqoPVPuSYSEfccmTFGHrt5b xASvRg+ax/EhG1tICc4x8A==;
Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 8D.80.12011.1AAA0285; Mon, 7 Nov 2016 08:24:01 -0800 (PST)
X-AuditID: 11973e13-68e279a000002eeb-33-5820aaa19c63
Received: from chive.apple.com (chive.apple.com [17.128.115.15]) by relay6.apple.com (Apple SCV relay) with SMTP id 32.B1.23613.1AAA0285; Mon, 7 Nov 2016 08:24:01 -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 <0OGA00EF95K1VD70@chive.apple.com>; Mon, 07 Nov 2016 08:24:01 -0800 (PST)
Sender: cpaasch@apple.com
Date: Mon, 07 Nov 2016 08:24:02 -0800
From: Christoph Paasch <cpaasch@apple.com>
To: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Message-id: <20161107162402.GJ3546@Chimay.local>
References: <73a1c0dd64a843a5baa645d960c82886@rew09926dag03b.domain1.systemhost.net> <b8bfd5c6-21eb-4c4f-879a-851c3a71792a@OPEXCLILM31.corporate.adroot.infra.ftgroup> <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> <87270f12-59ee-3caf-eeef-685195b35dcd@uclouvain.be> <A5256E6E-E2BA-4763-AEF9-3CC50EB432A2@gmail.com> <62c065c9-3ce5-5c46-91f4-41c2f4707f69@uclouvain.be>
In-reply-to: <62c065c9-3ce5-5c46-91f4-41c2f4707f69@uclouvain.be>
User-Agent: Mutt/1.7.1 (2016-10-04)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUi2FAYpbtwlUKEQf8SC4uV51YwW3xefZ3N 4kbDDxYHZo+ds+6yeyxZ8pPJ49Wx7ywBzFFcNimpOZllqUX6dglcGR39O5kLjohV3Pp7l7mB cZ1gFyMnh4SAicSuQwdYuxi5OIQE9jJKPHy+lRkmsWXOJ6jERkaJLXtOM4EkeAUEJX5MvsfS xcjBwSwgL3HkUjZImFlAWuLR3xnsEGF1iSlTciFaXzNKrDo4mxWkRlhAUqL7zh2w+SwCqhIf eh6DxdkEtCTe3m4Hs0UErCROnZ7ODjEzTOJH73moXjuJdY+/g83nFTCQmL1RHGL+JFaJF9t7 wOo5BRwkVk/sYASxRQWUJf4eBjmTC+iXFWwSzzcdZprAKDILyQuzEF6YheSFWQgvLGBkWcUo lJuYmaObmWeql1hQkJOql5yfu4kRFBvT7YR3MJ5eZXWIUYCDUYmH90W/QoQQa2JZcWXuIUZp DhYlcd7t/LIRQgLpiSWp2ampBalF8UWlOanFhxiZODilGhj1lT7EHk/u+jhrcnRpe5XklqUC D3ad27j6sKROoK6NlfCcg4lCwhkWwdaLCjoftDvsWjj53bewDA9LBXP9zESR7ulvPhaG7HuS 5Lh1w70/M7lil8f3WdhWBHpsts7/wlM0a0nyW4P/D96fauPYumTWh8U7QqKuriuPXn2p/yNr sEOP5vlHZReUWIozEg21mIuKEwHEzKQUbgIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUi2FDMr7twlUKEwbLJhhYrz61gtvi8+jqb xY2GHywOzB47Z91l91iy5CeTx6tj31kCmKO4bFJSczLLUov07RK4Mjr6dzIXHBGruPX3LnMD 4zrBLkZODgkBE4ktcz6xQthiEhfurWfrYuTiEBLYyCixZc9pJpAEr4CgxI/J91i6GDk4mAXk JY5cygYJMwtISzz6O4MdIqwuMWVKLkTra0aJVQdng80UFpCU6L5zhxnEZhFQlfjQ8xgsziag JfH2djuYLSJgJXHq9HR2iJlhEj96z0P12kmse/wdbD6vgIHE7I3iEPMnsUq82N4DVs8p4CCx emIHI4gtKqAs8ffwPZYJjEKzkFw9C+HqWUiunoVw9QJGllWMAkWpOYmVZnqJBQU5qXrJ+bmb GMEhXhi1g7FhudUhRgEORiUe3hf9ChFCrIllxZW5hxglOJiVRHh/rAQK8aYkVlalFuXHF5Xm pBYfYpTmYFES573WIR8hJJCeWJKanZpakFoEk2Xi4JRqYJyl2a8dsJ5hfSJLbcx82QvsvUv4 Q54pX6xLYN658GTtfuYSP+WXjZVuB0tuLaj1KAq8zrzzSdO6j//PJ529djNSzDeizOjJ03Xe 96/+2afBsVuK4SsPr765wulqn4xa+fpzj2LuKqzacM/jipvMRnWvnLCqkINLT1iWJuzwfGDe 8y7SYesPCSWW4oxEQy3mouJEAH6LFY1tAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/lU8_JnMOAi6lEbzYbnQ_5KDVb9Q>
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:24:08 -0000

Hello,

On 07/11/16 - 08:56:07, Olivier Bonaventure wrote:
> > > On 6 Nov 2016, at 21:06, Olivier Bonaventure
> > > <Olivier.Bonaventure@uclouvain.be
> > > <mailto:Olivier.Bonaventure@uclouvain.be>> wrote:
> > > 
> > > The implicit mode was suggested by network operators. The MCP resides
> > > on the path between the CPE and the destination server. The main
> > > benefit of the implicit mode is that the MCP does not need to perform
> > > any address translation. Given all the complications with NAT, this is
> > > a huge benefit, in particular in IPv6 deployments. In IPv4
> > > deployments, the CPE can use a single address and there is no need for
> > > a pool of IPv4 addresses on the MCP.
> > > 
> > > In implicit mode, the MCP needs to distinguish between an MP_CAPABLE
> > > generated by the endhost and an MP_CAPABLE added by the CPE.
> > 
> > Broad question - why?
> > 
> > If the answer is simply “to know when to terminate the MPTCP connection”
> > (i.e. if the end host does it you want it to run all the way to
> > destination, but if the CPE has done it you want to handle at the
> > proxy), then thinking out loud here, could the desired behaviour not be
> > achieved by deciding to proxy only based on the SYN/ACK (i.e. based on
> > the far end’s capabilities) and otherwise be transparently adding MPTCP
> > to /everything/? That way you get even greater MPTCP coverage whilst not
> > interfering with destinations which have already deployed it.
> 
> 
> The problem is more complex than this because the connecitivity on the CPE
> is not the same as connectivity on the endhost. Consider the following
> scenario :
> 
> laptop <-----------+
>                    |
> smartphone <----> cpe <-------> mcp <------> server
>     +              +
>  cellular1     cellular2
> 
> The MCP resides on the DSL path between the CPE and the server.
> 
> The laptop is connected over WiFi and the CPE converts the TCP connection
> onto an MPTCP connection to bond DSL and cellular2.
> 
> The smartphone is connected over wifi to the cpe which is connected over DSL
> to the server via the MCP. When the smartphone uses MPTCP, it wants to use
> WiFi and cellular1. It could start over WiFi and then moves and want to
> switch to cellular1. The MCP has no idea of cellular1 and cannot terminate
> an MPTCP connection created by the smartphone.

I'm not sure, why Alan's suggestion to only proxy based on the SYN/ACK
doesn't work here.

There are two scenarios here:

1. server supports MPTCP: Then, everything is fine. CPE and MCP will stay
   out of the business and native MPTCP will be done from smartphone to
   server.
2. server does not support MPTCP: In that case the MCP will announce its
   public IP to the smartphone and this one can then create an MPTCP-subflow
   via cellular1.


Christoph