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

"Henderickx, Wim (Nokia - BE)" <> Tue, 02 August 2016 04:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E81F412D146 for <>; Mon, 1 Aug 2016 21:08:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 J2kleycF6qTz for <>; Mon, 1 Aug 2016 21:08:13 -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 D369212B05E for <>; Mon, 1 Aug 2016 21:08:12 -0700 (PDT)
Received: from (unknown []) by Websense Email Security Gateway with ESMTPS id D4D0726F66815; Tue, 2 Aug 2016 04:08:09 +0000 (GMT)
Received: from ( []) by (GMO-o) with ESMTP id u72489Ti023521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Aug 2016 04:08:09 GMT
Received: from ( []) by (GMO) with ESMTP id u72487HF022849 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Aug 2016 06:08:09 +0200
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Tue, 2 Aug 2016 06:08:09 +0200
From: "Henderickx, Wim (Nokia - BE)" <>
To: Yoshifumi Nishida <>
Thread-Topic: [multipathtcp] towards a potential work item on two-ended proxy
Thread-Index: AQHR6/78+H5KVobs2E61DPJLQEiUPaA07KeAgAAiTYA=
Date: Tue, 2 Aug 2016 04:08:08 +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: multipart/alternative; boundary="_000_129D917FD4D14363AF149152A63E6B8Anokiacom_"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
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 04:08:15 -0000

From: Yoshifumi Nishida <<>>
Date: Tuesday 2 August 2016 at 06:05
To: Wim Henderickx <<>>
Cc: Rao Shoaib <<>>, "<>" <<>>
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy


On Mon, Aug 1, 2016 at 1:40 PM, Henderickx, Wim (Nokia - BE) <<>> wrote:

From: Rao Shoaib <<>>
Date: Monday 1 August 2016 at 21:46
To: Wim Henderickx <<>>, "<>" <<>>
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy

On 08/01/2016 12:05 PM, Henderickx, Wim (Nokia - BE) wrote:

I liked the initial proposal as it did not require any changes to the
>protocol. These change (as I have said before) seem very deployment
>specific and IMHO should not be part of the protocol.

WH> I would disagree since you don’t always control the addressing and it is better to have an explicit signaling in the protocol what to expect to happen.

Can you kindly provide an example of another standard IETF protocol that has this feature or something similar.

WH> I am not sure how relevant this is but you can find them in SIP e.g. Let have the discussion on th requirements. We already indicated that the usage of SOCKS is too chatty which is an OOB mechanism we propose. In the scenario’s we have in mind it is better to do this in-band in the protocol to avoid the extra latency.

I personally think this could be a trade-off discussion point.
A question would be if we want to update mptcp to carry non-mptcp-related (upper layer) info into the mptcp option in order to reduce latency for specific use cases.

Or, we just use mptcp as it is and accept the latency. SOCKS might be too chatty for this purpose, but I am thinking it will not be an only option.

WH> we are discussing it. If there is a clear advantage of extending this in the protocol I don’t see why we shouldn’t agree to such solution of embedding it in the protocol.