Re: [Banana] Charter Text w/Milestones

[Jordan Melzer <[e-mail]>]

I would like to see the group develop a path bonding mechanism that works for arbitrary collections of links (like MPTCP) and allows arbitrary protocols to run across them (unlike MPTCP).  I believe this implies flow control but not retransmission.  There may be some other considerations -- eg packet size, perhaps some policy concerns around what link gets used first / by what.  There are a number of uses for arbitrary link bonding, some of which would apply only to a network segment but not the endpoints and others which would involve one or both endpoints.  If it's possible to make a protocol that could be used in any of these ways that would be great.

Like every other group doing a multipath something, I think this group should briefly put together requirements and then define a solution that meets them.  Where BANANA is different from some of the others is that it would be building a general multi-path solution.  If you feel there already is one or a potential to do one without creating any new messages, say so -- certainly an informational RFC explaining how to do something with existing tools is easier to do than making a new protocol.  If not, it does sound possible to build -- some of the current solutions are very close -- feel free to suggest a method.

Though I am not sure that this is the group consensus, I believe the reason there is a new group for this is that no other protocol / group has nailed any path collection, any protocol multipathing.  If we're able to agree on what that really is and another IETF group can solve it -- great.  We knock off early for beers. 

Jordan

-----Original Message-----
From: Banana [mailto:[e-mail]] On Behalf Of Sri Gundavelli (sgundave)
Sent: April 4, 2017 02:56 PM
To: David Allan I; Margaret Cullen; [e-mail]
Cc: Mirja Kuehlewind; Suresh Krishnan
Subject: Re: [Banana] Charter Text w/Milestones

> 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

_______________________________________________
Banana mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/banana