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

Rao Shoaib <rao.shoaib@oracle.com> Mon, 01 August 2016 18:42 UTC

Return-Path: <rao.shoaib@oracle.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4870112D56C for <multipathtcp@ietfa.amsl.com>; Mon, 1 Aug 2016 11:42:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.508
X-Spam-Level:
X-Spam-Status: No, score=-5.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aucD75rj1j4u for <multipathtcp@ietfa.amsl.com>; Mon, 1 Aug 2016 11:42:55 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CC8D12D542 for <multipathtcp@ietf.org>; Mon, 1 Aug 2016 11:42:55 -0700 (PDT)
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u71IgseD022506 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Aug 2016 18:42:54 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u71IgsGI020124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Aug 2016 18:42:54 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u71Igrbw003369; Mon, 1 Aug 2016 18:42:54 GMT
Received: from [10.159.157.33] (/10.159.157.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Aug 2016 11:42:53 -0700
To: "Henderickx, Wim (Nokia - BE)" <wim.henderickx@nokia.com>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>
References: <b779dd12f1bb412c96c800eddaaf0247@rew09926dag03b.domain1.systemhost.net> <e2aa6ac517194af4b8c25c07f8e469fb@rew09926dag03b.domain1.systemhost.net> <9cafc779-502e-cc7f-676c-f6659e207c81@uclouvain.be> <3100ff74-0c7d-1815-03a1-aa4cec36d1e4@oracle.com> <3D8D4118-39CA-46A6-BFBD-026376C02058@nokia.com>
From: Rao Shoaib <rao.shoaib@oracle.com>
Message-ID: <811b2c78-0976-6994-d759-8cac5fa58864@oracle.com>
Date: Mon, 01 Aug 2016 11:42:48 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <3D8D4118-39CA-46A6-BFBD-026376C02058@nokia.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Source-IP: aserv0022.oracle.com [141.146.126.234]
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/EBnF61J7QKZtiF7jgQLZAFl9doI>
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Aug 2016 18:42:57 -0000


On 08/01/2016 07:13 AM, Henderickx, Wim (Nokia - BE) wrote:
>
>
>
>
>
>> Why is it necessary to know that the connection has been proxied ?
> WH> Otherwise the concentrator will perform the proxy function although the destination is the application server.
> So assume an E2E MPTCP flow. The UE initiates it and the element with the network assisted MPTCP proxy (Concentrator) receives it. The concentrator should not proxy this flow. It should only act upon MPTCP flow that should be proxied in network assisted mode. This is the reason we need an indication about this
This seems like a deployment issue not a protocol issue. The decision to 
proxy or not proxy should be based on the IP addresses or out of band 
signaling. After all the entity adding the option some how knows to add 
the option.

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.
>>> 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.
>> Since we seem to be only considering TCP, will the protocol field be
>> removed from the draft ?
> WH> this is to be discussed
It has to be or we are allowing protocol encapsulation. In which case we 
need to define the complete mechanism.

Rao
>> Shoaib
>>>
>>>
>>>
>>> Olivier
>>>
>>> _______________________________________________
>>> multipathtcp mailing list
>>> multipathtcp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/multipathtcp
>> _______________________________________________
>> multipathtcp mailing list
>> multipathtcp@ietf.org
>> https://www.ietf.org/mailman/listinfo/multipathtcp