Re: [multipathtcp] towards a potential work item on two-ended proxy

<> Tue, 02 August 2016 06:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0514912B035 for <>; Mon, 1 Aug 2016 23:33:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S7tpKETyZ_aE for <>; Mon, 1 Aug 2016 23:33:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1C14E12B004 for <>; Mon, 1 Aug 2016 23:33:45 -0700 (PDT)
Received: from (unknown [xx.xx.xx.4]) by (ESMTP service) with ESMTP id 2643022C838 for <>; Tue, 2 Aug 2016 08:33:43 +0200 (CEST)
Received: from localhost.localdomain (unknown []) by (ESMTP service) with ESMTP id 1905A2380A0 for <>; Tue, 2 Aug 2016 08:33:43 +0200 (CEST)
Received: from by with queue id 861931-34 for; Tue, 02 Aug 2016 06:33:43 GMT
Received: from Exchangemail-eme2.itn.ftgroup (unknown []) by (ESMTP service) with ESMTP id 0145823809E; Tue, 2 Aug 2016 08:33:43 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM42.corporate.adroot.infra.ftgroup ([fe80::d5fd:9c7d:2ee3:39d9%19]) with mapi id 14.03.0301.000; Tue, 2 Aug 2016 08:33:42 +0200
To: "" <>, "" <>
Thread-Topic: [multipathtcp] towards a potential work item on two-ended proxy
Thread-Index: AdHjZ4nHkoHVP9v7Rwqgdt1DLC/zlgD5RCMAACN7ZwABC2yHYAAdaKBQ
Date: Tue, 02 Aug 2016 06:33:41 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933008DF164A@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2016.8.2.55417
Archived-At: <>
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy
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, 02 Aug 2016 06:33:48 -0000

Hi Phil,

Please see inline.


> -----Message d'origine-----
> De : multipathtcp [] De la part de
> Envoyé : lundi 1 août 2016 17:46
> À :
> Objet : Re: [multipathtcp] towards a potential work item on two-ended
> proxy
> Thanks.
> So, for text for a potential work item, we could say something like "the
> WG assumes that the HAG is not necessarily on the default routing path
> between the end hosts".

[Med] Yes, with some modifications to the wording: 
* Actually, there are many "default" forwarding path*S*; a default forwarding path per network attachment. These default forwarding paths may be completely disjoint. 
* I suggest to avoid using "HAG" term because it is tied to a specific use case while the proxy work is applicable to a variety of use cases. I prefer much more "MPTCP Concentrator" or "Network-Assisted MPTCP Proxy".  

  This then leaves open whether we solve this
> problem in the mptcp-based protocol (as per plain mode) or solve it in the
> underlying layer (eg through a tunnel - transparent mode).
> Do we assume that the other end of the mptcp segment is on the default
> routing path?  I suppose this is the case for the CPE example we usually
> have in mind - but since we want a general protocol, it would be good if
> this end also need not be on the default end-to-end path.

[Med] Another approach for this one is the charter to be silent about it, i.e., we don't assume nor preclude it.       

> It was also suggested to have a second (informational) document.
> As a point of reference, our charter currently says (this is about one-
> ended proxy): << 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.>>
> So a potential work item may say something like:
> The working group will detail the use cases /deployment scenarios, the
> operational considerations and .... [anything else? Interaction with
> endhost-to-endhost MPTCP?]

[Med] I would add protocol extensions to differentiate native MPTCP connections from proxied ones. 

> Incidentally, it may be possible to use some of the text from draft-deng-
> mptcp-mobile-network-proxy ?
> I also note that draft-boucadair-mptcp-plain-mode has a very open-ended
> ipr statement. Do you think it could be made more specific (at some
> point)?

[Med] FWIW, that IPR does not apply to the current version of the plain-mode draft since a step mentioned in the first claim of that patent deposit is not present in the draft.  

> phil
> -----Original Message-----
> From: Olivier Bonaventure []
> Sent: 27 July 2016 09:43
> To: Eardley,PL,Philip,TUB8 R <>;
> Subject: Re: [multipathtcp] towards a potential work item on two-ended
> proxy
> Phil,
> > So far this discussion has made me a bit confused. Let me ask a
> > specific
> > question:-
> >
> > Why do we need both transparent and plain mode? If these are
> > addressing different usage scenarios, please explain them (in a
> > paragraph?)
> The two modes address different deployment scenarios.
> In the transparent mode, the HAG resides on the path to/from the client.
> There are many ways in current networks to ensure that the HAG is on the
> path of the clients that it serves. The transparent mode requires one
> option to distinguish between end-to-end MPTCP connections (directly
> established by the client using an MPTCP stack) and proxied connections.
> During IETF96, the authors of plain-mode and transparent-mode agreed that
> the transparent-mode draft would use an emply plain mode option to
> indicate that a connection has been proxied.
> In the plain-mode, the HAG does not need to be on the path to/from the
> client. The plain-mode option is used to signal the original
> source/destination address of the connection depending on the usage.
> Olivier
> _______________________________________________
> multipathtcp mailing list