Re: [multipathtcp] Towards a Multipath TCP Proxy work item

Robert Skog <> Tue, 15 November 2016 10:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B5B1E129A68 for <>; Tue, 15 Nov 2016 02:12:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EFiVmHNYaZIJ for <>; Tue, 15 Nov 2016 02:12:48 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D1A6F129A33 for <>; Tue, 15 Nov 2016 02:12:43 -0800 (PST)
X-AuditID: c1b4fb2d-5b107980000009f7-48-582adf9a657e
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 36.E1.02551.A9FDA285; Tue, 15 Nov 2016 11:12:42 +0100 (CET)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 15 Nov 2016 11:09:27 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HRDWL1Z71F5wYiSK0nXbs3grSXAsA01QpOcDZ0tWClg=; b=a0UkLlhD5nRMUb5s4uDUCLvN9sBDbxGz1gor5E5VRm1J7vF5Vq7BZF39gmuqDknaC1+2T5LGwuVWhnGMuVBb++plMtJAydEBad9N0Yp2iKRmnhrWhxHs8FrhMJztjseDkBZQSX2A4ENi3jMc1i+e0O6o2p5PqJIPfUq6PJNzGHA=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.2; Tue, 15 Nov 2016 10:08:52 +0000
Received: from ([]) by ([]) with mapi id 15.01.0734.004; Tue, 15 Nov 2016 10:08:52 +0000
From: Robert Skog <>
To: "" <>, "" <>, "" <>, "" <>
Thread-Topic: [multipathtcp] Towards a Multipath TCP Proxy work item
Thread-Index: AdI7N1nf0aKADf/wTiuUhe6Yz4SJ8QATzjrQAK3WTAAAAHG7lAA1kHYAAAIQ14AAAnGiUA==
Date: Tue, 15 Nov 2016 10:08:52 +0000
Message-ID: <>
References: <> <> <> <> <787AE7BB302AE849A7480A190F8B933009DB3E06@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DB3E06@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; VI1PR07MB1262; 7:+M/yIuspEMAr6P30G6DSDeonuupacCSBGDPNcrXRpwsLmm2loyjlp5OxqHyw3IGsKfZiRznMUFZORjUoOn4earauBCgdl9Rs1wKAY8IepX/516/rKGjhWvG1ivIr4ov6auYf90275c/bHQ9aMUEMiaP9jCQfxb1aJJ6scBH3kkyJs7pdAZFwB47WPdeAbs+gFJG9EjsvuxoD+5whah4y1n0PLNUwQTfQsRMDg65D7LF5ddNtemuTIjioYePvE/UDeLNw0iM0gKQNb/VQJPEYvrO8sYJ7irQxcWCkZ26GsTQc6B4SPqEG7tPmOSVpX1eQQb8ANXNrpGCFzFzNDtbOgK8aq2LN8/Y6vLERjdFSaZk=
x-ms-office365-filtering-correlation-id: 379318ef-126e-4a1b-8e1a-08d40d3f66e5
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:VI1PR07MB1262;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(146908506813832)(192374486261705)(18271650672692)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6061324); SRVR:VI1PR07MB1262; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1262;
x-forefront-prvs: 012792EC17
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(199003)(24454002)(189002)(3846002)(3660700001)(81166006)(81156014)(33656002)(561944003)(3280700002)(102836003)(4326007)(790700001)(6116002)(3900700001)(2906002)(106356001)(122556002)(7696004)(93886004)(105586002)(86362001)(2201001)(87936001)(8676002)(9686002)(8936002)(66066001)(2501003)(189998001)(54356999)(76176999)(92566002)(5660300001)(50986999)(101416001)(2900100001)(68736007)(5001770100001)(2950100002)(76576001)(97736004)(229853002)(7846002)(7736002)(77096005)(7906003)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB1262;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR07MB1262176069646E15A1813F2C8BBF0VI1PR07MB1262eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2016 10:08:52.3841 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1262
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTURjHOe9le50NjkvzSSNyVKR4N2qkRGLBggTpQ60L5NIXFeeFvTbS T/uQlVPB0KKJ2oxpziuKaKWGzjAVUXRpoE0RL5FiWlqyTMvtJPjt9zz//3M7HI6WDbA+XEp6 Fq9NV2vkIgljVLUfDyqdCVCFGs1YYRmuoRUr+mlK0buyIFas130SKaobatAFVvlwo5hSvim1 i5Vms4NSPlgcECntBiMdx96URCXymhQdrw05Hy9JLn4yJMqct1H3TfY/jB5tDFIG5MYBPg29 jXqxAUk4GW5EYCkwsiToRzD27ZErYHAhDWsFCzRRiilo7ywWkeA9gry6L8jZTIQDobmyyVXi iecRdNlWaKdA4wiYXXgsdvJBHAOFLdWskz3xRdhp7hQTvgZFy9uurRh8Avqmnu1O4Dgpvg2/ DaFkWAsFs5anIqfHDd+F2aFyxskIH4LNwXqKzPKGyfkX/6/DYO4coQl7wde5HZb4b0HH2pyI 5I/BUr7edQ1gEw0FehNDhFhY7LBQezzzuQI5FwKcCrZNP5LWgNk+QZHaHgQfqrZY4jkCjmEl ydez0N7X6uopwzy8ashF5CF8wP4xDxUh/9J9exPOgIaKKhdLsQcMGOeZ0t22NPaHprchxOIH JfmzYsKnILesXLw/b0LiWuQl8IKQlhQeEcxrUxIEISM9OJ3PakG7H6yndSvoNapbjrYizCH5 AWnmqL9Kxqp1QnaaFQFHyz2lZycCVDJpojo7h9dm3NHe0/CCFflyjNxbesYyc12Gk9RZfCrP Z/LaPZXi3Hz0KFBx9HKlt8O325G2/VJPD7iX/40rtEU3D014rCYYfGOsulGPtp0284+l8Lz+ Ima9sks1+q6ZHdmKXK0tKTPpaiJtYQ7TYNtPq8S0dLXAHosylZqT7uO6pRHP2O0b55av1I7L uluej04dnvw+mRM7FlE31xG3PYUuRb1qiP81LWeEZHVYAK0V1P8Aiakym1wDAAA=
Archived-At: <>
Cc: "" <>
Subject: Re: [multipathtcp] Towards a Multipath TCP Proxy work item
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: Tue, 15 Nov 2016 10:12:51 -0000

