Re: [multipathtcp] q about on-path proxy

<philip.eardley@bt.com> Fri, 24 March 2017 13:11 UTC

Return-Path: <philip.eardley@bt.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 08C2912943F for <multipathtcp@ietfa.amsl.com>; Fri, 24 Mar 2017 06:11:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level:
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 7KMns4SpRT3Z for <multipathtcp@ietfa.amsl.com>; Fri, 24 Mar 2017 06:11:11 -0700 (PDT)
Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.138]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51C2912714F for <multipathtcp@ietf.org>; Fri, 24 Mar 2017 06:11:09 -0700 (PDT)
Received: from E07HT05-UKBR.domain1.systemhost.net (193.113.197.167) by EVMED04-UKBR.bt.com (10.216.161.34) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 24 Mar 2017 13:11:04 +0000
Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by E07HT05-UKBR.domain1.systemhost.net (193.113.197.167) with Microsoft SMTP Server (TLS) id 8.3.342.0; Fri, 24 Mar 2017 13:11:06 +0000
Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03b.domain1.systemhost.net (10.55.202.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 24 Mar 2017 13:11:05 +0000
Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1210.000; Fri, 24 Mar 2017 13:11:05 +0000
From: philip.eardley@bt.com
To: philip.eardley@bt.com, mohamed.boucadair@orange.com, nishida@sfc.wide.ad.jp, Olivier.Bonaventure@uclouvain.be
CC: multipathtcp@ietf.org
Thread-Topic: [multipathtcp] q about on-path proxy
Thread-Index: AQHSoutDVeuhT2pHjE2DvPLVkd4SjKGgmViAgAADZwCAAAcpgIAABRGAgADCfYCAAKjOAIAA8hGAgACHRQCAAFYXQIAAFdjw
Date: Fri, 24 Mar 2017 13:11:05 +0000
Message-ID: <09ac1c9f9f1f4643a7813c7cb4df7ac1@rew09926dag03b.domain1.systemhost.net>
References: <CAO249ydsuoAUn0y6yo62OM8mdp_AfyS1cA+patgQ84ata5piXw@mail.gmail.com> <a5ae92e4-c0c9-96c6-a575-f23891189087@uclouvain.be> <787AE7BB302AE849A7480A190F8B933009E37584@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <ee22e83a-464e-f3a1-3d48-15043bcd6f74@uclouvain.be> <787AE7BB302AE849A7480A190F8B933009E3C5EC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <CAO249yc6KkvxKG3g5NzLguZZfEfGrvG1qFfvXL0WNwzECWdrLg@mail.gmail.com> <f7ab3458-7004-dcce-5f4a-c036705d0530@uclouvain.be> <CAO249yfzT32mku_1jwH+H0jKwa+LuCLQ2RsORrrqcDMA3qNL7A@mail.gmail.com> <787AE7BB302AE849A7480A190F8B933009E3FE7E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <a95767ffdaba46adb384e7d47b973ffa@rew09926dag03b.domain1.systemhost.net>
In-Reply-To: <a95767ffdaba46adb384e7d47b973ffa@rew09926dag03b.domain1.systemhost.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.216.161.24]
Content-Type: multipart/alternative; boundary="_000_09ac1c9f9f1f4643a7813c7cb4df7ac1rew09926dag03bdomain1sy_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/RrUjPdB2qjQQxtRaUR9mtRn1tmk>
Subject: Re: [multipathtcp] q about on-path proxy
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 24 Mar 2017 13:11:20 -0000

Forgot something, added in line

From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: 24 March 2017 07:29
To: mohamed.boucadair@orange.com; nishida@sfc.wide.ad.jp; Olivier.Bonaventure@uclouvain.be
Cc: multipathtcp@ietf.org
Subject: Re: [multipathtcp] q about on-path proxy

Following up on this.
I want to concentrate first **specifically** on the solution for this use case:

<<. The other scenario involves an MPTCP-enabled smartphone, with LTE and WiFi, plus a proxy in the operator’s network.>>

