Re: [Banana] Reaching Consensus on Problem Statement

[Mingui Zhang <[e-mail]>]

Hi Michael, 

> -----Original Message-----
> From: Banana [mailto:[e-mail]] On Behalf Of Michael Menth
> Sent: Friday, February 03, 2017 2:53 AM
> To: [e-mail]
> Subject: Re: [Banana] Reaching Consensus on Problem Statement
> 
> 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.

According to my understanding, the scope might as well be applicable to the network with MPTCP-Proxy. And surely, it does not include the network with pure MPTCP endpoints.

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

But there are solutions for per-flow load sharing already. Think about the widely used and standardized hashing methods. I think it’s non-necessary to mention per-flow load sharing issue in the problem statement. Otherwise, the problem statement would look like encouraging reinventing something.

> 
> Regards,
> 
> Michael


Thanks,
Mingui





> 
> 
> 
> 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
> > [e-mail]
> > 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: [phone]
> fax: [phone]
> mailto:[e-mail]
> http://kn.inf.uni-tuebingen.de
> 
> _______________________________________________
> Banana mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/banana