Re: [Banana] [ALU] Re: Charter Text w/Milestones

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

Hi Mingui,


> [Mingui] From I observed in the past few (at least 3) years, carriers never became interested in rendering a heavy mobile IP stack to be a BANANA solution. The first thing must be done is how to remove 90% of PMIP’s complicated functionalities that are designed for mobile scenarios only. Subsequently, we still have to design missing functionalities, such as per-packet load distribution and the bypassing feature. You’d better come up with a draft to depict a complete solution before you claim it is usable at all. If you do so, you will soon find out you are repeating the story of GRE tunnel bonding.

This is your argument basis for creating a new working group? So, there is a signaling protocol X which in your mind is bulky and so you will design a new protocol which will be less bulky. The protocol that is in question uses two messages and few options; it has the semantics and the design to support authentication, authorization and support for various features. But, in your mind its bulky and so you will be able to design a much better signaling protocol and with no loss of functional capabilities. Can you give a glimpse of how your new signaling protocol looks like? Can you compare that with the existing protocol?

I presume your new signaling protocol will rely on a standard tunneling protocol like GRE (just as how the above bulky protocol does) and that keeps all the forwarding plane considerations identical. But, magically your new signaling protocol will bea much better protocol and operators will embrace it and device vendors will roll it out in no time. That is your thinking?

Signaling protocol A with tunneling scheme X, vs Signaling protocol B with tunneling scheme X. Is there any feedback from any SDO that enforces your view point that they are looking for IETF to come out with a new protocol?

Industry spent few years on designing these protocols and then there was mass community interest. Now, couple of folks want a new protocol and so we will create a new working group? I really hope there is consensus and mass community interest behind this request and which I am not seeing.


> The first thing must be done is how to remove 90% of PMIP’s complicated functionalities that are designed for mobile scenarios only.

Please qualify this statement. Explain me what are those features that are in your 90% list and which of those features are mandatory to implement features?




Sri


From: Banana <[e-mail]<mailto:[e-mail]>> on behalf of "Zhangmingui (Martin)" <[e-mail]<mailto:[e-mail]>>
Date: Monday, April 3, 2017 at 2:17 PM
To: "Muley, Praveen (Nokia - US/Mountain View)" <[e-mail]<mailto:[e-mail]>>, Margaret Cullen <[e-mail]<mailto:[e-mail]>>
Cc: Mirja Kuehlewind <[e-mail]<mailto:[e-mail]>>, Suresh Krishnan <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Banana] [ALU] Re: Charter Text w/Milestones

Hi Praveen,

> Hi :
>    After attending several meetings , I am still NOT sure if there is clarity of right problem statement to charter a WG.  The issue which I have are following.

> 1. The third party operator offering service of bandwidth aggregation is NOT the case I have so far seen with our customers. That may be use case but is NOT the mainline line use case.  Either the operator offering service is wireline or wireless and is leasing the complementary line from other service provider but the device at home and anchor point of bandwidth aggregation is in control of the operator offering the service.

[Mingui] I know “speedify” is an example tool of bandwidth aggregation that is provided by a third party operator. But why there has to be a third party? Is it more of interest that the operator let the BANANA box talk with a remote BANANA box while these two boxes are produced by different vendors?

> 2. If the above case is something broadband forum is discussing with 3GPP , then we SHOULD first understand what pieces 3GPP will address and what will remain in ietf before we making any assumptions and starting the work.

[Mingui] No, BBF is talking about single-operator Hybrid Access rather than the third party operator problem.

[Mingui] Both tunnel based and MPTCP based BANANA solutions choose IETF from the first day. If there might be any conflict between the two SDOs, we could normally handle them through liaison.

> 3. Generally adding more encapsulations at layer 3 we should consider carefully especially in case of third party offering service as some of the wireless networks already have overhead of carrying huge tunnel overhead plus just for the third party operator the wireless operator is NOT going to change MTU on its S5/S8  and s1-u networks.  Also entropy is another reason why MP-TCP or MP-UDP/ MP-QUIC  might turn out to be better solutions.

[Mingui] We’ve already seen the mass deployment of tunnel based BANANA solution. The issues of MTU, entropy, etc are not challenging issues for tunneling techniques at all.

[Mingui] It’s not healthy to argue MP based solutions are better than tunnel based solutions or vice versa. Both kinds have their own problems to solve.

> 4. I know GRE is one solution which was discussed in BANANA meeting and if we have to develop signaling protocol for the tunnel status, then ietf has already produced one which is PMIP . Why not use it.

