Re: [Banana] Reaching Consensus on Problem Statement
Michael Menth <menth@uni-tuebingen.de> Thu, 02 February 2017 18:47 UTC
Return-Path: <menth@uni-tuebingen.de>
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 2154A1294FD for <banana@ietfa.amsl.com>; Thu, 2 Feb 2017 10:47:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.399
X-Spam-Level:
X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] 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 RNkvkRuaUeDn for <banana@ietfa.amsl.com>; Thu, 2 Feb 2017 10:47:09 -0800 (PST)
Received: from mx03.uni-tuebingen.de (mx03.uni-tuebingen.de [134.2.5.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82E5E129473 for <banana@ietf.org>; Thu, 2 Feb 2017 10:47:09 -0800 (PST)
Received: from [192.168.1.100] (hsi-kbw-5-56-219-179.hsi17.kabel-badenwuerttemberg.de [5.56.219.179]) by mx03.uni-tuebingen.de (Postfix) with ESMTPSA id B78A4C52AF for <banana@ietf.org>; Thu, 2 Feb 2017 19:47:07 +0100 (CET)
To: banana@ietf.org
References: <EE162993-F96F-458A-846C-D722EEF7A3B8@gmail.com>
From: Michael Menth <menth@uni-tuebingen.de>
Message-ID: <58938029.4030907@uni-tuebingen.de>
Date: Thu, 02 Feb 2017 19:53:29 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <EE162993-F96F-458A-846C-D722EEF7A3B8@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/banana/_UFg_LCHSSCFSzF6mTjtTqQNpq4>
Subject: Re: [Banana] Reaching Consensus on Problem Statement
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: Thu, 02 Feb 2017 18:47:12 -0000
Dear Margaret, thanks a lot for your initiative! The scope may depend on where the load balancer and recomination point are located. In the network similar to draft-zhang-gre-tunnel-bonding-01.txt (GRE Tunnel Bonding) or MPTCP-Proxy, or on the endpoints like pure MPTCP? Probably focus is on the first, but the text doesn't say so, yet. I can imagine that the load balancing option (per-packet or per-flow) may be minor. Both may be justified for performance reasons depending on networking conditions. Therefore, I wouldn't rule out per-flow load balancing but a priority on per-packet may be reasonable to start with. Regards, Michael Am 02.02.2017 um 17:48 schrieb Margaret Cullen: > At the BANANA BOF in November, we did not seem to have clear consensus on a concise problem statement. So, I’d like to try to reach consensus on a problem statement on this list, in the hopes that we can (finally!) move forward towards work on solutions. To that end, I’ve been working with multiple people over the past few weeks to come up with a concise problem statement for our expanded BANANA effort (as represented at the BOF), and I have determined that the main aspects of the problem we are trying to solve are: > > (1) Unmanaged networks (i.e. homes or small offices) often have more than one point of attachment to the Internet (DSL, Cable, LTE, etc). We call these networks “multi-access networks”. In multi-access networks, it is desirable to utilize the bandwidth of all attached networks to increase performance. We call this “bandwidth aggregation”. > > (2) An unmanaged multi-access network may have multiple links from a single provider (e.g. DSL/LTE, or two LTE links), or multiple links from different providers (e.g. Cable & LTE, or DSL and LTE from different providers). We need a solution that will work in both cases, without requiring cooperation between multiple providers. Therefore, our solution needs to work with existing IP address assignment, ingress filtering, and reverse path routing mechanisms. > > (3) In these environments, the available paths to the Internet may change over time due to changing conditions and/or service outages. It would be desirable for all existing sessions to continue using the remaining link(s) when a link becomes unavailable or unreliable. We call this “failover”. [Note: This is especially true when you consider the possibility that, using this mechanism, people could increase the bandwidth available wherever they are by routinely using their smart phones as Wifi access points accessible to their home or office CPE, PCs or laptops.] > > (4) Homes and small offices tend to have few simultaneous sessions active at any given time, and may often have only one large, relatively long-lived session in use for an online game or media download. Despite the fact that only one session may be active, end-users would still benefit from increased bandwidth and reliability for that single session. It is therefore important to support bandwidth aggregation and failover for a single session (i.e. a single TCP connection or UDP flow). This is a key point that distinguishes the BANANA problem from other flow-based load sharing and site multihoming problems. > > Thoughts? Comments? Do you think this problem statement is clear and understandable? If not, in what way is it unclear? All comments from major rewrites to word-smithing are welcome! > > I’ll wait a week for feedback, then I’ll update this problem statement based on any comments I have received from this list. After that, I will make a formal consensus call on the list, in the hope of confirming that we have consensus, among ourselves at least, regarding the problem we are trying to solve. > > Margaret > > > _______________________________________________ > Banana mailing list > Banana@ietf.org > https://www.ietf.org/mailman/listinfo/banana > -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://kn.inf.uni-tuebingen.de
- [Banana] Reaching Consensus on Problem Statement Margaret Cullen
- Re: [Banana] Reaching Consensus on Problem Statem… Michael Menth
- Re: [Banana] Reaching Consensus on Problem Statem… Mingui Zhang
- Re: [Banana] Reaching Consensus on Problem Statem… Mingui Zhang
- Re: [Banana] Reaching Consensus on Problem Statem… Brian Trammell
- Re: [Banana] Reaching Consensus on Problem Statem… Brian Trammell
- Re: [Banana] Reaching Consensus on Problem Statem… Mirja Kühlewind
- Re: [Banana] Reaching Consensus on Problem Statem… Jim Reid
- Re: [Banana] Reaching Consensus on Problem Statem… Margaret Cullen
- Re: [Banana] Reaching Consensus on Problem Statem… Margaret Cullen
- Re: [Banana] Reaching Consensus on Problem Statem… Margaret Cullen
- Re: [Banana] Reaching Consensus on Problem Statem… Mirja Kühlewind
- Re: [Banana] Reaching Consensus on Problem Statem… Mirja Kühlewind
- Re: [Banana] Reaching Consensus on Problem Statem… Margaret Cullen
- Re: [Banana] Reaching Consensus on Problem Statem… Mingui Zhang
- Re: [Banana] Reaching Consensus on Problem Statem… Michael Menth
- Re: [Banana] Reaching Consensus on Problem Statem… Alan Ford
- Re: [Banana] Reaching Consensus on Problem Statem… Joe Touch
- Re: [Banana] Reaching Consensus on Problem Statem… N.Leymann
- Re: [Banana] Reaching Consensus on Problem Statem… Margaret Cullen
- Re: [Banana] Reaching Consensus on Problem Statem… Martyn Russell