IETF Logo Mail Archive

[multipathtcp] Towards a Multipath TCP Proxy work item

<philip.eardley@bt.com> Thu, 10 November 2016 19:17 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 A6E73129979 for <multipathtcp@ietfa.amsl.com>; Thu, 10 Nov 2016 11:17:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.107
X-Spam-Level:
X-Spam-Status: No, score=-4.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 83KH7u14OSUW for <multipathtcp@ietfa.amsl.com>; Thu, 10 Nov 2016 11:17:29 -0800 (PST)
Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.138]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A2E51295A3 for <multipathtcp@ietf.org>; Thu, 10 Nov 2016 11:17:27 -0800 (PST)
Received: from EVHUB04-UKBR.domain1.systemhost.net (193.113.108.172) by EVMED04-UKBR.bt.com (10.216.161.34) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 10 Nov 2016 19:17:26 +0000
Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by EVHUB04-UKBR.domain1.systemhost.net (193.113.108.172) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Nov 2016 19:17:26 +0000
Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 10 Nov 2016 19:17:25 +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; Thu, 10 Nov 2016 19:17:25 +0000
From: philip.eardley@bt.com
To: multipathtcp@ietf.org
Thread-Topic: Towards a Multipath TCP Proxy work item
Thread-Index: AdI7N1nf0aKADf/wTiuUhe6Yz4SJ8QATzjrQ
Date: Thu, 10 Nov 2016 19:17:25 +0000
Message-ID: <0898853c01b245aa8b3c45c9da478d6a@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.23]
Content-Type: multipart/alternative; boundary="_000_0898853c01b245aa8b3c45c9da478d6arew09926dag03bdomain1sy_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/3SQ05kiyXeH4a7x8pJKUjeIShns>
Subject: [multipathtcp] Towards a Multipath TCP Proxy work item
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: Thu, 10 Nov 2016 19:17:32 -0000

Hi,
Perhaps this is speaking too soon, but it looks like the very active discussion is reaching some common understanding?


We're trying to work out what a work item might look like, so would like to understand what assumptions we would make, eg about the scenario, & what common agreements we'd assume & restrictions on how the solution works. This seems important to frame work by WG. If possible we'd like discussion on these points to avoid getting into the fine details of one particular existing proposal.

What we'd appreciate is a summary of what the assumptions /understandings are about:

*         The scenario (for instance: the MPTCP-enabled host knows the address of the proxy (eg through configuration); and it knows the address of the 'legacy' host it wants to communicate with)

*         If any impact is already envisaged on the current MPTCP protocol's fallback behaviour and coping with middleboxes

*         If we can agree that the solution is based on a new MPTCP option

*         If any impact is already envisaged on the current MPTCP protocol's semantics (other than the new option) eg in terms of https://tools.ietf.org/html/rfc6824#section-4

*         If any impact is already envisaged on TCP's semantics, or any mods are needed, or assumptions about its behaviour, etc

*         If any impact is already envisaged on other existing transport protocol's semantics (presuming people still would like non-TCP in scope?)

*         Anything else that you think is needed in order to frame the work item

It may be clearer to do this for the two use cases (single-ended proxy, ie where only one host is MPTCP-enabled; and double-ended proxy, ie where neither host is MPTCP-enabled).

This may seem like a long list, but most of the answers can be "none" - we'll end up with just a short paragraph or a few bullets in the charter.

We'd also have to work out interactions with non-MPTCP WGs, but Mirja and IESG will probably want the main input on this.

Thanks
Phil & Yoshi

v2.23.0 | Report a Bug | By Email