Re: [Banana] Charter

[Florin Baboescu <[e-mail]>]

Dear all,

Sorry for stepping late into this conversation . As I'm following both this
group and BBF as well as few other groups in 3GPP, I  can only agree with
David's comments below.
The obvious point is 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. We should  at least make sure
this does not overlap with the BBF work.
This is why I simply do not see the need of rushing into chartering this
group without a clear understanding of what the group is trying to address.
Thank you.
-Florin Baboescu



-----Original Message-----
From: Banana [mailto:[e-mail]] On Behalf Of David Sinicrope
Sent: Wednesday, September 20, 2017 2:25 PM
To: David Allan I; Margaret Cullen; Sri Gundavelli (sgundave)
Cc: Alexandre Petrescu; Muley, Praveen (Nokia - US/Mountain View);
Henderickx, Wim (Nokia - BE/Antwerp); [e-mail]
Subject: Re: [Banana] Charter

Hi All,

>From the initial discussions of this work a concern was raised (with the
authors, ADs, and IAB) that BANANA proposed work overlapping with the Hybrid
Access work in the Broadband Forum (BBF) (See TR-348, and WT-378) which
deals with both fixed and mobile provider (not solely single provider)
multiple access.

There was accommodation of the point of view that it could be useful to
explore the multi provider, over the top cases, but the pursuit of any work
that would compete with or be considered to overlap the BBF Hybrid Access
project, which was well underway at the time BANANA started, would
potentially jeopardize IETF's relations with the BBF and was therefore
discouraged.

Subsequent to the concerns noted above, the BBF has embarked on a project in
cooperation with 3GPP to converge fixed access and the 5G core which would
include hybrid access scenarios and fixed wireless access.  BBF and 3GPP
currently have work underway and are looking to produce documents in the
3GPP Rel 16 timeframe.

Over the course of the BANANA charter creation this positioning (i.e.,
BANANA = multi provider, OTT, not in conflict with the BBF) seems to have
been increasingly diluted, resulting in the existing charter which, as noted
below, gives license to deal with the entire space and seemingly casts aside
the previous scope positioning and concerns.  In doing so, the charter has
BANANA overlapping the work of the BBF creating a potentially adversarial
situation, and jeopardizing what is otherwise a cordial and productive
working relationship between BBF and the IETF.

I would suggest:
- clearly address the remaining substantive concerns about the clarity of
the problem, scope and requirements, etc.
- Explicitly scope the work to deal with only the multi provider, over the
top environment.  This clearly shows it is out of scope for BBF.
- liaise the charter and milestones/work plan to the BBF asking for their
input - given the subtle differences in the work and plans, even with the
non-overlapping scope, it would greatly help relations to ask before
completing the charter process.

Best Regards,
Dave Sinicrope
BBF/IETF Liaison Manager


On 9/18/17, 2:06 AM, "Banana on behalf of David Allan I"
<[e-mail] on behalf of [e-mail]> wrote:

    I have to admit, my original expectation of the outcome of the
discussions was what the focus would be on configuration of the end points
for a non-carrier-integrated OTT scenario.

    What I am reading in the charter is license to explore the whole space,
and invent additional solutions even in the presence of suitable work by
other WGs....

    Dave



    -----Original Message-----
    From: Banana [mailto:[e-mail]] On Behalf Of Margaret
Cullen
    Sent: Friday, September 15, 2017 12:03 AM
    To: Sri Gundavelli (sgundave) <[e-mail]>
    Cc: Alexandre Petrescu <[e-mail]>; Muley, Praveen
(Nokia - US/Mountain View) <[e-mail]>; Henderickx, Wim
(Nokia - BE/Antwerp) <[e-mail]>; [e-mail]
    Subject: Re: [Banana] Charter


    Hi Sri,

    > I have the same comment. It is not clear to me either on what exactly
    > this WG intends to do. In the BOF (WG-forming) meeting, there was no
    > opportunity given to raise any questions on the problem statement.
    > The entire focus of the meeting was on some charter text without any
    > discussions on 1.) problem statement, 2.) currently known art, 3.)
    > efforts in other WG groups,4.) the gaps.  There was no agreement on
    > IETF 98 BOF meeting (non-WG forming) either on the problem statement.

    Actually, the non-WG forming BOF was held at IETF-97, and it is true
that we did not yet have agreement on a clear and well-understood problem
statement at that time. We didn’t hold a BOF at IETF-98.  Instead, about 30
of us met for a publicly-scheduled "Bar BOF" and discussed the problem
statement and possible charter text. There was also _considerable_
discussion of the problem statement on the mailing list between IETF-97 and
IETF-99, and we reached general agreement on our problem statement on the
mailing list.

    At IETF-99, we reviewed the charter text, which included our agreed
problem statement as the first few paragraphs.  To wit:

    "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.

    Bandwidth 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, 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 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.”

    We went through the charter text, sentence by sentence, at the BOF and
the only change we made to the problem statement portion of the charter was
to add VPNs to the list of low bandwidth Internet links.  There was an
opportunity to discuss every sentence in this section, but people didn’t
have much to say about it, probably because we had already spent months
discussing it on the list and in a Bar BOF.

    During the question period at the end of the BOF, we asked whether the
problem was clear and well-understood.  The large majority of  the people
who responded said “yes”.  This was recorded in the minutes as a “decent
 hum” for yes, and a “low murmur” for no.

    > So, I do not
    > understand why we are jumping on charter text discussion without clear
    > agreements on the problem statement.

    Based on the agreement on the mailing list and in the room in Prague, I
would say that we _do_ have agreement on a clear and understandable problem
statement.  What makes you think we don’t?

    > I really hope IESG will review all the notes/discussions carefully.

    I am sure that Suresh can be trusted to review things carefully before
he puts our charter on the IESG agenda.  If there are any particular notes
or discussion that you would like him to review, please feel free to draw
his attention to them.

    Margaret


    _______________________________________________
    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