[Mingui] From I observed in the past few (at least 3) years, carriers never became interested in rendering a heavy mobile IP stack to be a BANANA solution. The first thing must be done is how to remove 90% of PMIP’s complicated functionalities that are designed for mobile scenarios only. Subsequently, we still have to design missing functionalities, such as per-packet load distribution and the bypassing feature. You’d better come up with a draft to depict a complete solution before you claim it is usable at all. If you do so, you will soon find out you are repeating the story of GRE tunnel bonding.

Thanks,
Mingui

________________________________________
From: Banana [[e-mail]<mailto:[e-mail]>] on behalf of Muley, Praveen (Nokia - US/Mountain View) [[e-mail]<mailto:[e-mail]>]
Sent: Tuesday, April 04, 2017 2:24
To: Margaret Cullen
Cc: Mirja Kuehlewind; Suresh Krishnan; [e-mail]<mailto:[e-mail]>
Subject: Re: [Banana] [ALU] Re:  Charter Text w/Milestones

Hi :
   After attending several meetings , I am still NOT sure if there is clarity of right problem statement to charter a WG.  The issue which I have are following.

1. The third party operator offering service of bandwidth aggregation is NOT the case I have so far seen with our customers. That may be use case but is NOT the mainline line use case.  Either the operator offering service is wireline or wireless and is leasing the complementary line from other service provider but the device at home and anchor point of bandwidth aggregation is in control of the operator offering the service.

2. If the above case is something broadband forum is discussing with 3GPP , then we SHOULD first understand what pieces 3GPP will address and what will remain in ietf before we making any assumptions and starting the work.

3. Generally adding more encapsulations at layer 3 we should consider carefully especially in case of third party offering service as some of the wireless networks already have overhead of carrying huge tunnel overhead plus just for the third party operator the wireless operator is NOT going to change MTU on its S5/S8  and s1-u networks.  Also entropy is another reason why MP-TCP or MP-UDP/ MP-QUIC  might turn out to be better solutions.

4. I know GRE is one solution which was discussed in BANANA meeting and if we have to develop signaling protocol for the tunnel status, then ietf has already produced one which is PMIP . Why not use it.


-Praveen


-----Original Message-----
From: Banana [mailto:[e-mail]] On Behalf Of Margaret Cullen
Sent: Thursday, March 30, 2017 10:56 AM
To: Jordan Melzer <[e-mail]<mailto:[e-mail]>>
Cc: Mirja Kuehlewind <[e-mail]<mailto:[e-mail]>>; Suresh Krishnan <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [ALU] Re: [Banana] Charter Text w/Milestones
Importance: Low

Perhaps it would make sense to write this charter in way that only references what this specific WG will do (choose one encapsulation, define a discovery/config mechanism, define a signaling protocol), and then do a minor re-charter to include adapting the signaling protocol to work with an MPTCP Proxy-based BANANA encapsulation if/when the MPTCP WG is chartered to produce one?  (And the same for any other group that produces one, I guess).

Thoughts?

Margaret


> On Mar 30, 2017, at 12:51 PM, Margaret Cullen <[e-mail]<mailto:[e-mail]>> wrote:
>
>
> The ambiguity may be cleared up if/when we know what is happening in
> MPTCP.  The idea is that the BANANA group will define an encapsulation to tunnel packets between BANANA Boxes.  It is also possible that the MPTCP WG will define a “BANANA Encapsulation” using MPTCP proxies on both ends.  If there is more than one encapsulation, we would still like to have a single signaling protocol to communicate link information and status, as well as any signaling needed by the encapsulations.
>
> Does that make sense?  How do you think I could make that clearer without this charter talking too specifically about what another WG may or may not do?
>
> Margaret
>
>> On Mar 30, 2017, at 12:06 PM, Jordan Melzer <[e-mail]<mailto:[e-mail]>> wrote:
>>
>> Thanks, Margaret.
>>
>> The proposed text sometimes uses singular and sometimes uses plural when referring to encapsulation(s).  I am not sure if the goal is to arrive at one encapsulation or many, and if BANANA will define the negotiation.  If some of the encapsulations don’t fully meet BANANA's goals, will BANANA still allow them to be negotiated?  If the goal is a single encapsulation, is there consensus that a single encapsulation that meets all needs is likely through minor extensions of existing encapsulations?
>>
>>
>> -----Original Message-----
>> From: Banana [mailto:[e-mail]] On Behalf Of Margaret
>> Cullen
>> Sent: March 30, 2017 12:10 PM
>> To: [e-mail]<mailto:[e-mail]>
>> Cc: Mirja Kuehlewind; Suresh Krishnan
>> 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]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/banana
>> _______________________________________________
>> Banana mailing list
>> [e-mail]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/banana
>

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