Looking first at the solution using MP_PREFER_PROXY on the SYN  ("implicit mode" solution)

I think the assumption is:
* the smartphone knows that the other end point is not MPTCP enabled, or prefers to use a proxy even if the other end point is MPTCP enabled.

I don’t like this assumption as it hinders end-to-end deployment of MPTCP.

Solution could be something on the lines you suggest below:
* the proxy tracks what end points are MPTCP enabled and which ones aren’t. I think this would run into scaling and DoS problems.
* or the smartphone tracks what end points are enabled and which ones aren’t; it needs to do this by which interface it tries to reach the other end point. Could be quite a lot of info to track

Perhaps it’s possible to devise a solution where the proxy adds a  HI_I_AM_A_PROXY onto the SYN_ACK (assuming the SYN_ACK goes through the proxy). Not sure what the next step would be. I guess one approach is to give up on the first connection and immediately send a new SYN with a PROXY_PLEASE_INSERT_YOURSELF. Seems to be getting cumbersome?

Another assumption, I think is:
* connection is initiated from the smartphone
It would be nice if the solution also worked for connections initiated by the other end point (and definitely nothing bad must happen)

Do the currently deployed solutions for the smartphone scenario use MP_PREFER_PROXY, or do they use an “explicit mode” solution?

Thanks
phil

From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>
Sent: 24 March 2017 01:42
To: Yoshifumi Nishida <nishida@sfc.wide.ad.jp<mailto:nishida@sfc.wide.ad.jp>>; Olivier.Bonaventure@uclouvain.be<mailto:Olivier.Bonaventure@uclouvain.be>
Cc: multipathtcp <multipathtcp@ietf.org<mailto:multipathtcp@ietf.org>>
Subject: Re: [multipathtcp] q about on-path proxy

Hi Yoshi,

Please see inline.

Cheers,
Med

De : Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp]
Envoyé : jeudi 23 mars 2017 23:38
À : Olivier.Bonaventure@uclouvain.be<mailto:Olivier.Bonaventure@uclouvain.be>; BOUCADAIR Mohamed IMT/OLN
Cc : multipathtcp
Objet : Re: [multipathtcp] q about on-path proxy

Hello Olivier, Med,

Thanks for providing detailed responses. I feel that things now got clearer than before.
In my understanding, the benefits for on-path mode is MCP can stop intercepting and splitting connection once it learns that both endpoints support MPTCP.  if there're other benefits, please point out.

One thing which is not very clear to me yet is MP_PREFER_PROXY.
Med explained that there is a way to learn the endpoints support MPTCP. I think MCPs can learn it through the method described in Figure 15, however I'm not sure how the sender can learn it.
[Med] An implementation example would look like the following :

·         A sends a SYN message with MP_CAPABLE+MP_PREFER_PROXY to B

·         This SYN is intercepted by an MCP which tracks the connection, that is: it removes the MP_PREFER_PROXY and add filters to intercept relevant incoming SYN/ACK. The SYN (MP_CAPABLE) is then forwarded to the next hop and so on, until it reaches B.

·         If the SYN/ACK received from B includes MP_CAPABLE, the MCP will forward it to A. A is now aware that B is MPTCP-capable and they can establish subsequent subflows directly. The MCP does not announce explicitly itself to A.

This makes me wonder why the sender needs to set MP_PREFER_PROXY.
[Med] The entity that sets the MP_PREFER_PROXY is likely to be an MCP. This is the typical dual-proxy case. This signal is set so that native MPTCP connections received from hosts of a LAN are distinguished from the connections the MCP transforms into MPTCP. An MCP located at the network side will intercept those connections that are proxied; not the ones that can be managed by endhosts.

This signal is motivated also by the requirements from MCP operators to control the usage of their MCP resources: only proxied MPTCP connections are assisted by an MCP.
The signal is also a guard against MCPs that will by default transform an MPTCP connection into a TCP connection. Allowing native connections to bypass that MCP is good to have.

