Re: [Banana] Charter Text w/Milestones

Generically then, is this right?
"The working group will define a method for sending BANANA boxes to measure and adapt to changes‎ on the local links to the receiving BANANA boxes. The working group may define a signaling protocol to achieve this."

-Dave

  Original Message
From: Margaret Cullen
Sent: Thursday, March 30, 2017 11:35 AM
To: Dave Dolson
Cc: banana@ietf.org; Mirja Kuehlewind; Suresh Krishnan
Subject: Re: [Banana] Charter Text w/Milestones

Hi Dave,

> On Mar 30, 2017, at 11:33 AM, Dave Dolson <ddolson@sandvine.com> wrote:
>
> Margaret,
> It seems like we should explicitly mention protocols to signal packet loss from receiving BANANA box to sending BANANA box so that senders can learn the performance of each link.
> I think this should include both packet loss and ECN marking on each link.

Whether these specific things are needed depends on what encapsulation is used.  For instance MPTCP proxies would not need these things, whereas a GRE tunneling protocol would.  I think it is premature to define exactly what will be signaled until we have agreed on what sort of encapsulation we are going to define.

>
> I didn't realize this was in scope until we discussed in the hall.

I absolutely agree that this will in scope for the signaling protocol if we choose an encapsulation that doesn’t already handle these things.

Margaret

>
> -Dave
>
>
> -----Original Message-----
> From: Banana [mailto:banana-bounces@ietf.org] On Behalf Of Margaret Cullen
> Sent: Thursday, March 30, 2017 11:10 AM
> To: banana@ietf.org
> Cc: Mirja Kuehlewind; Suresh Krishnan
> Subject: [Banana] Charter Text w/Milestones
>
> Here is the (wordsmithed) charter text from last night.  I have also added milestones.
>
> At this point, the text attempts to be neutral about the subject of whether there will be an MPTCP encapsulation (presumably done in the MPTCP WG) or not.  We might want to update the text based on the outcome of today’s MPTCP meeting if there is any clear conclusion.
>
> Thoughts?  Comments?
>
> Any feedback will be appreciated!
>
> 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.
>
> 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:
>
> - 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.
>
> - 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, and mechanisms for those components to find each other, exchange signalling information, and direct traffic to each other.  We refer to these functional components as the Local and Remote "BANANA Boxes", and we refer to the method they use to direct traffic to each other as a "BANANA Encapsulation".
>
> The Bandwidth Aggregation solutions developed in this group will work whether the attached links are provided by a single Internet Service Provider or multiple Providers.
>
> The BANANA WG will have the following work items:
>
> - Determine how Local and Remote BANANA Boxes find each other.
>
> - Specify a signalling protocol that can be used to send configuration
>  and control information between BANANA boxes, including:
>    -  IP Prefixes of local links
>    -  Information about link properties & status
>    -  Information needed by the encapsulations
>
> - Select (and extend, if necessary) an existing tunneling
>  encapsulation for sending traffic between BANANA Boxes.
>
> - Work with other IETF WGs defining BANANA encapsulations
>  (if any) to ensure that the discovery mechanism and signalling
>  protocol will meet their needs.
>
> BANANA Boxes will determine if a specific flow is eligible for Bandwith Aggregation. If a flow is not eligible, it will not be split across multiple attached links.
>
> For this initial charter, we will focus on how Local BANANA Boxes communicate with Remote BANANA Boxes.  We will not address the topic of cooperation between multiple Local BANANA Boxes.
>
> MILESTONES
> (Assumes WG Chartering by May 2017)
> Dec 2017 Adopt WG draft for discovery/configuration mechanism Dec 2017 Adopt WG draft for signalling proocol Dec 2017 Adopt WG draft for tunnel encapsulation Oct 2018 WGLC on discovery/configuration mechanism Oct 2018 WGLC on signalling protocol Oct 2018 WGLC on tunnel encapsulation Apr 2019 Send discovery/configuration mechanism to the IESG Apr 2019 Send signalling protocl to the IESG Apr 2019 Send tunnel encapsulation to the IESG
>
> _______________________________________________
> Banana mailing list
> Banana@ietf.org
> https://www.ietf.org/mailman/listinfo/banana
> _______________________________________________
> Banana mailing list
> Banana@ietf.org
> https://www.ietf.org/mailman/listinfo/banana