Re: [multipathtcp] potential MPTCP proxy charter item

<mohamed.boucadair@orange.com> Thu, 10 November 2016 06:48 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 7F45712947D for <multipathtcp@ietfa.amsl.com>; Wed, 9 Nov 2016 22:48:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.618
X-Spam-Level:
X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 Z7CNlm1gKhiq for <multipathtcp@ietfa.amsl.com>; Wed, 9 Nov 2016 22:48:32 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 827D3129640 for <multipathtcp@ietf.org>; Wed, 9 Nov 2016 22:48:31 -0800 (PST)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id DF7D318C2A8; Thu, 10 Nov 2016 07:48:29 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.41]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id B3AAF23807D; Thu, 10 Nov 2016 07:48:29 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0319.002; Thu, 10 Nov 2016 07:48:29 +0100
From: <mohamed.boucadair@orange.com>
To: Alan Ford <alan.ford@gmail.com>
Thread-Topic: [multipathtcp] potential MPTCP proxy charter item
Thread-Index: AQHSOqkknemdljzUmEGiGID3gGUCC6DRwCCQ
Date: Thu, 10 Nov 2016 06:48:29 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009DAF0C2@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
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> <7f9dd7ab-2e24-0319-b62f-fc4fa68b9568@tik.ee.ethz.ch> <787AE7BB302AE849A7480A190F8B933009DAE3A6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <A95CD4E7-6A3B-4622-A818-03B10AD75D4D@gmail.com> <787AE7BB302AE849A7480A190F8B933009DAE743@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <06A031EE-5F50-4A0F-BBEC-9F2766C543FF@gmail.com> <787AE7BB302AE849A7480A190F8B933009DAE7DC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <53CD2649-4063-4EA8-8076-71990B2D2371@gmail.com> <787AE7BB302AE849A7480A190F8B933009DAE977@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <228C439B-4AA4-48A9-B78A-FE7CD9EEFB81@gmail.com>
In-Reply-To: <228C439B-4AA4-48A9-B78A-FE7CD9EEFB81@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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009DAF0C2OPEXCLILMA3corp_"
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.17.114517
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/4ARCwAuB0JvoktFWJveMbjhjias>
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: Thu, 10 Nov 2016 06:48:34 -0000

Hi Alan,

Please see inline.

Cheers,
Med

De : Alan Ford [mailto:alan.ford@gmail.com]
Envoyé : mercredi 9 novembre 2016 17:49
À : BOUCADAIR Mohamed IMT/OLN
Cc : Mirja Kühlewind; Olivier.Bonaventure@uclouvain.be; multipathtcp@ietf.org
Objet : Re: [multipathtcp] potential MPTCP proxy charter item

OK got it - I think. I’ll summarise here and please correct me if my understanding is wrong.

Essentially, there are cases where the CPE’s secondary uplink does not have public IP access and thus needs to go via the MCP, but if the MCP has removed itself from the path, the secondary uplink won’t know about the MCP. You need a way to signal this information to a MCP over the primary path so it doesn’t remove itself.
[Med] The signal to be removed from the path can be at least in-band (like what was already discussed in the network-assisted MPTCP drafts) or be a local configuration parameter to an MCP.

Is this the only case where this signal is required?
[Med] Frankly speaking, I don’t know. We will need to figure out this once this work is endorsed by the WG.

Why can’t these scenarios be handled with explicit mode, for example with using the DHCP option to pass down the MCP address?
[Med] The same problem applies for the explicit mode. If an MCP decides to withdraw itself from a connection because it receives an MP_CAPABLE option from the server, subsequent subflows may not be established directly with the server for the same reasons we discussed earlier.

Regards,
Alan

On 9 Nov 2016, at 14:12, mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> wrote:

Re-,

Please see inline.

Cheers,
Med

De : Alan Ford [mailto:alan.ford@gmail.com]
Envoyé : mercredi 9 novembre 2016 14:39
À : BOUCADAIR Mohamed IMT/OLN
Cc : Mirja Kühlewind; Olivier.Bonaventure@uclouvain.be<mailto:Olivier.Bonaventure@uclouvain.be>; multipathtcp@ietf.org<mailto:multipathtcp@ietf.org>
Objet : Re: [multipathtcp] potential MPTCP proxy charter item

