Re: [Banana] Proposed Charter for BANANA WG

[Florin Baboescu <[e-mail]>]

Hi Margaret/Suresh,

I guess that I happen to be one of the dissenters in this case, so please
let me explain my reasons of dissent here.

First of all, I happen to be one of the co-authors an IETF draft for which I
believe BANANA may be a good fit, once we actually have a clear
understanding what this group goals are supposed to be.
Unfortunately, at this stage, this is unclear, at least in my view.

Furthermore, the current discussions seems to be very much a "deja-vu" of
how things happened in another organization, in which a couple of companies
succeeded to propose a solution, to a problem that has not been fully
identified/defined, use cases have never been properly identified, etc. More
unfortunate is that in the end,  many companies wasted 3-4 years of
standardization time, and the final result is that:
1.  No one deploys it, and
2. Major terminal vendors do not want to implement it due to major hardware
architectural impacts in the devices;
3. Other potential solutions, that could have been better options, and how
can one compare one solution vs another once you do not have clear
evaluation criteria. And, how can you have clear evaluation criteria without
clear requirements, use cases, etc.

Going now a little bit on the technical details, although as I indicated
earlier I resent doing this without proper requirements and use cases. You
state that " Bandwidth Aggregation consists of splitting local traffic
across multiple Internet access links on a per-packet basis, including the
ability to split a single flow across multiple links when necessary."
Are you very sure that this is needed? What is the bottleneck that you are
trying to address? The over the air connectivity (cellular, WiFi) or the
backhaul capacity?
If you are addressing the over the air connectivity, an .ac pipe to an end
user is by one-two order of magnitude different that an LTE pipe. Why do you
want to do link aggregation in this case? If I can give an analogy, it is
like you are trying to use a straw to re-direct the water when your toilet
is flooding. If your cellular connectivity is improved to higher data rate
to make it comparable with the over the air capacity of the WiFi
connectivity, why do you need the aggregation in the first place?  And I can
continue.

What I want to point out is that per-packet load balancing comes at a very
high cost on the end nodes from both an architectural point of view(high
memory bandwidth between different components, large memory buffer
requirements, which in the end also translate into high power consumption)
as well as from a pure functional view (large re-order buffer, large jitter)
Accepting a solution that proposes per-packet load balancing need to be very
clearly justified as there are other options almost as good as per-packet
load balancing, without the burdens that the former one introduce.

This is why, I reiterate my original position " that the problem statement
is not clear. From this point of view, I would like to suggest the group to
meet and spend time in coming up with an agreeable problem statement. ".

Thank you.
-Florin



-----Original Message-----
From: Banana [mailto:[e-mail]] On Behalf Of Margaret Cullen
Sent: Monday, October 2, 2017 2:34 PM
To: Suresh Krishnan <[e-mail]>
Cc: [e-mail]
Subject: [Banana] Proposed Charter for BANANA WG

[Resending to Suresh’s actual address]

Hi Suresh,

I think we have reached the point where there are no more constructive
comments on the proposed BANANA charter, so I have included the final text
below for your consideration.

There continue to be a small group of people who do not think that this work
is necessary, or who don’t think it should be chartered in the IETF for
various reasons.  Discussions with those people are not moving towards
agreement, so we will have to leave it up to you to decide if we have
sufficient interest and support to charter this work in the IETF.

Please let us know whether you are willing to bring this charter to the IESG
and IAB for consideration.

Thanks,
Margaret

Proposed Charter:  BANdwidth Aggregation for Network Access WG

The BANdwidth Aggregation for Network Access (BANANA) Working Group is
chartered to specify protocols and mechanisms to support dynamic path
selection on a per-packet basis in networks that have more than one point of
attachment to the Internet.  The protocols and mechanisms produced by this
WG will be designed to work in situations where Internet access is provided
by more than one Internet Service Provider, and without cooperation between
a set of Internet Service Providers (i.e. they will be Over-The-Top (OTT)
mechanisms).

Bandwidth Aggregation consists of splitting local traffic across multiple
Internet access 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 Bandwidth Aggregation mechanisms with
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 mechanism 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 Bandwidth Aggregation mechanisms use different techniques (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
multiple-access network, a remote component within the Internet or at the
remote end, and ways for those components to find each other, exchange
control information, and direct packets to each other.   We refer to the
functional components at each end as the Local and Remote “BANANA Boxes”,
and we refer to the ways they direct traffic to each other as “Bandwidth
Aggregation mechanisms”.

[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).]

The Bandwidth Aggregation mechanism(s) developed in the BANANA working group
will be designed to work in scenarios where Internet access links from
multiple, independent Internet access providers are being aggregated  (i.e.
where the aggregated Internet access links are not provided by a single
Internet access provider, nor by a set of cooperating providers).  Any
protocols defined by this working group will be IP-based,
link-layer-independent solutions, and they will be designed to work across
NATs and other middle boxes, as needed.

The BANANA WG is chartered to complete the following  work items:
	• Informally document/discuss a BANANA problem statement and usage
scenarios in a non-archival document (e.g. Wiki, etc.)
	• Determine how Local and Remote BANANA Boxes find each other (i.e.
describe how BANANA boxes will be provisioned/configured).
	• Select or specify protocol(s) 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 the Bandwidth Aggregation mechanism(s) in use
	• Determining which flows are/are not eligible for Bandwidth Aggregation
	• Select (and extend, if necessary) a tunnel-based method for sending
traffic between BANANA Boxes (i.e. specify a tunnel-based Bandwidth
Aggregation mechanism).

When applicable, the BANANA WG will use existing IETF protocols, or
extensions to existing IETF protocols, as the basis for the work items
listed above.  When an existing protocol is used, the WG deliverable will be
a document describing the use of that protocol for Bandwidth Aggregation
and/or a set of options or extensions to an existing IETF protocol to make
it useful for Bandwidth Aggregation.

The BANANA WG will work with other IETF WGs that define "Bandwidth
Aggregation mechanisms" (as defined above), to ensure that protocols
selected or specified by the BANANA WG for provisioning and the exchange of
control information will work for those Bandwidth Aggregation mechanisms.
The BANANA WG will also work with other SDO(s) that are defining Bandwidth
Aggregation solutions (e.g. Broadband Forum TR-378) to ensure that there are
no conflicts between our work, and to ensure that there are no negative
consequences for users when multiple Bandwidth Aggregation technologies are
available in a single environment.

Milestones
	• Apr 2018 Adopt WG draft on provisioning/configuration protocol(s)
	• Apr 2018 Adopt WG draft  on protocol(s) to send control information
	• Apr 2018 Adopt WG draft on tunnel-based BA mechanism(s)
	• Feb 2019 WGLC on provisioning/configuration protocol(s)
	• Feb 2019 WGLC on protocol(s) to send control information
	• Feb 2019 WGLC on tunnel-based BA mechanism(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




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

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