Subject: [Banana] Draft Charter Text

From: Margaret Cullen <[email-masked]>
Date: Wed, 29 Mar 2017 16:39:55 -0500

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?]

---

From: Margaret Cullen <[email-masked]>
Date: Wed, 29 Mar 2017 16:41:55 -0500

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 <[email-masked]> wrote:
> 
> Hi All,
> 
> _______________________________________________
> Banana mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/banana