Subject: [Banana] Final(?) BANANA Charter Text

From: Margaret Cullen <[email-masked]>
Date: Tue, 12 Sep 2017 09:40:15 -0400

Hi BANANA Folks,

Based on the meeting in Prague, and the feedback we have received on the BANANA List regarding the charter Google Doc, I have included the current state of the BANANA charter text below.  I believe that all of the issues have been addressed, and that this charter is ready to go to the IESG for review.

We’d like to get this charter to the IESG as soon as possible, in the hope of chartering a WG before the November IETF meeting, so please provide any final feedback you have on this text to the BANANA list no later than next Tuesday, September 19th.  Thank you.  Unless there are any major issues, I will send this charter (with minor tweaks as needed) to the IESG next Tuesday.

The current working version of the charter text also continues to be visible here:  https://docs.google.com/document/d/1byOJ_To6eL1ZBxKSYpTafQbngTBiNwxaK7ReIsld9Ek/edit

Thank you,
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 approaches (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 methods they use to direct traffic to each other as a “BANANA Encapsulations”.  

[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).  Similarly, the use of the term “Encapsulation” does not mean that all BANANA Encapsulations will add an explicit encapsulation header.]

The Bandwidth Aggregation solutions developed in this group will be designed to work in multi-provider scenarios (i.e. they will not depend on all of the aggregated links being provided by a single Internet access provider).

The BANANA WG is chartered to complete the following  work items:
	• Informally document/discuss BANANA 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. define BANANA provisioning/configuration mechanism(s)).
	• 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 BANANA Encapsulations
		• Determining which flows are/are not eligible for BANANA Encapsulation
	• Select (and extend, if necessary) an existing tunneling encapsulation (e.g. GRE)  for sending traffic between BANANA Boxes.

The BANANA WG will consider existing IETF protocols, where applicable, as the basis for the work items listed above.

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

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

---

From: Michael Menth <[email-masked]>
Date: Tue, 12 Sep 2017 16:06:29 +0200

Hi Margaret,

I've read the revised version and find it very clear and reasonable.
Thanks a lot!

Best wishes,

Michael

Am 12.09.2017 um 15:40 schrieb Margaret Cullen:
> _______________________________________________
> Banana mailing list
> [email-masked]
> 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: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:[email-masked]
http://kn.inf.uni-tuebingen.de

---

From: Margaret Cullen <[email-masked]>
Date: Mon, 18 Sep 2017 15:48:19 -0400

If there are people who do support the BANANA charter text, more or less as written, and would like to see us do this work in the IETF, it would be helpful if you could state that support here, along with any constructive suggestions you have for improvements to the text.

Thanks,
Margaret

> On Sep 12, 2017, at 9:40 AM, Margaret Cullen <[email-masked]> wrote:
> 
> 
> Hi BANANA Folks,
>

---

From: "Zhangmingui (Martin)" <[email-masked]>
Date: Tue, 19 Sep 2017 03:47:13 +0000

Hi Margaret,

I have read the charter text and found it clear about the problem and work items. I'd like to support it and would like to contribute to the WG. 

Thanks,
Mingui

> -----Original Message-----
> From: Banana [mailto:[email-masked]] On Behalf Of Michael Menth
> Sent: Tuesday, September 12, 2017 10:06 PM
> To: [email-masked]
> Subject: Re: [Banana] Final(?) BANANA Charter Text
> 
> Hi Margaret,
> 
> > Based on the meeting in Prague, and the feedback we have received on the
> BANANA List regarding the charter Google Doc, I have included the current state
> of the BANANA charter text below.  I believe that all of the issues have been
> addressed, and that this charter is ready to go to the IESG for review.
> >
> > We’d like to get this charter to the IESG as soon as possible, in the hope of
> chartering a WG before the November IETF meeting, so please provide any final
> feedback you have on this text to the BANANA list no later than next Tuesday,
> September 19th.  Thank you.  Unless there are any major issues, I will send this
> charter (with minor tweaks as needed) to the IESG next Tuesday.
> >
> > The current working version of the charter text also continues to be visible here:
> https://docs.google.com/document/d/1byOJ_To6eL1ZBxKSYpTafQbngTBiNwxaK
> 7ReIsld9Ek/edit
> >
> > Thank you,
> > Margaret
> >
> > 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.
> >
> > 	• 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 approaches (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 methods they use to direct
> traffic to each other as a “BANANA Encapsulations”.
> >
> > [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).  Similarly, the use of the term
> “Encapsulation” does not mean that all BANANA Encapsulations will add an
> explicit encapsulation header.]
> >
> > The Bandwidth Aggregation solutions developed in this group will be designed
> to work in multi-provider scenarios (i.e. they will not depend on all of the
> aggregated links being provided by a single Internet access provider).
> >
> > 	• Determine how Local and Remote BANANA Boxes find each other (i.e.
> define BANANA provisioning/configuration mechanism(s)).
> > 	• Select (and extend, if necessary) an existing tunneling encapsulation (e.g.
> GRE)  for sending traffic between BANANA Boxes.
> >
> > The Banana WG will work also with other IETF WGs (and other SDOs, as
> requested) that define additional BANANA Encapsulations (if any)  to ensure
> that the protocols defined by the BANANA WG will meet the needs of those
> additional Encapsulations.
> >
> > Milestones

---

