Re: [multipathtcp] potential MPTCP proxy charter item

<> Fri, 07 October 2016 07:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9223C129492 for <>; Fri, 7 Oct 2016 00:08:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.595
X-Spam-Status: No, score=-5.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jINu0sdrrzlT for <>; Fri, 7 Oct 2016 00:08:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BEB5F129508 for <>; Fri, 7 Oct 2016 00:08:21 -0700 (PDT)
Received: from (unknown [xx.xx.xx.71]) by (ESMTP service) with ESMTP id CA43EC07BE for <>; Fri, 7 Oct 2016 09:08:19 +0200 (CEST)
Received: from localhost.localdomain (unknown []) by (ESMTP service) with ESMTP id BBB681C0069 for <>; Fri, 7 Oct 2016 09:08:19 +0200 (CEST)
Received: from by with queue id 340265-14 for; Fri, 07 Oct 2016 07:08:19 GMT
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by (ESMTP service) with ESMTP id 99FA61C005D; Fri, 7 Oct 2016 09:08:19 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0319.002; Fri, 7 Oct 2016 09:08:19 +0200
To: "" <>, "" <>
Thread-Topic: potential MPTCP proxy charter item
Thread-Index: AdHxWbUCMvV2F7dASMGmgM35ml/5/QvDnYJg
Date: Fri, 07 Oct 2016 07:08:19 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933008E3DDE0@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008E3DDE0OPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [multipathtcp] potential MPTCP proxy charter 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: Fri, 07 Oct 2016 07:08:23 -0000

Hi Phil,

Please see inline.


De : multipathtcp [] De la part de
Envoyé : lundi 8 août 2016 11:50
À :
Objet : [multipathtcp] potential MPTCP proxy charter item

I had thought a potential charter item could be something on the lines of:

<Experimental Extensions to the MPTCP protocol to enable an MPTCP-aware middlebox to act as an MPTCP proxy for an end host, which runs TCP. One or both end hosts may be MPTCP-unaware, and the MPTCP proxy(s) is (are) not necessarily on the default routing path(s). The working group will also detail, in an Informational document, the use cases /deployment scenarios and the operational considerations.>

[Med] I would like to see the charter includes the following; "The working group will also edit Network-Assisted Multipath provisioning documents. In particular, the WG will specify DHCP options and RADIUS attributes for MPTCP."

However, if I get the discussion right, this is not quite right.
* assume a controlled environment (to avoid a problem where the message reaches the 'wrong' proxy) (IETF usually prefers generally applicable protocols)
* assume some (?additional) 'header swapping' protocol and a new signalling protocol (not an mptcp extension - so probably in INTAREA WG's remit)
[Med] IMHO, it is not odd to document in the mptcp wg how a Network-Assisted MPTCP solution can also be applicable to other protocols (UDP in particular). This work can be done jointly/closely with other WGs. The important point is whether there is enough interest from the mptpcp WG members to work on this.
If the above is roughly right, then I think some extra work is needed before we can get a clear charter item. Can some of the work that isn't mptcp extensions be cleanly separated out? Can you be clear what deployment assumptions are being made (and preferably reduce them, so there is wider applicability). Personally I'd also find it very helpful if the plain/transparent 'merged' draft could try and follow the guidance about protocol models in RFC4101 (personally I found the plain mode doc difficult to understand).