[multipathtcp] Impact of any of the mptcp proxy proposals on base protocol?

<philip.eardley@bt.com> Mon, 27 March 2017 22:35 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 6E90312966F for <multipathtcp@ietfa.amsl.com>; Mon, 27 Mar 2017 15:35:54 -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 7kns2tWdcEUR for <multipathtcp@ietfa.amsl.com>; Mon, 27 Mar 2017 15:35:51 -0700 (PDT)
Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F9DA126BFD for <multipathtcp@ietf.org>; Mon, 27 Mar 2017 15:35:51 -0700 (PDT)
Received: from E07HT05-UKBR.domain1.systemhost.net (193.113.197.167) by EVMED06-UKBR.bt.com (10.216.161.38) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 27 Mar 2017 23:35:45 +0100
Received: from rew09926dag03a.domain1.systemhost.net (10.55.202.18) by E07HT05-UKBR.domain1.systemhost.net (193.113.197.167) with Microsoft SMTP Server (TLS) id 8.3.342.0; Mon, 27 Mar 2017 23:35:49 +0100
Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03a.domain1.systemhost.net (10.55.202.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 27 Mar 2017 23:35:28 +0100
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; Mon, 27 Mar 2017 23:35:27 +0100
From: <philip.eardley@bt.com>
To: <multipathtcp@ietf.org>
Thread-Topic: Impact of any of the mptcp proxy proposals on base protocol?
Thread-Index: AdKnP+BaIPzlfde7R/qtTexcgZ9/aA==
Date: Mon, 27 Mar 2017 22:35:27 +0000
Message-ID: <5ec326f8da2a492f88266cb0687b6cb0@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.27]
Content-Type: multipart/alternative; boundary="_000_5ec326f8da2a492f88266cb0687b6cb0rew09926dag03bdomain1sy_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/UU7aHMSulmKDRrpgkv6eFl6-ej8>
Subject: [multipathtcp] Impact of any of the mptcp proxy proposals on base protocol?
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: Mon, 27 Mar 2017 22:35:54 -0000

Hi,
My personal view is that the revised base protocol (RFC6824bis) is what all MPTCP-enabled endpoints implement. So I want to make sure that we think carefully about including any changes needed on the endpoint to get the proxy scenarios to work.
If I get it right, this means that:

*         2-ended proxy scenarios -  endpoints run rfc6824bis, proxy devices run new mptcp-proxy protocol. Think this is ok - operator has chosen to deploy the proxies, no changes needed on the endpoints.

*         1-ended proxy scenario with explicit mode - endpoint is explicitly configured to know about the proxy and runs mptcp with additional capability (MP_CONVERT info element in data, or some other proposal). It may be OK for this not to be in the bis, since the endpoint is explicitly configured with this capability, so it's reasonable to expect the operator to upgrade the smartphone's mptcp. Opinions?

*         1-ended proxy scenario in implicit mode. Endpoint runs bis with additional capability (MP_PREFER_PROXY MPTCP Option or some other proposal). Since this mode is implicit, I think this would need to be in the bis - or alternatively, we don't support this scenario. Opinions?
Comments?
Thanks
phil