We see a need to solve UDP in several places, so having a separate specification can help this moving forward.


From: multipathtcp [] On Behalf Of
Sent: den 15 november 2016 09:57
Subject: Re: [multipathtcp] Towards a Multipath TCP Proxy work item

Hi Markus, all,

I’m on the same page that non-tcp traffic should be considered in scope. At least, the UDP case should be investigated. I remember there was interest in BA meeting about the UDP part (

An option I see is to consider advancing the use of MPTCP to convey UDP flows in a separate EXPERIMENTAL specification that will be cross-reviewed with other WGs (intarea, tsvwg). Having that base specification will help having interoperable implementations that will be used to carry experimentations.

Those experiments will help to determine whether the proposed solution is complex/simple, viable/non-viable, failed/successful, etc.

Let’s give it a try.


De : multipathtcp [] De la part de<>
Envoyé : mardi 15 novembre 2016 08:58
À :<>;<>
Cc :<>
Objet : Re: [multipathtcp] Towards a Multipath TCP Proxy work item


If you feel it would take too long and to be too complex to achieve in a reasonable timeframe, we are ok with excluding non-tcp traffic, however, for our total solution we do requires also non-tcp traffic to be sent over multiple paths. We could argue that we can use a different mechanisms specifically for UDP and other protocols, but it would be nice to have as single MPTCP-based solution. (my gut feeling is that we would need to replicate a lot of MPTCP scheduling features into a new mechanism).


Von: multipathtcp <<>> im Auftrag von "<>" <<>>
Datum: Montag, 14. November 2016 um 07:32
An: "<>" <<>>
Cc: "<>" <<>>
Betreff: Re: [multipathtcp] Towards a Multipath TCP Proxy work item

i think we should move beyond "exploring whether it would be useful".

i'd like us to assess proposed solutions. i think we should say this is what we're doing - at the moment we've had quite a lot of discussion about one proposal. we should give the chance for other proposals, and make the discussion more structured (what are the assessment criteria).

i also think we should explicitly exclude non-tcp traffic  (i think non-tcp traffic is too big a topic for our WG)


From: Alan Ford <<>>
Sent: 14 November 2016 06:11
To: Eardley,PL,Philip,TUB8 R
Subject: Re: [multipathtcp] Towards a Multipath TCP Proxy work item

I think this work item is achievable by simply removing references to “at least one end” from the existing charter item on the proxy. So the item would now read:

Finally, the working group will explore whether an MPTCP-aware
middlebox would be useful. For example, potentially helping MPTCP’s
incremental deployment by allowing only one end host to be MPTCP-enabled
and the middlebox acts as an MPTCP proxy for the other end host, which runs
TCP; and potentially helping some mobility scenarios, where the middle box
acts as an anchor between two MPTCP-enabled hosts. Alternatively, neither
end host could be MPTCP-enabled but a pair of proxies could work together to
bring MPTCP benefits to such connections. The working group will detail what real
problems an MPTCP-enabled middlebox might solve, how it would impact the
Multipath TCP architecture (RFC6182), what proxy approach might be
justified as compared against alternative solutions to the problems, and
the likely feasibility of solving the technical and security issues.

In some ways, the two ended proxy work could even be seen as an extension of the previous operational experience work within this WG.


On 10 Nov 2016, at 19:17,<> wrote:

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

Phil & Yoshi
multipathtcp mailing list<>