Re: [Banana] Updated Charter

[David Allan I <[e-mail]>]

HI Margaret

An aspect that concerns me for a while is the notion that there will be a single signaling protocol to satisfy a laundry list of requirements. On first blush this seems to suggest a solution is already in the wings that needs the laundry list, or that we will end up with  a bloated superset god protocol. Neither of which is IMO a totally desirable outcome.

Easiest fix for me would be to replace “a signaling protocol” with “mechanisms”.

Cheers
Dave

From: Banana [mailto:[e-mail]] On Behalf Of Margaret Cullen
Sent: Monday, September 25, 2017 12:33 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: [Banana] Updated Charter


No problem, Philip.  I have included the latest text below.  This does not yet include the changes I am currently discussing with Dave Sinicrope.

Margaret


Charter: BANdwidth Aggregation for Network Access WG

The BANdwidth Aggregation for Network Access (BANANA) Working Group is chartered to develop solution(s) to support dynamic path selection on a per-packet basis in networks that have more than one point of attachment to the Internet.

Bandwidth 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:


  *   Higher Per-Flow Bandwidth: Many Internet links available to homes and small offices (DSL, Cable, LTE, Satellite, VPNs, 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.

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

  *   Increased Reliability: When one Internet link goes down, ongoing application flows can be moved to another link, preventing service disruption.

Proposed BANANA solutions use different mechanisms (e.g. tunnels, proxies, etc.) to split and recombine traffic, but at an abstract level, they involve a local (hardware or software) component on the multi-access network, a remote component within the Internet or at the remote end, and mechanisms for those components to find each other, exchange signalling information, and direct traffic to each other.   We refer to the functional components at each end as the Local and Remote “BANANA Boxes”, and we refer to the mechanisms they use to direct traffic to each other as “Bandwidth Aggregation mechanisms”.

[Note:  Despite our use of the term “Boxes”, it should be understood that a “BANANA Box” might be a software component running on a piece of hardware with another primary purpose (e.g. a CPE router).]

The Bandwidth Aggregation solutions developed in this group will work
in true multi-provider scenarios (i.e. they will not depend on all of
the aggregated links being provided by a single Internet access provider
nor by a group of cooperating providers).  Any protocols defined by this
group will be IP-based, link-layer-independent solutions, and they will
be designed to work across NATs and other middle boxes, as needed.

The BANANA WG is chartered to complete the following  work items:

  *   Informally document/discuss BANANA problem statement and usage scenarios in a non-archival document (e.g. Wiki, Google Doc, etc.)

  *   Determine how Local and Remote BANANA Boxes find each other (i.e. describe how BANANA boxes will be provisioned/configured.)

  *   Select or specify a signalling protocol that can be used to send control information between BANANA Boxes, including:

  *   IP Prefixes of access  links

  *   Information about link status and properties (including congestion)

  *   Information needed by the Bandwidth Aggregation mechanism(s) in use

  *   Determining which flows are/are not eligible for Bandwidth Aggregation

  *   Select (and extend, if necessary) a tunneling encapsulation for sending traffic between BANANA Boxes.

When applicable, the BANANA WG will use existing IETF protocols, or extensions to existing IETF protocols, as the basis for the work items listed above.  When an existing protocol is used, the WG deliverable will be a document describing the use of that protocol for Bandwidth Aggregation and/or a set of options or extensions to an existing IETF protocol to make it useful for Bandwidth Aggregation.

The BANANA WG will also work with other IETF WGs (and other SDOs, as requested) that define additional Bandwidth Aggregation mechanisms (if any)  to ensure that the protocols defined by the BANANA WG will meet the needs of those additional mechanisms.

Milestones

  *   Apr 2018 Adopt WG draft for provisioning/configuration mechanism

  *   Apr 2018 Adopt WG draft for signaling protocol

  *   Apr 2018 Adopt WG draft(s) for tunnel encapsulation(s)

  *   Feb 2019 WGLC on provisioning/configuration mechanism

  *   Feb 2019 WGLC on signaling protocol

  *   Feb 2019 WGLC on tunnel encapsulation(s)

  *   Aug 2019 Send provisioning/configuration mechanism to the IESG

  *   Aug 2019 Send signalling protocol to the IESG

  *   Aug 2019 Send tunnel encapsulation(s) to the IESG

On Sep 25, 2017, at 12:37 PM, <[e-mail]<mailto:[e-mail]>> <[e-mail]<mailto:[e-mail]>> wrote:

Margaret,
Please could you post the text on the mailing list, as our firewall blocks google docs
Thanks!
phil

From: Banana [mailto:[e-mail]] On Behalf Of Margaret Cullen
Sent: 22 September 2017 20:19
To: [e-mail]<mailto:[e-mail]>
Subject: [Banana] Updated Charter

I have updated the charter text in an attempt to reflect all of the feedback to date.  You can find the new version here:
https://docs.google.com/document/d/1byOJ_To6eL1ZBxKSYpTafQbngTBiNwxaK7ReIsld9Ek/edit

Thoughts?  Comments?

Do folks think this is ready to send to the IESG?  Or are there other changes that it would make it clearer or better?

Margaret