Re: [Banana] Reaching Consensus on Problem Statement

[Mirja Kühlewind <[e-mail]>]

Hi Margaret,

thanks for starting this discussion. Here are some personal thoughts:

> Am 02.02.2017 um 17:48 schrieb Margaret Cullen <[e-mail]>:
> 
> 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”.
> 
This is related to point 4 and combining both is the interesting problem from my point of view. If you have multiple flows and multiple interfaces, it's rather easy to simply route/schedule different flows over different links (a la ECMP). The problem comes up if you have a service with one flow that needs more capacity than a single link can provide. The example we’ve been working on is HD video streaming in rural areas where the DSL is limited but LTE is provided and sparely used. In this case you need re-oder buffers and additional signaling between the tunnel endpoints.

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

This is not fully clear to me. I don’t think it's important who owns the link (I mean if you buy connectivity from one provider you can just use it); it’s important who owns the proxies. And the ingress proxy can only be own by one party (because it’s one box) however that box can simply use connectivity from different providers. I don’t see a problem there. The more interesting case is if the ingress and the egress proxy are not owned by the same party because this is the case where a proprietary protocol to exchange information between those two boxes would not work anymore. 

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

I don’t think this is that important. I believe failover will likely be cover implicitly and if not it might be a completely different problem (than bandwidth aggregation).

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

See above.

Also having an agreement for the problem is of course the first step. Howeve,r my understanding from the BoF was that there are already quite a bunch of people working on different solutions. So what’s really needed is agreement on the solution (and if there is one for all or different things or multiple solutions  are needed). Only if there is a first proposal for one (or more?) protocol(s) that this group would work on, it makes sense to think about chartering.

Mirja


> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/banana