Re: [Banana] Charter Text w/Milestones

["Sri Gundavelli (sgundave)" <[e-mail]>]

> So before progressing, I think more effort needs to be put into
>demonstrating that there is a common problem to be solved that is any
>more than configuration of what I believe to be a boutique use case.

Agree with Dave. I am not understanding what this group intends to
develop. I am all for bringing new features/addressing gaps in protocol
specific groups such as MPTCP/DMM ..etc.



Sri



On 3/30/17, 11:12 AM, "Banana on behalf of David Allan I"
<[e-mail] on behalf of [e-mail]> wrote:

>HI
>
>I have to admit I have a few problems with this....
>
>First, two items in the interest of full disclosure,
>
>1) I'm focused on the converged operator case where this is likely to be
>a managed service, and my comments are a result of viewing the problem
>through that lens. As such, operators already have tools to do a chunk of
>this (e.g. policy and configuration) which they will simply extend as
>necessary vs. deploy new protocols.
>
>2) I have a leadership position in Broadband Forum where we have been
>working this space for some time. We expect to do further work as part of
>efforts to add fixed access/hybrid access directly to a 5G core. This is
>to satisfy the aspirations of a number of European carriers of have both
>wireless and wireline offerings and wish to converge them. This is a
>project we are initiating in cooperation with 3GPP with deliverables to
>be complete for release 16(YE 2018), and I would expect this to address a
>chunk of the wishlist in the charter independently of any BANANA efforts.
>My reasons for thinking this outlined above, the bootstrapping and
>configuration I would expect to be achieved by augmenting already
>specified and deployed tools.
>
>IF this were to go forward I would want to see the necessary functions
>decomposed, and separate out initial bootstrapping of the service from
>steady state operation. A toolbox of protocols that could be individually
>adopted would serve the industry better than a god protocol. That being
>said, if bootstrapping and initial configuration is taken off the table
>as not of use to my constituency,  I am highly skeptical that the steady
>state operation of any of a number of solutions can be genericized to be
>common to the set of approaches currently on the table... Off the top of
>my head I would characterize the steady state functions as:
>	- routing to an off path proxy <-- property of the individual protocol
>solution
>	- flow control <-- property of the individual protocol solution, e.g.
>TCP can be dealt with differently than UDP, differently than something
>like QUIC
>	- maintaining ordering guarantees <-- property of the individual
>protocol solution
>	- fault detection <-- COULD be separate OAM, or bundled into the
>individual solution's flow control, ergo part of the specific solution....
>
>So before progressing, I think more effort needs to be put into
>demonstrating that there is a common problem to be solved that is any
>more than configuration of what I believe to be a boutique use case.
>
>I hope this helps
>Dave
>
>
>
>-----Original Message-----
>From: Banana [mailto:[e-mail]] On Behalf Of Margaret Cullen
>Sent: Thursday, March 30, 2017 11:10 AM
>To: [e-mail]
>Cc: Mirja Kuehlewind <[e-mail]>; Suresh Krishnan
><[e-mail]>
>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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/banana
>_______________________________________________
>Banana mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/banana