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

Margaret Cullen <margaretw42@gmail.com> Sat, 04 February 2017 17:50 UTC

Return-Path: <margaretw42@gmail.com>
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 64FCB12947F for <banana@ietfa.amsl.com>; Sat, 4 Feb 2017 09:50:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.55
X-Spam-Level:
X-Spam-Status: No, score=-0.55 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Z6c_U-m97VIM for <banana@ietfa.amsl.com>; Sat, 4 Feb 2017 09:50:21 -0800 (PST)
Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 2F093129449 for <banana@ietf.org>; Sat, 4 Feb 2017 09:50:21 -0800 (PST)
Received: by mail-qt0-x22e.google.com with SMTP id x49so73600705qtc.2 for <banana@ietf.org>; Sat, 04 Feb 2017 09:50:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nBEMp9gEE1T56YhUOMP007UBKfx2QUpZwhkVIOJ0yeg=; b=jtqEDYkZrpo6IoKQWy/wh46znDe45YO3yz0GTP/sHoXHxa17ZSpv/6Njlf5jSrn2Lj EUqVI/GlpSw1v8IP4Nn5V53Yadbo9LUJYw/kaSm6QZQN62HSuN2PWY9xn1zevUeP0T7A qCIf3zzsbT6uJ5K7MPocoSO8S55tOYHTdDcWTGft1ic2PETt3rhwSrYlpfTvFw9u8eBE NWaaIYg3nAdh8bTQn/xp3mGIqwjo9ri0F85qP500bTjxuDzEaFxpS/MAiDpsjB1FaU5w iZGHlfRTm77pkGXZya38UCzFW8pEEdvz2X273Ox9/JrFBOSFF5x4EdTkJnRFSlt5yrpC XFpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nBEMp9gEE1T56YhUOMP007UBKfx2QUpZwhkVIOJ0yeg=; b=aTkFASPK/j0+4eF/s8NhUklpxSm2c8DXORXo1FC3Y6zBoay5BAt20sltne4r6CjYQT OH3kMVhIzgRKf++lRVALjXyHrk89Hxsv2cBFCP7wu0q2HjUQG3uhkbs/f9S6J/VQdCAR qTQTFYIr/ff2f+l53pDZfox6m0GZc5lw7GQBN0SQkP5JqyeRo0UAFyPZawSBcxqDcxKO T7UoLU1LQlvAP6756LFeWTRgaOSOXSPMAunWZhbF3VuhG1P/2umBHqT7JkYwdLzFW+H0 IbyTCmFqNoZftGVQmkWl1XzS8aXZJdH5VnWTdqvU2rle6iRcRamD4gWoSlVsK09KKv0O Lsxw==
X-Gm-Message-State: AMke39mRLAKQtgasSCjtTGQM4/9hKcITD02HCRJczOo62B8/PkVe7jFPmjdLJelHRgKaFQ==
X-Received: by 10.200.53.244 with SMTP id l49mr2553266qtb.285.1486230620327; Sat, 04 Feb 2017 09:50:20 -0800 (PST)
Received: from [172.20.10.8] ([172.58.216.119]) by smtp.gmail.com with ESMTPSA id c19sm28084319qtc.29.2017.02.04.09.50.17 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 04 Feb 2017 09:50:19 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Margaret Cullen <margaretw42@gmail.com>
In-Reply-To: <f5bc7430-45dd-c5a6-d376-9d349d40a373@isi.edu>
Date: Sat, 04 Feb 2017 12:49:31 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <6F657BB7-A556-4428-B3FE-015F7EC92A61@gmail.com>
References: <4552F0907735844E9204A62BBDD325E7A6386E6A@NKGEML515-MBX.china.huawei.com> <C328BFD1-A2B7-4E95-956A-D553A8167922@gmail.com> <f5bc7430-45dd-c5a6-d376-9d349d40a373@isi.edu>
To: Joe Touch <touch@isi.edu>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/banana/BpcnTYABmbZ0vaa85Eo10a-EAU8>
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: Sat, 04 Feb 2017 17:50:22 -0000

Hi Joe,

> On Feb 3, 2017, at 11:46 AM, Joe Touch <touch@isi.edu> wrote:
> So am I to understand that the "problem statement" is:
> 
>   - given two cooperating devices, how to manage a set of bonded links
> between them?

No that is not what we are talking about here.  We are talking about distributing a single flow across non-bonded links, potentially provided by different Internet Service Providers, and recombining that traffic at a convergence point for both paths (whether that is a tunnel endpoint, or a proxy is solution specific) to arrive at the remote destination as it was originally sent by the local end-point.

> Isn't that what routers already do?

No, routers don’t do this.  Routers choose a next hop for each IP packet based on <destination IP address>, <source/dest IP addresses> or <source/dest IP addresses, transport protocol, and protocol source/dest ports>, depending on what type of router you are talking about.  

There are all sorts of devices that are routers AND include other sorts of traffic shaping or loadsharing.  There are even some routers deployed today that can share a single flow across multiple access links, recombining the traffic in a provider network.   However, there is no standard that I am aware of for doing this, so both ends need to be provided by a single vendor.

Margaret