Re: [Banana] Charter Text w/Milestones

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

> Where BANANA is different from some of the others is that it would be
>building a general multi-path solution.
 

This goal of realizing a, "general multi-path solution” will end up
creating a new signaling protocol with identical capabilities that the
existing protocol does. Duplicating all the capabilities, gateway
discovery, authentication, path connectivity tests, multi path signaling,
flow policy negotiation … all and every semantic that is present in
existing protocols will be required. Just that there will be new name for
the protocol called “BANANA”, which gives a false illusion that it is
specific to tunnel bonding and so it will be better and it will take 4 to
5 years ti complete that work. For all practical purposes, the signaling
semantics will be identical, only the messaging formats will be different.
You call it “Banana”, I call it “Mobile IP”. but it looks the same, does
the same thing and you need all the capabilities.

FWIW, Mobile IP was defined with the goal to keep it access agnostic and
has support for anchor discovery and signaling for multi path
establishment. it is not clear why that protocol cannot be used here and
why there is a need for a new protocol? More importantly, which SDO is
asking for it and why? The bar for new signaling protocol standardization
should be very high.

Now, with respect to data plane, or more specifically on how to split
traffic between two peers and in the presence of multiple overlay tunnel
paths, there are many deployments and existing vendor solutions that has
addressed this issue. Mobile IP, PMIP, Multilink PPP, MPTPCP have support
for flow distribution to large part. But, if there is a specific gap, say,
we need an informational spec on how the tunnel peers have to behave when
splitting a IP flow across multiple tunnel paths ..some specific
considerations etc, that can be done in that specific working group.  If
the extension required is for TCP based protocol, it can be done in MPTCP
WG; if the extension is for overlay tunnel based paths, DMM WG can address
that. INT area WG can also publish information specs on such matters,
exactly how there is UDP encap being defined for GRE. I am failing to
understand why a new working group is needed.


Sri












On 4/4/17, 1:05 PM, "Jordan Melzer" <[e-mail]> wrote:

>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