Re: [Banana] 答复: diff (banana load distribution, next-hop selection of multipath)

Joe Touch <touch@isi.edu> Mon, 13 February 2017 17:54 UTC

Return-Path: <touch@isi.edu>
X-Original-To: banana@ietfa.amsl.com
Delivered-To: banana@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA54912971E for <banana@ietfa.amsl.com>; Mon, 13 Feb 2017 09:54:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 vEkrQ5-RP5e9 for <banana@ietfa.amsl.com>; Mon, 13 Feb 2017 09:54:00 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD28D129547 for <banana@ietf.org>; Mon, 13 Feb 2017 09:53:59 -0800 (PST)
Received: from [128.9.184.84] ([128.9.184.84]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v1DHqOBE014117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 13 Feb 2017 09:52:25 -0800 (PST)
To: "Zuojing (2012 Laboratories)" <jing.zuo@huawei.com>, Margaret Cullen <margaretw42@gmail.com>
References: <4552F0907735844E9204A62BBDD325E7A6386E6A@NKGEML515-MBX.china.huawei.com> <C328BFD1-A2B7-4E95-956A-D553A8167922@gmail.com> <f5bc7430-45dd-c5a6-d376-9d349d40a373@isi.edu> <4552F0907735844E9204A62BBDD325E7A63A1C49@NKGEML515-MBX.china.huawei.com> <99F04B22-01AC-476C-A15A-1696B686A953@isi.edu> <4552F0907735844E9204A62BBDD325E7A63A1D7D@NKGEML515-MBX.china.huawei.com> <9c6339a0-be7a-5b26-acc8-b8b13108eeca@isi.edu> <956518A5-6371-4959-BBB8-1C4B9604DA0D@gmail.com> <E5EB799F-F922-4AB3-A77D-E8EFF1866A2E@gmail.com> <4AD902A48032F745A3D7866E6CAE8CB064BBD1D8@DGGEMM521-MBX.china.huawei.com> <029e994f-e5e8-08a2-6015-eb8dd2d692fb@isi.edu> <4AD902A48032F745A3D7866E6CAE8CB064BBD532@DGGEMM521-MBX.china.huawei.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <5f170803-f4f9-f1d3-41a0-c76ef7d6dd7e@isi.edu>
Date: Mon, 13 Feb 2017 09:52:26 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <4AD902A48032F745A3D7866E6CAE8CB064BBD532@DGGEMM521-MBX.china.huawei.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/banana/PmLd2YTTqmvk-AuO3XG1BU6WkH8>
Cc: Mingui Zhang <zhangmingui@huawei.com>, "banana@ietf.org" <banana@ietf.org>
Subject: Re: [Banana] 答复: diff (banana load distribution, next-hop selection of multipath)
X-BeenThere: banana@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Bandwidth Aggregation for interNet Access: Discussion of bandwidth aggregation solutions based on IETF technologies." <banana.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/banana>, <mailto:banana-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/banana/>
List-Post: <mailto:banana@ietf.org>
List-Help: <mailto:banana-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/banana>, <mailto:banana-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Feb 2017 17:54:02 -0000

First: I agree with Jim that this is out of scope for the charter.

Second: to queue up some observations IF MPTCP handling is part of a
solution (which I remain unconvinced is necessary):


On 2/13/2017 1:23 AM, Zuojing (2012 Laboratories) wrote:
> Hi Joe,
>
> Right. BANANA needs not to distinguish subflows from TCP flows only if Service Providers require BANANA boxes to do such exemption
Which I believe should NOT be required or even suggested...

>  For example, Service Providers may purposely let those flows already being conducted by other multipath technologies be “bypassed”. 
Again, an MPTCP subflow should be treated identically to a TCP flow. If
TCP flows can be split across connections, then so can MPTCP subflows.
There is no reason to treat them differently.

> There is a scenario that comes into my mind: the BANANA box may simultaneously be an MPTCP proxy device.
The MPTCP proxy rules would govern its behavior, not BANANA (IMO).

>  The MPTCP proxy function handles the TCP flow and generates MPTCP subflows. In this case, the generated subflows should not to go through the traffic distribution function of BANANA once again. 
>
> I can imagine another scenario: BANANA is supported by the end device. Assume this end device supports MPTCP.

Again, the MPTCP system needs to be the one to accommodate things, not
BANANA (IMO).

Joe

>  It should exempt its MPTCP subflows from being processed by the traffic distribution function of BANANA.
>
> BR, 
> Jing
>
> -----邮件原件-----
> 发件人: Joe Touch [mailto:touch@isi.edu] 
> 发送时间: 2017年2月11日 1:42
> 收件人: Zuojing (2012 Laboratories); Margaret Cullen
> 抄送: Mingui Zhang; banana@ietf.org
> 主题: Re: [Banana] diff (banana load distribution, next-hop selection of multipath)
>
> Hi, Jing (et al.),
>
>
> On 2/9/2017 6:10 PM, Zuojing (2012 Laboratories) wrote:
>> Dear Margaret and all,
>>
>> It's true that we need to exempt end-to-end MPTCP flows from BANANA processing in case the sub-flows of MPTCP are split by BANANA once again.
> I disagree.
>
> MPTCP flows are no different than a single TCP connection; both assume a single set of "path" properties, and both could be affected by use of multipath.
>
> However, both may need to use multipath to have the resources needed, e.g., to complete a transfer quickly.
>
> AFAICT, both should be treated the same for the purposes of BANANA, and neither one should have a blanket exemption.
>
> Joe