Re: [multipathtcp] potential MPTCP proxy charter item

<mohamed.boucadair@orange.com> Tue, 08 November 2016 14:24 UTC

Return-Path: <mohamed.boucadair@orange.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 46501129CAE for <multipathtcp@ietfa.amsl.com>; Tue, 8 Nov 2016 06:24:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.097
X-Spam-Level:
X-Spam-Status: No, score=-3.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 w2y6U9-qGgjV for <multipathtcp@ietfa.amsl.com>; Tue, 8 Nov 2016 06:24:12 -0800 (PST)
Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D369129CAD for <multipathtcp@ietf.org>; Tue, 8 Nov 2016 06:24:12 -0800 (PST)
Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 649214061C; Tue, 8 Nov 2016 15:24:10 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.57]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 3B2111A013F; Tue, 8 Nov 2016 15:24:10 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0319.002; Tue, 8 Nov 2016 15:24:09 +0100
From: mohamed.boucadair@orange.com
To: Alan Ford <alan.ford@gmail.com>
Thread-Topic: [multipathtcp] potential MPTCP proxy charter item
Thread-Index: AQHSObvCnemdljzUmEGiGID3gGUCC6DPCzaw
Date: Tue, 08 Nov 2016 14:24:08 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009DAE277@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
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> <20161107162402.GJ3546@Chimay.local> <787AE7BB302AE849A7480A190F8B933009DADEF6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <EB946B44-882B-41A4-9CF0-7763EFBD05DA@gmail.com>
In-Reply-To: <EB946B44-882B-41A4-9CF0-7763EFBD05DA@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/m5hPRG_X_xhhr8LtzkkAqfOWN-s>
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: Tue, 08 Nov 2016 14:24:14 -0000

Re-,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Alan Ford [mailto:alan.ford@gmail.com]
> Envoyé : mardi 8 novembre 2016 13:30
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Christoph Paasch; Olivier Bonaventure; multipathtcp@ietf.org
> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
> 
> Hi Med,
> 
> Inline...
> 
> 
> >> -----Message d'origine-----
> >> De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de
> >> Christoph Paasch
> >> Envoyé : lundi 7 novembre 2016 17:24
> >> À : Olivier Bonaventure
> >> Cc : multipathtcp@ietf.org
> >> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
> >>
> >> Hello,
> >>
> >> On 07/11/16 - 08:56:07, Olivier Bonaventure wrote:
> >>>
> >>> 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.
> >
> > [Med] Existing network-assisted MPCP documents already cover this case.
> Native MPTCP connections will be established by that smartphone without
> even being intercepted by an MCP. The MCP has not to inspect the SYN/ACK.
> The problem is more on the laptop side.
> 
> But inspecting the SYN/ACK would allow the MCP to provide Multipath
> capabilities when the smartphone is MPTCP capable but the server is not.
> However, that’s a side-effect...
> 
> >
> > Let's consider a TCP connection from that laptop. This TCP connections
> is relayed to MPTCP via the fixed line, and the intercepted by the MCP. If
> the MCP withdraws itself because it receives an MP_CAPBLE in the SYN/ACK
> from the ultimate server, the secondary subflow (via cellular2) may not be
> established because only private IPv4 addresses may be assigned in that
> leg (e.g., dedicated APN is used). In this case, the withdrawal of the MCP
> will lead to more failures.
> 
> Sorry I don’t follow that scenario. If cellular2 tried to join, it would
> talk direct to the far end, and not to the MCP,  if the MCP was not in the
> path… Right? So what’s the problem?

[Med] The problem arise when only private IPv4 are assigned on cellular 2.

> 
> If the MCP remained in the path, then what would be different for this
> scenario to make it work?

[Med] It will use a globally routable IP address as source address (either the same IP address as the one used by the host to establish to first subflow) or an address that assigned locally by the MCP.

> 
> >
> > This is exactly why I'm advocating for a configurable parameter.
> >
> >> 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.
> 
> These two scenarios make sense to me (at the moment), I am confused as to
> why this would not work?
> 
> Regards,
> Alan
>