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

Margaret Cullen <margaretw42@gmail.com> Sat, 04 February 2017 18:27 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 9375A129C0F for <banana@ietfa.amsl.com>; Sat, 4 Feb 2017 10:27:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zFK0SeougZLl for <banana@ietfa.amsl.com>; Sat, 4 Feb 2017 10:27:57 -0800 (PST)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 49DD2129C0A for <banana@ietf.org>; Sat, 4 Feb 2017 10:27:57 -0800 (PST)
Received: by mail-qt0-x22f.google.com with SMTP id w20so69442223qtb.1 for <banana@ietf.org>; Sat, 04 Feb 2017 10:27:57 -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=yTAN81o9hcnCxx7KdC4ZvxWlSPGEIpF7vJ2N9hI3PM8=; b=SoeRmRuEyLjdbHUIIujlaETQEMjqvidqZSu2pTO+Ex4lgAG3ldvADt7fbf2XyWH5rJ FRziwh32TjZO+Ji8Us6AIGo1k5AbtLDe+mMwes5+bZYH1GFMcNq5zL4GiM5iTI8Iev7n 8agj2geLoryg1JuQGwjL5eeftT/pZZPU3x2qxLo/xm4o/wBjs+31+BswG2vaVD4wjsdc 1xyH2HnPaFPPOCg6eWL221ToBuQxqLRF5mnTjNHwitJdUGLslaPoYPDgW72M6dDxEWHS p5FKDvJfv+/34y//XAbTgLMh9SmXvCY8JRToIuvERoo4AgBswaCxCSZ4RhraHkri4gbD k0DQ==
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=yTAN81o9hcnCxx7KdC4ZvxWlSPGEIpF7vJ2N9hI3PM8=; b=AIhZ27AwhtFThPYmImawmFOfLeMq5Q9MSRthGbfyWz6T250/axIxGROcphnPldVP0o +TBxxpg4icauAU790yEuhlV4Vlv6j4b5BQEO+fSHQT8BcHQ6FgEYQ6rqViTUocJEBrst ACxhIPBvpg3V1gW6BUoANmXzpRl6CNosgdtolYEiAEaEsRGGyXthFVI4gBF39/yrcBr8 YXFZPod3q4R375sNS6OFPWlkxyNurffP+iyPAVWPcGh9fLyC56qQUuyct97K259OW5IP itJUU91JkFnMkJO3B9/zJ2s3kYaA//Kei3ZjGchHe/3T325/j1OsGAmdlwXortyYFPUa xcrA==
X-Gm-Message-State: AMke39lqwAPpkgIVJ5GKg7qhO71TOitJM36xaee923j9E6BX0ldCjhH2XDINMT2l11yL5Q==
X-Received: by 10.237.63.122 with SMTP id q55mr2724676qtf.201.1486232876454; Sat, 04 Feb 2017 10:27:56 -0800 (PST)
Received: from ?IPv6:2607:fb90:682b:13b6:cc9:144e:7870:10e9? ([2607:fb90:682b:13b6:cc9:144e:7870:10e9]) by smtp.gmail.com with ESMTPSA id 140sm28110234qkj.19.2017.02.04.10.27.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 04 Feb 2017 10:27:55 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Margaret Cullen <margaretw42@gmail.com>
In-Reply-To: <956518A5-6371-4959-BBB8-1C4B9604DA0D@gmail.com>
Date: Sat, 04 Feb 2017 13:27:53 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <E5EB799F-F922-4AB3-A77D-E8EFF1866A2E@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>
To: Joe Touch <touch@isi.edu>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/banana/R_DxY7lxVdzA2V_I0vDyv5NOPU4>
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 18:27:58 -0000

> On Feb 4, 2017, at 1:21 PM, Margaret Cullen <margaretw42@gmail.com> wrote:
> 
> Personally, I would consider algorithms that run within a single box to decide whether to aggregate a particular flow...

Actually, there might be a couple of exceptions to my statement that this could be implementation-specific.

We might want to specifically state how "BANANA Boxes" would detect a BANANA flow and avoid aggregating it again.  We might also want to define how they should detect some other flows that already have multi-path capability, like end-to-end MPTCP and exempt those flows from BANANA processing. 

But, I think the performance/reliability-related decisions about whether to split a given flow (that is not specifically called out in the standard) across multiple available access networks should be implementation-specific.

Does that makes sense?

Margaret