Re: [multipathtcp] q about on-path proxy
<philip.eardley@bt.com> Fri, 24 March 2017 14:50 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 CF7FC129650 for <multipathtcp@ietfa.amsl.com>; Fri, 24 Mar 2017 07:50:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.397
X-Spam-Level:
X-Spam-Status: No, score=-5.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, 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 0evSqUPOlQ3O for <multipathtcp@ietfa.amsl.com>; Fri, 24 Mar 2017 07:50:02 -0700 (PDT)
Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.136]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40D9A128BBB for <multipathtcp@ietf.org>; Fri, 24 Mar 2017 07:50:00 -0700 (PDT)
Received: from E07HT05-UKBR.domain1.systemhost.net (193.113.197.167) by EVMED02-UKBR.bt.com (10.216.161.32) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 24 Mar 2017 14:49:58 +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 14:49:57 +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 14:49:57 +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 14:49:57 +0000
From: philip.eardley@bt.com
To: 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: AQHSoutDVeuhT2pHjE2DvPLVkd4SjKGgmViAgAADZwCAAAcpgIAABRGAgADCfYCAAKjOAIAA8hGAgACHRQCAAFYXQIAAFdjwgAAKnNCAABDloA==
Date: Fri, 24 Mar 2017 14:49:56 +0000
Message-ID: <7d9118f841c54079a486d1ffb113faec@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> <09ac1c9f9f1f4643a7813c7cb4df7ac1@rew09926dag03b.domain1.systemhost.net> <787AE7BB302AE849A7480A190F8B933009E4011C@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E4011C@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
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_7d9118f841c54079a486d1ffb113faecrew09926dag03bdomain1sy_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/7fS7B-0tcovm3Zh4MLA70bwgLNU>
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 14:50:07 -0000
Thanks. Several points here I don’t understand, but it seems this is not the preferred solution approach anyway. So rather than following up the details, let me ask: Does anyone want to pursue an “implict mode” solution to the single-ended proxy scenario? Please shout if you do, otherwise I suggest we concentrate on an “explicit mode” solution for this scenario. Thanks phil From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: 24 March 2017 08:57 To: Eardley,PL,Philip,TUB8 R <philip.eardley@bt.com>; nishida@sfc.wide.ad.jp; Olivier.Bonaventure@uclouvain.be Cc: multipathtcp@ietf.org Subject: RE: [multipathtcp] q about on-path proxy Hi Phil, Please see inline. Cheers, Med De : philip.eardley@bt.com<mailto:philip.eardley@bt.com> [mailto:philip.eardley@bt.com] Envoyé : vendredi 24 mars 2017 14:11 À : philip.eardley@bt.com<mailto:philip.eardley@bt.com>; BOUCADAIR Mohamed IMT/OLN; nishida@sfc.wide.ad.jp<mailto:nishida@sfc.wide.ad.jp>; Olivier.Bonaventure@uclouvain.be<mailto:Olivier.Bonaventure@uclouvain.be> Cc : multipathtcp@ietf.org<mailto:multipathtcp@ietf.org> Objet : RE: [multipathtcp] q about on-path proxy Forgot something, added in line From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com<mailto:philip.eardley@bt.com> Sent: 24 March 2017 07:29 To: mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>; nishida@sfc.wide.ad.jp<mailto:nishida@sfc.wide.ad.jp>; Olivier.Bonaventure@uclouvain.be<mailto:Olivier.Bonaventure@uclouvain.be> Cc: multipathtcp@ietf.org<mailto: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.>> [Med] IMHO, the implicit mode is more suitable for the dual-proxy case rather than the single proxy…but let’s discuss this one. 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. [Med] It doesn’t. The MCP can be removed from the path if the MP_CAPABLE is received from the RM. 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. [Med] Scaling is not an issue here given that the implicit mode assumes that MCP inspects all TCP traffic. Tracking the 3WHS of the initial subflow and then get out from the connection if DST is MPTCP-capable is more optimal compared to systematically be inserted in all connections. Means to mitigate DoS problems are called out in the draft (rate-limit state creation, limit subflow creation, etc.). * 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 [Med] A white list approach may be considered in early stages. That is always insert MP_PREFER_PROXY except for this list of servers. 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? [Med] This increases the delay of the connection establishment for non-obvious added value. 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) [Med] For incoming connections (MCP-to-UE), there is no need to insert MP_PREFER_PROXY. Do the currently deployed solutions for the smartphone scenario use MP_PREFER_PROXY, or do they use an “explicit mode” solution? [Med] The deployments I’m aware of are using the explicit mode. 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
- [multipathtcp] q about on-path proxy Yoshifumi Nishida
- Re: [multipathtcp] q about on-path proxy Olivier Bonaventure
- Re: [multipathtcp] q about on-path proxy mohamed.boucadair
- Re: [multipathtcp] q about on-path proxy mohamed.boucadair
- Re: [multipathtcp] q about on-path proxy Olivier Bonaventure
- Re: [multipathtcp] q about on-path proxy mohamed.boucadair
- Re: [multipathtcp] q about on-path proxy Yoshifumi Nishida
- Re: [multipathtcp] q about on-path proxy mohamed.boucadair
- Re: [multipathtcp] q about on-path proxy Olivier Bonaventure
- Re: [multipathtcp] q about on-path proxy Yoshifumi Nishida
- Re: [multipathtcp] q about on-path proxy mohamed.boucadair
- Re: [multipathtcp] q about on-path proxy philip.eardley
- Re: [multipathtcp] q about on-path proxy philip.eardley
- Re: [multipathtcp] q about on-path proxy mohamed.boucadair
- Re: [multipathtcp] q about on-path proxy philip.eardley
- Re: [multipathtcp] q about on-path proxy Yoshifumi Nishida
- Re: [multipathtcp] q about on-path proxy Henderickx, Wim (Nokia - BE/Antwerp)