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

"Henderickx, Wim (Nokia - BE)" <> Mon, 01 August 2016 20:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 01F5D12D880 for <>; Mon, 1 Aug 2016 13:44:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T1_kADwsNLZz for <>; Mon, 1 Aug 2016 13:44:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5448E12D98A for <>; Mon, 1 Aug 2016 13:44:46 -0700 (PDT)
Received: from (unknown []) by Websense Email Security Gateway with ESMTPS id 29F728CD5E490; Mon, 1 Aug 2016 20:44:41 +0000 (GMT)
Received: from ( []) by (GMO-o) with ESMTP id u71Kiixn004345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Aug 2016 20:44:44 GMT
Received: from ( []) by (GMO) with ESMTP id u71Kihpd017152 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Aug 2016 22:44:44 +0200
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Mon, 1 Aug 2016 22:44:43 +0200
From: "Henderickx, Wim (Nokia - BE)" <>
To: "" <>, "" <>
Thread-Topic: [multipathtcp] towards a potential work item on two-ended proxy
Thread-Index: AQHR7DWI+H5KVobs2E61DPJLQEiUPQ==
Date: Mon, 1 Aug 2016 20:44:43 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: nl-BE, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: Mon, 01 Aug 2016 20:44:48 -0000

On 01/08/16 17:45, "multipathtcp on behalf of" < on behalf of> wrote:

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

WH> we should not assume the proxy is on the default path since it limits a number of use cases
>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?]
WH> I would think: use cases/deployment scenarios, protocol extensions for the proxy
Interaction with end-host MPTCP should be covered in the use case/deployment scenario
>Incidentally, it may be possible to use some of the text from draft-deng-mptcp-mobile-network-proxy ?

WH> we could use some text but it is mobile centric
>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)? 
>-----Original Message-----
>From: Olivier Bonaventure [] 
>Sent: 27 July 2016 09:43
>To: Eardley,PL,Philip,TUB8 R <>om>;
>Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy
>> 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.
>multipathtcp mailing list