Re: [multipathtcp] Collection of MPTCP proxy scenarios.

"Weixinpeng (Jackie)" <weixinpeng@huawei.com> Tue, 05 May 2015 01:50 UTC

Return-Path: <weixinpeng@huawei.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93ABB1B2D88 for <multipathtcp@ietfa.amsl.com>; Mon, 4 May 2015 18:50:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 z1llJlurJO6c for <multipathtcp@ietfa.amsl.com>; Mon, 4 May 2015 18:50:10 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4003F1B2D85 for <multipathtcp@ietf.org>; Mon, 4 May 2015 18:50:09 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSD29564; Tue, 05 May 2015 01:50:07 +0000 (GMT)
Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 May 2015 02:50:06 +0100
Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.79]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Tue, 5 May 2015 09:50:03 +0800
From: "Weixinpeng (Jackie)" <weixinpeng@huawei.com>
To: Jordan Melzer <Jordan.Melzer@telus.com>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Thread-Topic: [multipathtcp] Collection of MPTCP proxy scenarios.
Thread-Index: AdCAwvpNnNPeumeBQfS9+TLGmrSnh///e4sA//49DdD/+HUGkP/rkfCg
Date: Tue, 05 May 2015 01:50:02 +0000
Message-ID: <C5C3BB522B1DDF478AA09545169155B46E337A2F@nkgeml507-mbx.china.huawei.com>
References: <C5C3BB522B1DDF478AA09545169155B46E336D13@nkgeml507-mbx.china.huawei.com> <553DF29E.7000502@tu-berlin.de> <C5C3BB522B1DDF478AA09545169155B46E337225@nkgeml507-mbx.china.huawei.com> <80C0017654A043479F53C41112BE847687D93BC532@WP40046.corp.ads>
In-Reply-To: <80C0017654A043479F53C41112BE847687D93BC532@WP40046.corp.ads>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.76.176]
Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B46E337A2Fnkgeml507mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/multipathtcp/0IpdbwipITRv1r8EBA9kFUbEegg>
Subject: Re: [multipathtcp] Collection of MPTCP proxy scenarios.
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 05 May 2015 01:50:13 -0000

Hi Jordan,
         Sorry for late reply. (I have just come back from a vacation..)
         I think you have provided a very good use case related with the home CPE devices that have more than one interfaces.
         As my understanding, this use case focuses on providing multipath support in the network for TCP hosts. My feeling is
         that this use case is a bit of similar to what Lukasz provided below. I think this kind of back-to-back MPTCP proxy setup might
         be useful for specific scenario.

Regards,
Xinpeng

From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Jordan Melzer
Sent: Friday, May 01, 2015 1:13 AM
To: multipathtcp@ietf.org
Subject: Re: [multipathtcp] Collection of MPTCP proxy scenarios.

Hi Xinpeng,

I have used a back-to-back MPTCP proxy setup to allow TCP to multipath over a segment of network.  My use case is allowing a home router to use more than one Internet connection.  The home router would have one MPTCP proxy and the ISP would have another.  The home devices would not need to run MPTCP, nor would any Internet servers.  The advantage of MPTCP proxies here is that the different network connections coming into the home need not have deterministic capacities, and the system supports smooth failover as well as aggregation.  DSL, LTE, cable, and WiFi (eg, from a neighbouring home) are all candidate technologies to be aggregated.

The challenge in this configuration is for the proxy to not prevent a native MPTCP device from running an end-to-end MPTCP connection.  The default proxy one gets by running a TCP proxy, eg HAPROXY, on a machine running an MPTCP kernel doesn’t avoid proxying MP_JOINs from sessions it doesn’t know about and doesn’t keep the keys the same on both sides of the connection, preventing an MPTCP capable home client from successfully doing an MP_JOIN using a path that doesn’t go through the home proxy.

One could probably modify HAPROXY to do this behaviour or make nftables rules that make MPTCP traffic bypass the proxies altogether.

I am not entirely satisfied that this kind of setup is a great idea, but the use case of bonding different connections together without changing anything at the ends of the network could be compelling.

Jordan

From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Weixinpeng (Jackie)
Sent: April 28, 2015 11:14 PM
To: lukasz.budzisz@tu-berlin.de<mailto:lukasz.budzisz@tu-berlin.de>; multipathtcp@ietf.org<mailto:multipathtcp@ietf.org>
Subject: Re: [multipathtcp] Collection of MPTCP proxy scenarios.

Hi Lukasz,
         Thanks for your information.
         I have read through the document, and find it an interesting solution, but I think the solution in the document is
about how to transmit traditional TCP traffic through multipath, and it is a bit of different from MPTCP protocol.
         Thanks.
Regards,
Xinpeng

From: Lukasz Budzisz [mailto:lukasz.budzisz@tu-berlin.de]
Sent: Monday, April 27, 2015 4:26 PM
To: Weixinpeng (Jackie)
Subject: Re: [multipathtcp] Collection of MPTCP proxy scenarios.

Dear Xinpeng,
you may have a look at the draft we presented in the IETF Paris meeting:
https://tools.ietf.org/html/draft-ayar-transparent-sca-proxy-00
Best regards,
Lukasz

------------------------------------------

Łukasz Budzisz, Ph.D.

Research Fellow

Technische Universität Berlin (TU Berlin)

Telecommunication Networks Group

Tel: +49 30 314 23836

------------------------------------------
On 27/04/15 10:20, Weixinpeng (Jackie) wrote:
Hi all,
MPTCP proxy aims to provide additional deployment support for MPTCP protocol, and the functions provided
by MPTCP proxy could involve several different aspects such as supporting establishment of MPTCP connection between
MPTCP host and traditional TCP host, aggregating of subflows to one point for security reasons,…

I am trying to figure out as many MPTCP proxy deployment scenarios as possible to have a more deep understanding
of how MPTCP proxy should work. As an example, here are some potential scenarios:
(1) MPTCP proxy in operator’s network. The operator could deploy MPTCP proxy to assist MPTCP-capable UE to communicate
with TCP server on Internet using MPTCP.
(2) MPTCP proxy in enterprise network. Enterprise network could ask all the traffic pass through security check point for security reasons,
in this case, all the subflows belong to a MPTCP connection should be aggregated at the same point.
Besides, some existing documents such as draft-deng-mptcp-proxy-01 and draft-lopez-mptcp-middlebox-00 also provide some related discussion.

So if you know some additional MPTCP proxy deployment scenarios especially the ones that have some special requirements, It will be appreciated if you could
share it here. Or if you have any other considerations on the MPTCP proxy topic, we can also discuss it here.

Thanks!

Regards,
-Xinpeng






_______________________________________________

multipathtcp mailing list

multipathtcp@ietf.org<mailto:multipathtcp@ietf.org>

https://www.ietf.org/mailman/listinfo/multipathtcp