Hi Med,

Inline...

On 9 Nov 2016, at 09:45, mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> wrote:



-----Message d'origine-----
De : Alan Ford [mailto:alan.ford@gmail.com]
Envoyé : mercredi 9 novembre 2016 09:04
À : BOUCADAIR Mohamed IMT/OLN
Cc : Mirja Kühlewind; Olivier.Bonaventure@uclouvain.be<mailto:Olivier.Bonaventure@uclouvain.be>;
multipathtcp@ietf.org<mailto:multipathtcp@ietf.org>
Objet : Re: [multipathtcp] potential MPTCP proxy charter item

Hi Med,

Thanks for providing some scenarios. Comments inline…



On 9 Nov 2016, at 06:41, mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> wrote:

Hi Alan,

Below some examples to illustrate the problem I'm talking about.

(1) Private IPv4 addresses or RFC6598 Shared Address space

Let's consider this configuration (reusing the same topology in this
thread):



laptop <-----------+
                 | (Public IPv4@)
smartphone <----> cpe <----FIXED------> mcp <------> server
   +             +
cellular1     cellular2
              (Private IPv4)

In this example, the multipath CPEs gets a public IPv4 address from the
fixed network and a private IPv4 address (or an address from RFC6598
range) from the mobile network (cellular2).



Consider the server is MPTCP-capable.

The first subflow can be placed using the fixed line. Fine.
The MCP will remove itself from the connection because the server is
MPTCP-capable. Cool!


The second subflow that will use cellaulr2 cannot be established because
of a basic forwarding problem: packets sourced with private IPv4 addresses
cannot be forwarded over the public Internet.

Presumably cellular2 goes through a NAT in order to talk to anything in
the public Internet. So it can be addressed to the server, and work like
any other MPTCP subflow behind a NAT would work today.

[Med] You are assuming that the same Internet APN will be used for the hybrid access. This is not a valid assumption. Some deployment are considering dedicated APN for this service to avoid additional public IPv4 address are assigned to this service and also to avoid overload the service function at the Gi interface with traffic that will be routed to the backbone of the same provider.

Regrettably I’m not familiar with all these 3GPP terms here, however are you saying that cellular2 would not be able to have external, public, IP connectivity?
[Med] Yes, because this is supposed to be a dedicated APN for hybrid access service. FWIW, you can refer to the concept of APN herehttps://tools.ietf.org/html/rfc6459#section-2.2.

If not, what’s the point of that interface? I was assuming that it would, and therefore would be able to talk direct to the server.
[Med] That’s may be another APN: Internet APN.



What am I missing? Why is this any different to today with a MPTCP end
host with private IP addresses?

[Med] The difference is that there is no NAT in the path before the MCP. The MCP has the role to use the IP address assigned by the fixed line when forwarding the secondary subflow.

I wasn’t talking before the MCP; in this scenario we are talking that the MCP gets out of the path
[Med] I got that.

- so what cellular2 needs to do is reach the server to open the second subflow.
[Med] Cellular2 needs nothing! But MPTCP connections need the flows to be intercepted but the MCP. That is avoid withdrawing the MCP even if the remote server is MPTCP-capable.  Please note that I’m not expressing my own preferences here, but I’m explaining what kind of problems may arise if we make invalid assumptions.

The smartphone does not have knowledge of cellular2, presumably… So the
CPE would have to do something funky with the traffic to split it over
fixed and cellular2

[Med] This is a proxy function (MCP) in the CPE! I didn't focused on that part of the flow because there are other problems there. If the CPE does not embed an MCP, an MPTCP capable host (laptop of smartphone) may not be able to aggregate the resources of multiple access links. Going native will lead to less QoE compared to involving the MCP located in the CPE.

- but it could still establish the subflow towards the


server on cellular2, without any knowledge of the smartphone or the
network.




(2) IPv6-only access network

Lets' consider this configuration:

laptop <-----------+
                 | (Public IPv4@
smartphone <----> cpe <----FIXED------> mcp <------> server
   +              +                                IPv4-only
cellular1     cellular2
              (IPv6-only prefix)

In this example, the multipath CPEs gets a public IPv4 address from the
fixed network and an IPv6 prefix from the mobile network (cellular2).



Consider the server is MPTCP-capable, but IPv4-only.

The first subflow can be placed using the fixed line. Fine.
The MCP will remove itself from the connection because the server is
MPTCP-capable. Cool!


The second subflow that will use cellaulr2 cannot be added because the
remote server does not support IPv6.




So in this case, if the MCP was on-path, it could be dual-stack and could
add its IPv6 address to the subflows.

[Med] Yes.




If the MCP knew the connection was being proxied, would this help? Since
as you’ve already defined, the MCP <—> server path would then be TCP. If
the MCP stayed on-path, you could do multi path towards the MCP but then
lose MPTCP capabilities to the server.

[Med] The MCP can do the following:
* It removes itself from the connection, then the connection will be e2e MPTCP... but only one access network will be used at the client side.
* The MCP may decide the stay in the connection to glue two adjacent MPTCP connections. Doing so, we benefit from both MPTCP capabilities at the client and servier side.

The exact behavior should IMHO be configurable.

So the desire is for the CPE to make this choice, based on some internal logic, and without having a MCP address to explicitly communicate with?
[Med] My take on this is to have configurable parameters that will be instructed by an operator. The MCP will behave according to those instructions. If an MCP is configured to be removed from a connection, it will coordinate its withdrawal accordingly.



Or alternatively, the MCP could always stay on-path but only add IPv6
addresses if it somehow had knowledge that was required based on the
source or destination address. Does it need to know by a flag? Would there
actually be any harm by maintaining itself on the path anyway?

[Med] I don't see a harm in doing so (see above), but those who want to have an e2e MPTCP connection may see something bad in that design. I though they wanted to completely remove the MCP from the path when both the client and server are MPTCP-capable.

That would certainly be desirable, yes. But if not possible, then there’s not much harm with always sitting on the path - it’s a bit like a NAT.



It’s not


like it’s doing anything other than packet forwarding on the initial
subflow, and just adds its IPv6 addresses to the initial exchanges in case

[Med] It needs to terminate the MPTCP connections, mange them, etc. This is exactly the MCP job.



it would be useful - and if it receives traffic to the relevant
address/port, it can start forwarding it to the far end too (possibly over
a second IPv4 subflow). Again, no need or any explicit signalling to make
this work.

[Med] We are not discussing about any explicit signaling her, Alan. We are discussing the implications on removing the MCP from the path based on SYN/ACK that will carry an MP_CAPABLE option!

My hypothesis here is that an explicit signal is not required if you choose to sit on the path or not based on the presence of MP_CAPABLE in the SYN/ACK.
[Med] The explicit signal is useful for not intercepting the initial subflow. That is, we don’t even enter the phase of waiting a SYN/ACK as the MCP does not see those.



I can share other examples where problems arise when the proxy is
blindly removed from the connection based on the presence of MP_CAPABLE in
SYN/ACK.

If it would help to clarify, please do! Since I don’t see a problem in
(1), and whilst I can see a potential problem in (2) above, I am not sure
how you are resolving it. Any other examples very welcome!

[Med] Happily. You can consider a homenet architecture https://tools.ietf.org/html/rfc7368 where MPTCP-capable hosts may not be aware of the presence of multiple paths (see this simple topology).  The use of a proxy will to deterministically make use of the path diversity.

Great! So the CPE can act as a MCP here, and optionally there could be a secondary MCP in the path to terminate paths for the far ends that do not support MPTCP (i.e. sitting on the path if the SYN/ACK does not contain MPTCP capability, and could advertise its own address in an ADD_ADDR). So why do you need an explicit signal in this case?
[Med] It is useful to deterministically force a connection to be forwarded via a node that embeds the MCP. Classical dst-based forwarding may not always allow for that. In such case, the explicit mode can be enabled inside the user’s internal network. The signal may be useful for cases that do not require reverting MPTCP back to TCP in the providers networks (implicit mode). It is also useful if.…one decides to use MPTCP connection to carry other protocol’s payload (UDP, for example) (as captured in the “Protocol” field of the MP_CONVERT MPTCP option).

Regards,
Alan