From: chenlihao <[email-masked]>
Date: Wed, 20 Sep 2017 07:01:15 +0000

Hi Margaret,

I have read the charter text and I think the issues have been well addressed. Works here would be worthwhile in my opinion and I'd like to support it.

Lihao

> From: Banana [mailto:[email-masked]] On Behalf Of Margaret Cullen
> Sent: Tuesday, September 19, 2017 3:48 AM
> To: [email-masked]
> If there are people who do support the BANANA charter text, more or less as
> written, and would like to see us do this work in the IETF, it would be helpful if
> you could state that support here, along with any constructive suggestions you
> have for improvements to the text.
> 
> Thanks,
> Margaret
> 
> 
> BANANA List regarding the charter Google Doc, I have included the current
> state of the BANANA charter text below.  I believe that all of the issues have
> been addressed, and that this charter is ready to go to the IESG for review.
> >
> September 19th.  Thank you.  Unless there are any major issues, I will send
> this charter (with minor tweaks as needed) to the IESG next Tuesday.
> >
> https://docs.google.com/document/d/1byOJ_To6eL1ZBxKSYpTafQbngTBiNwxa
> K7ReIsld9Ek/edit
> >
> > Thank you,
> > Margaret
> >
> 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.
> >
> 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.
> 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 methods
> they use to direct traffic to each other as a “BANANA Encapsulations”.
> >
> with another primary purpose (e.g. a CPE router).  Similarly, the use of the
> term “Encapsulation” does not mean that all BANANA Encapsulations will add
> an explicit encapsulation header.]
> >
> > The BANANA WG will consider existing IETF protocols, where applicable, as
> the basis for the work items listed above.
> >

---

From: <[email-masked]>
Date: Wed, 20 Sep 2017 08:42:06 +0000

Hi Margaret,

From my point of view the charter and problem statement are clear. I think the  changes currently under discussion (removing references to GRE and/or changing the wording for reusing existing protocols) help to make the charter more understandable.

best regards

Nic

-----Ursprüngliche Nachricht-----
Von: Banana [mailto:[email-masked]] Im Auftrag von Margaret Cullen
Gesendet: Dienstag, 12. September 2017 15:40
An: [email-masked]
Betreff: [Banana] Final(?) BANANA Charter Text

Hi BANANA Folks,

Thank you,
Margaret

Milestones

---

From: <[email-masked]>
Date: Wed, 20 Sep 2017 08:59:52 +0000

Margaret,
Thanks for the latest version.  I believe there is operator interest in an aggregation solution. 

<< 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.>>
 I don’t understand the significance of the word 'local' - should it be deleted?

<<	• Select (and extend, if necessary) an existing tunneling encapsulation (e.g. GRE)  for sending traffic between BANANA Boxes.>>
Is the mention of GRE now deleted?

What I want to make sure is that the protocols developed in work items 2 & 3 don’t assume or depend on the solution used for work item 4 (the "encapsulation"). Since there's work elsewhere in IETF on MPTCP and other possibilities. 
I'm not sure the current wording is quite right ("additional" encapsulations" may give the wrong impression?).  
maybe some wording on the lines:  
it is assumed that there may be several alternative Banana encapsulation solutions, hence it is the aim of the WG that the protocols developed in work items 2 & 3 can work with different encapsulations / don’t restrict the encapsulation used / or something like this...

I also think that the term "encapsulations" will be confusing in the future when the caveat doesn’t appear in close proximity (ie when your warning "the use of the term “Encapsulation” does not mean that all BANANA Encapsulations will add an explicit encapsulation header" isnt in an adjacent sentence). Sorry, I don’t have alternative wording at this moment. 

Margaret said:
<< I have proposed three changes to the charter to address issues that have been discussed on the list.  They can be found in three separate threads under the following subjects:

- Add mention of NAT/remove GRE
- Problem Statement
- Use of Existing IETF Protocols
For me, the changes improve the charter.

Best wishes,
phil

-----Original Message-----
From: Banana [mailto:[email-masked]] On Behalf Of Margaret Cullen
Sent: 12 September 2017 14:40
To: [email-masked]
Subject: [Banana] Final(?) BANANA Charter Text

Hi BANANA Folks,

Thank you,
Margaret

Milestones

---

From: Margaret Cullen <[email-masked]>
Date: Wed, 20 Sep 2017 16:04:33 -0400

Hi Phil,

> On Sep 20, 2017, at 4:59 AM, <[email-masked]> <[email-masked]> wrote:
> it is assumed that there may be several alternative Banana encapsulation solutions, hence it is the aim of the WG that the protocols developed in work items 2 & 3 can work with different encapsulations / don’t restrict the encapsulation used / or something like this…

This is a good point.  I think there is general agreement about this, which is _why_ we split the signaling protocol off from the “encapsulations”, but it probably would make sense to make this more explicit.  I will try to come up with full wording for a proposed change and request feedback on it in another thread.
> I also think that the term "encapsulations" will be confusing in the future when the caveat doesn’t appear in close proximity (ie when your warning "the use of the term “Encapsulation” does not mea…

I think we would all like a better word for “encapsulations”, but it is not clear what that word would be.  For a while, we were saying “transports”, but then the tunnel-based approaches didn’t fit in.  I am not sure what better wording would be, either…

> For me, the changes improve the charter.

Thanks for the feedback!

Margaret