Instead, I am thinking that using a certain option or flag that indicates "MCP has intercepted this flow" may look more reasonable. This seems to be more explicit signal to the downstream MCP.
[Med] Thank you for sharing your preference. I’m personally neutral on the structure of the MP_PREFER_PROXY signal. The most important point at this stage is to assess whether we need it or not.

Also, even when on-path MCP is not there, the sender might put MP_PREFER_PROXY. This looks the waste of resource.
[Med] This is a fair enough.

Thanks,
--
Yoshi

On Thu, Mar 23, 2017 at 1:11 AM, Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be<mailto:Olivier.Bonaventure@uclouvain.be>> wrote:
Yoshifumi,

Thanks for the response. I think I got basic idea.  Now I have other
questions..
I feel on-path mode a bit more complex than off-path mode.

1:  I am thinking that when uMCP intercept the packet from C, we can
send MP_Convert Information Element to dMCP.
    (and dest will be dMCP instead of S)
    We don't need to use source routing and spoofing techniques on dMCP
in this approach, which looks simpler to me.

There are three abstract ways to ensure that the packets from the uMCP reach the dMCP.

- influence the control plane (e.g. routing tables by using source specific routing) of the network between the uMCP and the dMCP to ensure that the packets reach the dMCP
- change all network packets (e.g. by using source routing)
- change the destination address of all flows initiated by the client

An advantage of the fist solution is that there is no per-packet overhead. A disadvantage of this solution is that it can be costly in a large network to implement and maintain this source specific routing.

An advantage of the second solution is that the IP addresses of the endpoints are preserved. A drawback of this solution is that there is a per packet overhead.

A drawback of the latter solution is that the network operator does not have visibility anymore on the traffic between the uMCP and the dMCP. All traffic appears as TCP connections to the dMCP. An advantage of this solution is that its overhead is minimised since only the SYN carries an additional TCP option.

There is no clear winner among these solutions and we should let the operators select the approach that better suits their deployment and operational concerns.

2: I am wondering how a sender will use MP_PREFER_SIGNAL.
    In my understanding, the possible use cases would be:
         a) A sender knows the receiver doesn't support MPTCP, but it
still wants to utilize MPTCP in some portions of path.
             In this case, it seems to me that we presume the existence
of MCP.
             If so, why we cannot use explicit mode (off-path mode) here?

         b) A sender not sure if the receiver supports MPTCP or not.
But, even if the receiver doesn't support MPTCP, it wants to use MPTCP
in some portions of path at least.
            In this case, uMCP will intercept packets and split the
connection regardless of whether the receiver supports MPTCP.
            The sender cannot know if the receiver supports MPTCP or not
because MCP works transparently.
            So, it can never learn about the receiver.
            If I think this way, it seems MP_PREFER_SIGNAL is not
beneficial when the receiver supports MPTCP.

Currently, the main usage is the following in transparent mode


C --- uMCP ------ R1 ------ dMCP -------- R2 ------ S


The client wants to create a Multipath TCP connection towards S. A typical example is that C is an iPhone using the Siri application and S is Apple's server.

The uMCP and dMCP are useful when either the Client or the Server does not support Multipath TCP. If they both support Multipath TCP, it could be useful to allow the connection to pass through the uMCP and dMCP without terminating it. To achieve this in transparent mode, the dMCP must be able to distinguish between :

- a SYN containing an MP_CAPABLE option that was added by the uMCP and that must be terminated by the dMCP
- a SYN containing an MP_CAPABLE option that was inserted by the Client and should not be terminated by the dMCP

This is basically one bit of information. The MP_PREFER_PROXY option indicates that the MP_CAPABLE option was added by an upstream MCP and the connection should be terminated by a downstream MCP.

There are other use cases where the uMCP does not want the dMCP to terminate the Multipath TCP connections for policy reasons or because the uMCP knows that the server directly supports Multipath TCP.

I'm not a big fan of using an entire Multipath TCP option to carry one bit of information in the SYN. I would prefer to define a Proxy flag inside the MP_CAPABLE option as proposed several years ago on this list. This would be a clean solution with a very small overhead. We have spare bits in the MP_CAPABLE option.



Olivier