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

Rao Shoaib <rao.shoaib@oracle.com> Mon, 01 August 2016 19:46 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 34CC512DB6C for <multipathtcp@ietfa.amsl.com>; Mon, 1 Aug 2016 12:46:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.507
X-Spam-Level:
X-Spam-Status: No, score=-5.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 a5smAPFAgJAg for <multipathtcp@ietfa.amsl.com>; Mon, 1 Aug 2016 12:46:16 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 A6C1712DADB for <multipathtcp@ietf.org>; Mon, 1 Aug 2016 12:46:16 -0700 (PDT)
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u71JkFUB003497 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Aug 2016 19:46:15 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u71JkFsP012995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Aug 2016 19:46:15 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 u71JkEKm002219; Mon, 1 Aug 2016 19:46:14 GMT
Received: from [10.159.157.33] (/10.159.157.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Aug 2016 12:46:14 -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> <811b2c78-0976-6994-d759-8cac5fa58864@oracle.com> <0084773F-53E5-41A4-A244-430DAF12322A@nokia.com>
From: Rao Shoaib <rao.shoaib@oracle.com>
Message-ID: <1f67528e-5bc2-5c49-db8f-903b95da0409@oracle.com>
Date: Mon, 1 Aug 2016 12:46:09 -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: <0084773F-53E5-41A4-A244-430DAF12322A@nokia.com>
Content-Type: multipart/alternative; boundary="------------E61E678DB67632846E152663"
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/4AWXoNALDQ0qR2wTBApsWYdb4_M>
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 19:46:18 -0000


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.

Shoaib