Re: [Banana] Reaching Consensus on Problem Statement

Hi Margaret, all,

Thanks for picking this up. The problem statement as written below indeed gives a clear high-level overview of the scenario, although one point I’d make is that point 4 appears to me to be simply a corollary to point 1 (i.e. “and this includes aggregating for a single session”).

One observation is that I think it is implied that this requires some kind of device in the network to assist with these scenarios (since otherwise end-to-end MPTCP would solve most of this for stream-based transports), but this is not stated. The problem with this broadness is that who the problem would be solved for could lead to a considerably different solutions (e.g. solving for network providers would potentially lead to different scenarios to hosting providers, which in turn which would be different to those for third-party service providers), and similarly ownership/management of the various enabling devices (CPE, concentrator, etc).

Brian describes this as an “intersection of the problem spaces”, but it was this lack of specificity in the commonality between the presented scenarios which I think led to at least some of the confusion in the BOF. Some of the scenarios presented could be solved with existing technologies with minimal changes, but these may not apply to other scenarios. So is the goal here going to be to try to provide a generic solution? Or one or more solutions more specific to certain problems? Can the problem statement in some way be more focused on a particular scenario or set of scenarios which have commonality (e.g. two constraints could be: the existence of a terminating proxy within the network, and no requirement for manual configuration at the CPE end - both would significantly focus the work; if management commonality could also be established (or defined) that would also focus the solution space).

Regards,
Alan

> On 2 Feb 2017, at 16:48, Margaret Cullen <margaretw42@gmail.com> wrote:
> 
> 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