IETF Logo Mail Archive

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

Joe Touch <touch@isi.edu> Sat, 04 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 6E14A12965F for <banana@ietfa.amsl.com>; Sat, 4 Feb 2017 09:54:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.001
X-Spam-Level:
X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 gyLKSUpYHBLl for <banana@ietfa.amsl.com>; Sat, 4 Feb 2017 09:54:53 -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 3A80112949A for <banana@ietf.org>; Sat, 4 Feb 2017 09:54:53 -0800 (PST)
Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v14HsFvt005441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 4 Feb 2017 09:54:16 -0800 (PST)
To: Mingui Zhang <zhangmingui@huawei.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>
From: Joe Touch <touch@isi.edu>
Message-ID: <9c6339a0-be7a-5b26-acc8-b8b13108eeca@isi.edu>
Date: Sat, 04 Feb 2017 09:54:15 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <4552F0907735844E9204A62BBDD325E7A63A1D7D@NKGEML515-MBX.china.huawei.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
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/QY984IgYrLfntrbZxjWAU-poUGI>
Cc: Margaret Cullen <margaretw42@gmail.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: Sat, 04 Feb 2017 17:54:54 -0000


On 2/4/2017 12:51 AM, Mingui Zhang wrote:
> Hi Joe,
>
> But channel bonding is not applicable to heterogeneous links (wired & wireless).
That doesn't seem like that's new - that's ECMP (where you are defining
the "cost" of the links as equivalent, even when they aren't identical).

>  It's not applicable to tunnels which are built up on multi-hop paths either. 
A tunnel is a link, when implemented properly. There should never be a
difference.

(e.g., the multihop part is exactly equivalent to multiple L2 hops)

> So, according to my understanding the goal is to sequence incoming packets and distribute them onto multiple paths (heterogeneous yet multi-hops) in a per-packet manner and then restore their order according to their sequence number. 
Sure - getting that right is an issue of picking the right algorithm,
but again that seems like an IRTF issue at this point (unless you're
just identifying an existing ECMP algorithm, at which point BANANA
should specify "no new algs").

Joe

v2.23.0 | Report a Bug | By Email