Re: [multipathtcp] MPTCP proxy work - call for ideas

<> Mon, 13 March 2017 17:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 91BB1129879 for <>; Mon, 13 Mar 2017 10:26:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OXvLqkm_yQXU for <>; Mon, 13 Mar 2017 10:26:13 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D38921295EC for <>; Mon, 13 Mar 2017 10:26:12 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 13 Mar 2017 17:26:11 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 8.3.342.0; Mon, 13 Mar 2017 17:26:10 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 13 Mar 2017 17:26:09 +0000
Received: from ([fe80::d514:fe50:560c:401e]) by ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1210.000; Mon, 13 Mar 2017 17:26:10 +0000
Thread-Topic: MPTCP proxy work - call for ideas
Thread-Index: AdKY5fGqZBBdXE87RbWG2QzGV2x0rADN4M5w
Date: Mon, 13 Mar 2017 17:26:10 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_d1d56b0cdacd47b185ac93116c486e53rew09926dag03bdomain1sy_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [multipathtcp] MPTCP proxy work - call for ideas
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Mar 2017 17:26:16 -0000

We should also point out explicitly that the text below makes some assumptions about the scenarios of interest, the nature of the solutions and the way they're presented. Discussion is welcome, if people disagree.
To be explicit, for instance:  in the single-ended proxy case, the proxy is (most likely) not on both default paths; whilst the single-ended proxy & dual-ended proxy may need different solutions, we're not developing multiple solutions for each case; etc.
Phil & Yoshi
From: multipathtcp [] On Behalf Of
Sent: 09 March 2017 15:28
Subject: [multipathtcp] MPTCP proxy work - call for ideas


We have two (adjacent) sessions in Chicago - so we have some time to dedicate to MPTCP proxy related discussions.

We'd like to offer time for people to present their proposals. These could be new ideas, or relate to what has already been proposed.
In order to try and make this discussion more fruitful, please read the words below - which frame the scope of the discussion, and suggest how to present your idea.
Please let us know if you want time - we'll divide the available time, and leave plenty of time for discussion.
PS This is MPTCP proxy discussion - there may be some side meeting about banana.
PS This discussion proceeds without changing the charter. Depending on the idea(s) that get consensus, then we work out if it needs a re-charter or not, and about coordinating with other WGs.

Best wishes,
Phil & Yoshi

MPTCP is now seeing widespread deployment in networks to bond together two accesses, such as fixed and mobile broadband, by using an MPTCP-specific proxy or proxies. There are two scenarios. The first involves two proxies, one in the home gateway or Customer Premises Equipment and one in the network, both under the control of the operator. The other scenario involves an MPTCP-enabled smartphone, with LTE and WiFi, plus a proxy in the operator's network.
The WG will analyse proposed solutions for both the single and dual proxy scenarios. The solution(s) may require changes to RFC6824bis, and may require a means of configuring set-up information in the proxy, which would be done in coordination with other IETF WGs such as DHC.

- Single & two ended proxy in scope
- Proxy(s) are under control of operator
- Only TCP traffic considered
- Open for solution proposals. First step is to analyse proposals and reach consensus on one we go ahead with, or perhaps a solution for each scenario
- Hopefully just one solution, but possibly need a different solution for 1 & 2 ended scenarios. Not multiple solutions for each scenario.
- May (but may not) require changes to rfc6284 (for instance, is it an extension to the protocol, or using the existing protocol)
- If it does require a change to 6824, then prefer to include the change in the bis, in order have one version of the protocol.
- "appropriate IETF WGs" includes any WG arising from the banana BoF
- if the solution(s) require a non-MPTCP protocol to exchange information between the two proxies, this presumably wouldn't be in the remit of MPTCP WG

We now have a 'call for solution proposals'. First step is to analyse proposals and reach consensus on one we go ahead with

*                    proposal should be in the form of a "protocol model". See RFC4101, Writing protocol models: <<to present an architectural model for how the protocol operates ...  1. What problem is the protocol trying to achieve? 2.What messages are being transmitted and what do they mean? 3. What are the important, but unobvious, features of the protocol? >>

*                    if your ideas involve multiple possibilities, please either select your favourite, or report them as separate solutions

*                    The WG will consider single and dual proxy separately. But we favour solutions with a lot of "re-use" between the single and dual proxy. This is in terms of effort by the WG, implementers and deployers. We also favour solutions where the single and dual proxied solutions can co-exist

*                    Whilst you may not be ready to present your analysis of your proposal against the (proposed) Criteria (See separate email), it may be worth bearing them in mind.