Re: [multipathtcp] potential MPTCP proxy charter item

Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> Mon, 07 November 2016 07:56 UTC

Return-Path: <olivier.bonaventure@uclouvain.be>
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 68C0F129C90 for <multipathtcp@ietfa.amsl.com>; Sun, 6 Nov 2016 23:56:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level:
X-Spam-Status: No, score=-4.321 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be
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 VgZElqzXdpYW for <multipathtcp@ietfa.amsl.com>; Sun, 6 Nov 2016 23:56:14 -0800 (PST)
Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2929129C74 for <multipathtcp@ietf.org>; Sun, 6 Nov 2016 23:56:13 -0800 (PST)
Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id C0FE267D9DD; Mon, 7 Nov 2016 08:56:06 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.9.2 smtp6.sgsi.ucl.ac.be C0FE267D9DD
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1478505366; bh=BHmgDDhBHSV5ueVWL4LFiQEdzV4GOOI+QetckFKack0=; h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To; b=uKZN5EG1CeFyyjtSA+KIYnY7L6fKa+q12msJAHrBQzeIq+0kfWcTZwAFtIZKBDh3X ynnrt585MAQZAhrzz5AVnT/7QhFSCkGLsLDCZ1QYKSVlmBlV07jbuC6EtZo3pf7iUs xt6LC/2LCFNYAv5ESihssZLQr+YvcYWzuvLhMkgs=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99 at smtp-6
References: <CCD1A987-0F3C-4775-8B0E-5232965E7E22@nokia.com> <CAO249ydpdtR53VBniDczSt4zj_kk32c2W_FoZKs2XED0Jzk7Jw@mail.gmail.com> <787AE7BB302AE849A7480A190F8B933009D9577B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <22907_1476946228_58086934_22907_5464_1_a7bca8d2-7656-4ff0-9f01-cf307f017148@OPEXCLILM42.corporate.adroot.infra.ftgroup> <57543A7A-1542-4C60-A5D3-E1658354BE5A@tik.ee.ethz.ch> <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>
To: Alan Ford <alan.ford@gmail.com>
From: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Message-ID: <62c065c9-3ce5-5c46-91f4-41c2f4707f69@uclouvain.be>
Date: Mon, 7 Nov 2016 08:56:07 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <A5256E6E-E2BA-4763-AEF9-3CC50EB432A2@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-Information:
X-SGSI-MailScanner-ID: C0FE267D9DD.A5E7E
X-SGSI-MailScanner: Found to be clean
X-SGSI-From: olivier.bonaventure@uclouvain.be
X-SGSI-Spam-Status: No
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/AW0RJ2p0l63dzbP3MLfaKVCuEQs>
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
Reply-To: Olivier.Bonaventure@uclouvain.be
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 07:56:15 -0000

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



Olivier