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

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Tue, 02 August 2016 04:05 UTC

Return-Path: <nishida@sfc.wide.ad.jp>
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 6BFB912D11A for <multipathtcp@ietfa.amsl.com>; Mon, 1 Aug 2016 21:05:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level:
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 TEXWoiOrmDj2 for <multipathtcp@ietfa.amsl.com>; Mon, 1 Aug 2016 21:05:26 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35B4212B05E for <multipathtcp@ietf.org>; Mon, 1 Aug 2016 21:05:25 -0700 (PDT)
Received: from mail-ua0-f180.google.com (mail-ua0-f180.google.com [209.85.217.180]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 87C03278696 for <multipathtcp@ietf.org>; Tue, 2 Aug 2016 13:05:23 +0900 (JST)
Received: by mail-ua0-f180.google.com with SMTP id j59so120415968uaj.3 for <multipathtcp@ietf.org>; Mon, 01 Aug 2016 21:05:23 -0700 (PDT)
X-Gm-Message-State: AEkoouscglNPSuU/a7P5cYDSEotEX9Int2lX5oDnhJI7tNzSzSX8edJRE6JPqc8mIZb+WMMHsRijBYe0sb4/Ig==
X-Received: by 10.159.34.23 with SMTP id 23mr29272978uad.21.1470110722042; Mon, 01 Aug 2016 21:05:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.4.164 with HTTP; Mon, 1 Aug 2016 21:05:21 -0700 (PDT)
In-Reply-To: <9A3D1498-3EC9-4E80-8731-730999F8739C@nokia.com>
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> <1f67528e-5bc2-5c49-db8f-903b95da0409@oracle.com> <9A3D1498-3EC9-4E80-8731-730999F8739C@nokia.com>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Mon, 01 Aug 2016 21:05:21 -0700
X-Gmail-Original-Message-ID: <CAO249ycj4Fy7zEG9b3WWUi6AEKk3O7UE2F_7bLeOOQeh6xfGBg@mail.gmail.com>
Message-ID: <CAO249ycj4Fy7zEG9b3WWUi6AEKk3O7UE2F_7bLeOOQeh6xfGBg@mail.gmail.com>
To: "Henderickx, Wim (Nokia - BE)" <wim.henderickx@nokia.com>
Content-Type: multipart/alternative; boundary="001a113cba385e34e905390ed3f5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/zXdeo6yF2A7l9VWTeZcghUZtWsc>
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
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: Tue, 02 Aug 2016 04:05:28 -0000

Hello,

On Mon, Aug 1, 2016 at 1:40 PM, Henderickx, Wim (Nokia - BE) <
wim.henderickx@nokia.com> wrote:

>
>
> From: Rao Shoaib <rao.shoaib@oracle.com>
> Date: Monday 1 August 2016 at 21:46
> To: Wim Henderickx <wim.henderickx@nokia.com>, "multipathtcp@ietf.org" <
> multipathtcp@ietf.org>
> 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.

Thanks,
--
Yoshi