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


Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA5A31315E0 for <>; Thu, 23 Mar 2017 09:44:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.91
X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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 8tgVouBJXIDB for <>; Thu, 23 Mar 2017 09:44:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9B039129A56 for <>; Thu, 23 Mar 2017 09:44:15 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Thu, 23 Mar 2017 16:44:12 +0000
Received: from ([fe80::a518:e59a:79b9:cc58]) by ([fe80::a518:e59a:79b9:cc58%14]) with mapi id 15.01.0977.021; Thu, 23 Mar 2017 16:44:12 +0000
To: "" <>, "" <>
Thread-Topic: MPTCP proxy work - call for ideas
Thread-Index: AdKY5fGqZBBdXE87RbWG2QzGV2x0rALDPefQ
Date: Thu, 23 Mar 2017 16:44:12 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: es-ES, en-US
Content-Language: es-ES
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; AM3PR06MB1379; 7:8kT55cfKdfTnCJMBH1ugCLdONYkr/dq9v132H68PL7YpzOAfrDw0nPbgUUR0GEpFlL4XY0m6O222pbOs/4D4iZ7GeRCiyP9uQw1ub4coI0V/miAqxH2B6ZNXyBj3+Wnn8YcQea96PFl0Rycb0J5/Teya428Wq1VeDtSLCWg2whqrmpvTj65fy4Lh2Icjeq+MdQbVAtH6o2mNRQxXjndg66o1h6QIUgFMsGpGn0YzENqKwSlNE32KaF0HAhOu261T/f9KMREmf1mZav601h66zAnalw8++0sp5yfg2d8KziJ0cQrleITo3lOIdyaJ6za51iBI0EEbeshdMDEenawdfg==
x-ms-office365-filtering-correlation-id: 57c43932-59f9-4289-655e-08d4720bd61b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:AM3PR06MB1379;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(146908506813832)(40392960112811)(100405760836317)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(20161123558025)(6072148); SRVR:AM3PR06MB1379; BCL:0; PCL:0; RULEID:; SRVR:AM3PR06MB1379;
x-forefront-prvs: 0255DF69B9
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39860400002)(39410400002)(39450400003)(39850400002)(74316002)(5660300001)(86362001)(76176999)(8936002)(81166006)(189998001)(99286003)(229853002)(8676002)(50986999)(6246003)(6116002)(790700001)(3846002)(102836003)(2900100001)(38730400002)(53346004)(53936002)(6306002)(54896002)(33656002)(54356999)(66066001)(236005)(7736002)(2950100002)(3660700001)(55016002)(6436002)(7696004)(6506006)(561944003)(2501003)(2906002)(3280700002)(25786009)(5250100002)(9686003)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR06MB1379;; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM3PR06MB13798DFA9A6A53A760E64ABF9E3F0AM3PR06MB1379eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2017 16:44:12.5836 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR06MB1379
Archived-At: <>
Subject: Re: [multipathtcp] MPTCP proxy work - call for ideas
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Mar 2017 16:44:38 -0000

Hi Phil, Yoshi

I could cover for the session a new scenario related with the application of MPTCP proxy to mobile backhaul / aggregation scenarios. Unfortunately there is not a supporting document for this yet, but I could through a descriptive scenario during the session by now, looking for a way for documenting it (if it is interesting for the people) afterwards.

>From the solution space perspective I foresee this scenario being solved by network-assisted MPTCP.

My only constraint would be that I most probably should leave the session at 18:00 (or even a bit before).

Bets regards


Luis M. Contreras

Technology and Planning
Transport, IP and Interconnection Networks
Telefónica I+D / Global CTO unit / Telefónica

Distrito Telefónica, Edificio Sur 3, Planta 3
28050 Madrid
España / Spain

Skype (Lync): +34 91 312 9084
Mobile: +34 680 947 650<>

De: multipathtcp [] En nombre de
Enviado el: jueves, 9 de marzo de 2017 16:28
Asunto: [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.