Re: [multipathtcp] towards a potential work item on two-ended proxy

"Ivancic, William D. (GRC-LCA0)" <william.d.ivancic@nasa.gov> Fri, 22 July 2016 20:45 UTC

Return-Path: <william.d.ivancic@nasa.gov>
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 D877F12D0FB for <multipathtcp@ietfa.amsl.com>; Fri, 22 Jul 2016 13:45:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.487
X-Spam-Level:
X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 y5aY7ElGKocm for <multipathtcp@ietfa.amsl.com>; Fri, 22 Jul 2016 13:45:10 -0700 (PDT)
Received: from ndjsvnpf104.ndc.nasa.gov (NDJSVNPF104.ndc.nasa.gov [198.117.1.154]) by ietfa.amsl.com (Postfix) with ESMTP id E8ADB12D8D1 for <multipathtcp@ietf.org>; Fri, 22 Jul 2016 13:45:06 -0700 (PDT)
Received: from ndjsppt105.ndc.nasa.gov (ndjsppt105.ndc.nasa.gov [198.117.1.199]) by ndjsvnpf104.ndc.nasa.gov (Postfix) with ESMTP id 3C39B40079C5; Fri, 22 Jul 2016 15:45:05 -0500 (CDT)
Received: from NDJSCHT115.ndc.nasa.gov (ndjscht115-pub.ndc.nasa.gov [198.117.1.215]) by ndjsppt105.ndc.nasa.gov (8.15.0.59/8.15.0.59) with ESMTP id u6MKj4Gn010156; Fri, 22 Jul 2016 15:45:04 -0500
Received: from NDJSMBX203.ndc.nasa.gov ([169.254.2.200]) by NDJSCHT115.ndc.nasa.gov ([198.117.1.215]) with mapi id 14.03.0294.000; Fri, 22 Jul 2016 15:45:04 -0500
From: "Ivancic, William D. (GRC-LCA0)" <william.d.ivancic@nasa.gov>
To: Christoph Paasch <cpaasch@apple.com>, Philip Eardley <philip.eardley@bt.com>
Thread-Topic: [multipathtcp] towards a potential work item on two-ended proxy
Thread-Index: AdHjZ4nHkoHVP9v7Rwqgdt1DLC/zlgAvIGGAAA+3KgA=
Date: Fri, 22 Jul 2016 20:45:04 +0000
Message-ID: <D3B7FD61.4ACEA%william.d.ivancic@nasa.gov>
References: <b779dd12f1bb412c96c800eddaaf0247@rew09926dag03b.domain1.systemhost.net> <BD18EDA4-5564-47EE-8EA7-38265A93D36F@apple.com>
In-Reply-To: <BD18EDA4-5564-47EE-8EA7-38265A93D36F@apple.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.5.160527
x-originating-ip: [76.188.210.200]
Content-Type: multipart/related; boundary="_004_D3B7FD614ACEAwilliamdivancicnasagov_"; type="multipart/alternative"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-22_16:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/fa-EsCUxkOXps-Uojdyg6SGT98E>
Cc: MultiPath TCP - IETF WG <multipathtcp@ietf.org>
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy
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: Fri, 22 Jul 2016 20:45:13 -0000

On our NASA Atmospheric Research vehicles, we are beginning to test MP-TCP.  Current testing is between aircraft communication relay and ground communication relay without a proxy.  But, the attached figure (I could eventually put this in ascii art if need be) shows the need for two proxies.  I suspect this architecture is not that uncommon in mobile communication platforms that may be acting as the communication relay (military, first responders, etc…).

Will



[cid:8B1F62E2-78B3-44F6-9701-D557A7BE5DEF]


From: multipathtcp <multipathtcp-bounces@ietf.org<mailto:multipathtcp-bounces@ietf.org>> on behalf of Christoph Paasch <cpaasch@apple.com<mailto:cpaasch@apple.com>>
Date: Friday, July 22, 2016 at 5:19 AM
To: Philip Eardley <philip.eardley@bt.com<mailto:philip.eardley@bt.com>>
Cc: MultiPath TCP - IETF WG <multipathtcp@ietf.org<mailto:multipathtcp@ietf.org>>
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy

Hello,

On Jul 21, 2016, at 6:12 PM, philip.eardley@bt.com<mailto:philip.eardley@bt.com> wrote:
We started the discussion yesterday on a potential new work item on “two-ended proxy scenario” – where there’s an MPTCP proxy in both the CPE and an aggregation point (for instance). The current charter is that one end host is MPTCP.

If I can try and summarise the brief discussion yesterday (plus some side discussions) (please correct my inaccuracies):
-          there are now deployments & products with an MPTCP proxy at each end, plus planned Broadband Forum work (WT-348 is about to be made public, with subsequent work to follow). So IETF work is timely (eg help allow an operator to buy CPE from one vendor and aggregation gateway from another vendor).
-          However, some people object to going beyond the current charter’s “one-ended proxy scenario” (since the “two-ended proxy” discourages deployment of MPTCP to all the end hosts, which is the ultimate goal)
-          There are two proposals (transparent & plain mode: draft-boucadair-mptcp-plain-mode-08 & draft-peirens-mptcp-transparent-00). Are these addressing different use cases, or do we need to choose between them? would a (potential) charter item be to standardise existing draft(s), or to solve a problem /scenario?
-          I think there was mention (by Wim??) that there’s a third proposal – how does this fit in, or did I get it wrong?
-          One aspect of the plain mode draft is to allow transport of UDP traffic as well as TCP traffic. I think this is a proposal that should be discussed separately  - for instance it needs INT-area expertise.

I think the proxy-work is built of two items:

1. The documentation of how a deployment of one-ended and two-ended proxies look a like and the things that one should consider when doing so.

2. The plain-mode-option.


The point 1) is specific to MPTCP and probably useful to include in the charter.

For the point 2), I agree with Alan's comment in that this is entirely independent from MPTCP. It is basically a mechanism for 0-RTT proxying, by communicating the relevant IP-addresses between the proxies. Thus, I don't think that we should specify the plain-mode option in the MPTCP working-group, as the same plain-mode option might be useful in any other transport-layer protocol. And we probably don't want a list of draft-sctp-plain-mode, draft-tcp-plain-mode, ...