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

"Henderickx, Wim (Nokia - BE)" <wim.henderickx@nokia.com> Fri, 22 July 2016 04:17 UTC

Return-Path: <wim.henderickx@nokia.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 05C1112DEAB for <multipathtcp@ietfa.amsl.com>; Thu, 21 Jul 2016 21:17:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 bdRtpUdNFoIt for <multipathtcp@ietfa.amsl.com>; Thu, 21 Jul 2016 21:17:26 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C1D312DEBF for <multipathtcp@ietf.org>; Thu, 21 Jul 2016 21:17:25 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 2EA34630622F6; Fri, 22 Jul 2016 04:17:22 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6M4HNvO016064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Jul 2016 04:17:23 GMT
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u6M4HNSW015234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Jul 2016 06:17:23 +0200
Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.82]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Fri, 22 Jul 2016 06:17:22 +0200
From: "Henderickx, Wim (Nokia - BE)" <wim.henderickx@nokia.com>
To: "philip.eardley@bt.com" <philip.eardley@bt.com>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Thread-Topic: [multipathtcp] towards a potential work item on two-ended proxy
Thread-Index: AQHR48/xdDE8Hq+810K/F7XEsZLkuQ==
Date: Fri, 22 Jul 2016 04:17:22 +0000
Message-ID: <30A9DFA7-1413-412D-87A1-F2963FFD2861@nokia.com>
Accept-Language: nl-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/0.0.0.151008
x-originating-ip: [135.239.27.41]
Content-Type: multipart/alternative; boundary="_000_30A9DFA71413412D87A1F2963FFD2861nokiacom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/fHng_xgr105lGWgd44Q7v03jvss>
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 04:17:29 -0000

In-line with WH

From: multipathtcp <multipathtcp-bounces@ietf.org<mailto:multipathtcp-bounces@ietf.org>> on behalf of "philip.eardley@bt.com<mailto:philip.eardley@bt.com>" <philip.eardley@bt.com<mailto:philip.eardley@bt.com>>
Date: Thursday 21 July 2016 at 18:12
To: "multipathtcp@ietf.org<mailto:multipathtcp@ietf.org>" <multipathtcp@ietf.org<mailto:multipathtcp@ietf.org>>
Subject: [multipathtcp] towards a potential work item on two-ended proxy

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).

WH> Given the interest from operator and vendor community (see author/co-authors of the plain mode/transparent mode draft) it would be strange that the IETF would not take on this work. The goal here is defining an interoperable MP-TCP proxy solution between different devices from different vendors.

-          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)

WH> MPTCP proxy is in the charter, so we should update it to capture and define all MP-TCP proxy deployments, single ended, dual ended.

-          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?

WH> The use case is the same but the deployment scenario is different, so I don’t see why we have to choose between them

-          I think there was mention (by Wim??) that there’s a third proposal – how does this fit in, or did I get it wrong?

WH> No there is not a 3rd proposal afaik

-          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 it would be good to have more discussion before attempting to write some potential charter text (and then seeing if there’s consensus for it).

Thanks!
Philip Eardley
Research and Innovation
This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000