Re: [Banana] Reaching Consensus on Problem Statement

Hi Margaret,

Thanks for bringing this out!

This is a very clear statement of the problem we are currently facing. The motivations have been well explained. The unique feature about bandwidth aggregation for a single session is addressed so that people will not mistake it for the traditional flow-based load sharing any more.

A minor comment is inserted inline below.

Regards,
Mingui

> -----Original Message-----
> From: Banana [mailto:banana-bounces@ietf.org] On Behalf Of Margaret Cullen
> Sent: Friday, February 03, 2017 12:49 AM
> To: banana@ietf.org
> Subject: [Banana] Reaching Consensus on Problem Statement
> 
> 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.]

Here, it means “home or office CPE, PCs or laptops” are connected to the smart phone while the smart phone is sharing its Internet access (through its data plans, airport Wifis, etc) as an AP. It does not mean the opposite direction that ”home or office CPE, PCs or laptops” are providing Internet access to the smart phone while this smart phone is sharing its Internet access to other possible end devices. Am I correct? I know the first case is a quite ordinary use case when people are traveling.

> 
> (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