Re: [Banana] Draft Charter Text

[Margaret Cullen <[e-mail]>]

I realized that, in all of my attempts to edit the problem statement based on previous feedback, I left out the part where the home/small-office network has more than one point of attachment to the internet.  Oops.  I will add that back in before tonight.

Margaret


> On Mar 29, 2017, at 4:39 PM, Margaret Cullen <[e-mail]> wrote:
> 
> Hi All,
> 
> Here is my proposed charter text, which we will be discussing tonight from 7pm to 9pm in the Lugano room.  
> 
> Am I getting close?  Any feedback on the mailing list, before or after the meeting tonight, would be greatly appreciated!
> 
> 
> Margaret
> 
> ---
> 
> The BANdwidth Aggregation for Network Access (BANANA) Working 
> Group is chartered to develop one or more solutions [Should we say 
> “an IP-Layer, tunnel-based solution", instead, and assume any MPTCP
> solution will be done in the MPTCP WG?] to support dynamic path
> selection on a per-packet basis in unmanaged (home/small-office)
> networks.
> 
> Bandwith Aggregation consists of splitting local traffic across
> multiple Internet links on a per-packet basis, including the ability
> to split a single flow across multiple links when necessary.
> 
> It is the goal of this WG to produce a Bandwidth Aggregation solution
> that will provide the following benefits to home/small-office users:
> 
> (1) Higher Per-Flow Bandwidth: Many Internet links available to homes
> and small offices (DSL, Cable, LTE, Satellite, etc.) have relatively
> low bandwidth.  Users may wish to run applications (such as streaming
> video, or content up/downloads) that require (or could benefit from)
> more bandwidth for a single traffic flow than is available on any of
> the local links.  A Bandwidth Aggregation solution could supply the
> needed bandwidth by splitting a single traffic flow across multiple
> Internet links.
> 
> (2) Reduced Cost: Traffic sharing on a per-packet basis allows the full
> bandwidth of the lowest-cost link to be used first, only using a 
> higher-cost link when the lowest-cost link is full.
> 
> (3) Increased Reliability: When one Internet link goes down, ongoing
> application flows can be moved to another link, preventing service
> disruption.
> 
> The Bandwidth Aggregation solution should work whether the attached
> links are provided by a single Internet Service Provider or multiple
> Providers.
> 
> The solution should include a by-pass mechanism that allows specified
> flows to be ignored by the Bandwidth Aggregation mechanism.  This
> mechanism should make it possible to bypass any traffic that is using
> the same mechanism, and to bypass traffic that is using multipath
> transport-layer mechanisms, such as MPTCP.  
> 
> The Bandwidth Aggregation mechanism should be as transparent as
> possible.  It should not modify traffic en-route (beyond encapsulation
> and decapsulation), it should not terminate transport-layer sessions,
> and it should continue to work (perhaps on less granular flows) when
> transport-layer headers are encrypted.  If a single flow is split
> across multiple paths, the Bandwidth Aggregation mechanism should
> restore the original packet ordering before the traffic reaches its
> final destination.
> 
> [Anything else we should say here?  Have I said too much already?]
> 
> [Do we want to specifically say that (one of) the solutions will be
> based on GRE?  On the Bonding Tunnels solution?  Or leave that 
> up to the WG?]
> 
> _______________________________________________
> Banana mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/banana