Re: [Banana] Fwd: BANANA BOF Request

[[e-mail]]

I will add it to the related work section and add it to the Considerations document, then.  

Thanks,
Margaret

Sent from my iPhone

> On Oct 1, 2016, at 10:32 AM, Henderickx, Wim (Nokia - BE) <[e-mail]> wrote:
> 
> It is also a solution used in the same ctxt so very relevant and should be discussed as well
>  
> From: "[e-mail]" <[e-mail]>
> Date: Saturday 1 October 2016 at 15:44
> To: "Henderickx, Wim (Nokia - BE)" <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> Subject: Re: [Banana] Fwd: BANANA BOF Request
>  
> Hi Wim,
>  
> It looks like this is a 3GPP-specific solutions, which isn't a problem necessarily, but I wondered if you think this work is in scope for the IETF?  Or if just suggesting it should be referenced as related work?
>  
> In other words, where/how do you suggest I include it in the BOF request?
>  
> Margaret
> 
> Sent from my iPhone
> 
> On Oct 1, 2016, at 1:47 AM, Henderickx, Wim (Nokia - BE) <[e-mail]> wrote:
> 
> You are missing this one
>  
> https://www.ietf.org/staging/draft-muley-bonding-solution-hybrid-access-00.txt
>  
>  
> From: Banana <[e-mail]> on behalf of Margaret Cullen <[e-mail]>
> Date: Saturday 1 October 2016 at 00:52
> To: "[e-mail]" <[e-mail]>
> Subject: [Banana] Fwd: BANANA BOF Request
>  
> Here is the formal BOF Request that was submitted to Suresh this evening.
>  
> Margaret
> 
> 
> 
> Begin forwarded message:
>  
> From: Margaret Cullen <[e-mail]>
> Subject: BANANA BOF Request
> Date: September 30, 2016 at 6:51:45 PM EDT
> To: Suresh Krishnan <[e-mail]>
> Cc: Mirja Kuehlewind <[e-mail]>, Mingui Zhang <[e-mail]>, [e-mail]
>  
> Hi Suresh,
>  
> Here is the formal BOF request.  I have cc:ed Mirja, because I know there has been discussion of where to house the MPTCP solution in the IETF, and I don’t know if a conclusion has been reached.  For the moment, we are offering to host it in the proposed BANANA WG, but if you and Mirja have decided on another home for that work, we would be happy to remove it from the proposal and would still like to propose a BOF to do the Problem Statement, the Considerations Draft and a GRE Tunnel Bonding-based solution.
>  
> Thank you for your consideration!
>  
> Margaret
>  
> ---
>  
> - Name: BANdwidth Aggregation for interNet Access (BANANA)
> 
> - Description: 
> There is an emerging demand for services that provide coordinated Internet Access to a home network or mobile device over multiple links of different types to allow for increased bandwidth utilization, load-balancing and/or higher reliability.  Examples include: combining Broadband (DSP or Cable) and LTE links for  home network connectivity, or combining WiFi and LTE links for mobile devices.  Although this problem space has some commonality with the broader site-multihoming problem, the fact that both links are provided by a single operator makes this particular problem space considerably more tractable, because network solutions can be deployed that involve controlling the flow of traffic from both links. One example of this problem has been detailed by the Broadband Forum in TR-348 (https://www.broadband-forum.org/technical/download/TR-348.pdf), and at least two other SDOs are working to document similar problems.  An attempt has been made to describe this problem in general terms in the BANANA Problem Statement document (draft-zhang-banana-problem).
>  
> Multiple solutions that could apply to this problem space have been documented in Internet Drafts, including:  a MIP-Based Solution (draft-ietf-dmm-mag-multihoming), an MPTCP Proxy-based solution (merged draft forthcoming), and a GRE Tunnel Bonding Solution (draft-zhang-tunnel-bonding).  The MIP-based solution was developed in the DMM WG.  The GRE Tunnel Bonding solution, proposed for publication as an Independent Stream RFC, has been deployed by Deutsche Telecom in a large-scale operational network.  The MPTCP solution, though not yet fully documented, presents a promising, minimal-overhead solution, especially for situations where it is only necessary to share TCP traffic between multiple links.  
>  
> There are significant differences between these proposals, resulting in different technical trade-offs, many of which have been explored in the BANANA Considerations Draft (draft-mrc-banana-considerations).  Because of the complexity of the problem and the differences in operational networks, it is possible that different solutions will prove more effective for different deployments.  So it may be desirable to standardize more than one of these solutions.
>  
> This BOF will propose a WG to develop and publish a Problem Statement and a Considerations document, based on the drafts listed above.  The proposed WG would also work on one or more standards-track solutions.  One of these solutions would be based on the Tunnel Bonding draft (draft-zhang-tunnel-bonding).  The group could also work on an MPTCP-based solution based on a forthcoming merged MPTCP proposal, if the ADs decide that this group is the right place for that work.  
>  
> In addition to working on the above-listed documents, this WG could also serve as a point-of-contact for the Broadband Forum and other SDOs to help them understand how various IETF solutions map to their needs.  We would also work with other Working Groups within the IETF (such as DMM and MPTCP, if applicable) to make sure that their solutions are accurately represented in the Considerations document, and in any communications with other SDOs.
> 
> - Agenda:
> 0) Administrivia (5 mins)
> 1) Problem Statement: (20 mins)
> - Problem statements from other SDOs
> - BANANA Problem Statement Draft
> 2) Brief Overview of Solution Space & Considerations (20 min)
> - BANANA Consideration Draft
> - Tunnel Bonding
> - MPTCP Proxy
> - MIP-Based Approach
> 3) Operational Experience (20 mins)
> - Deutsche Telecom
> - Others?
> 4) Draft Charter (10 mins)
> 5) Open Discussion (30 mins)
> 6) Questions & Next Steps (15 mins)
> 
> - Status: WG Forming (although other options may be discussed)
> 
> - Responsible AD: Suresh Krishnan
> 
> - BoF proponents: Mingui Zhang
> 
> - BoF chairs: TBD 
> 
> - Number of people expected to attend: 100 
> 
> - Length of session (1, 1.5, 2, or 2.5 hours): 2 hours 
> 
> - Conflicts to avoid (whole Areas and/or WGs): Entire INT Area (if possible), INTAREA WG, MPTCP, DMM, TRILL, HOMENET, BABEL, CAPPORT
> 
> - Mailing List: https://www.ietf.org/mailman/listinfo/banana 
> 
> - Draft charter:
> 
> BANdwidth Aggregation for interNet Access (BANANA) WG
>  
> Services that provide coordinated Internet Access to a home network or mobile device over multiple links of different types can be used to provide a better customer experience and lower operator costs by allowing increased bandwidth utilization, load-balancing and/or higher reliability.  
> Examples include: combining Broadband (DSP or Cable) and LTE links for  home network connectivity, or combining WiFi and LTE links for mobile devices.  Although this problem space has some commonality with the broader site-multihoming problem, the fact that both links are provided by a single operator makes this particular problem space considerably more tractable, because network solutions can be deployed that involve controlling the flow of traffic from both links. One example of this problem has been detailed by the Broadband Forum in TR-348 (https://www.broadband-forum.org/technical/download/TR-348.pdf), and at least two other SDOs are working to document similar problems.  
>  
> The BANANA WG is chartered to work on the following work items in this space:
>  
> - A  BANANA Problem Statement document (possibly based on draft-zhang-banana-problem).
>  
> - A Considerations document outlining the technical trade-offs between different solutions to this problem (possibly based on draft-mrc-banana-considerations).  
>  
> - One or more solutions for this space (possibly based on draft-zhang-gre-tunnel-bonding or a merged MPTCP-based approach).  Because there are substantial differences between the solutions proposed in this space, and because the solutions are all network based (so it won’t cause issues for host stack implementations or the Internet if different operators deploy different solutions), it may be desirable to standardize multiple solutions in this space, allowing operators to choose the solution that is best for their deployment situation.
>  
> If possible, the group may harmonize some layers or portions of the specified solutions, such as having similar measurement tools for link quality and performance, or by specifying a common control plane.  It will be up to the WG to decide whether there are any common elements that it makes sense to standardize.
>  
> The BANANA WG also serves as a point-of-contact for the Broadband Forum (and potentially other SDOs) to help them understand how various IETF solutions map to their needs.  The WG also coordinates with other Working Groups within the IETF (such as DMM and MPTCP) to make sure that their solutions are accurately represented in the Considerations document, and in any communications with other SDOs.
>  
> Changes to host stacks or non-network-based solutions are out of scope for this group.
>  
> - Relevant drafts:
>  
> DRAFTS FOR THIS WORK:
> https://datatracker.ietf.org/doc/draft-zhang-banana-problem-statement 
> https://datatracker.ietf.org/doc/draft-mrc-banana-considerations 
> https://datatracker.ietf.org/doc/draft-zhang-gre-tunnel-bonding 
> https://datatracker.ietf.org/doc/draft-boucadair-mptcp-plain-mode
> https://datatracker.ietf.org/doc/draft-peirens-mptcp-transparent
>  
> RELATED WORK:
> https://datatracker.ietf.org/doc/https://tools.ietf.org/html/draft-ietf-dmm-mag-multihoming-02
> https://www.broadband-forum.org/technical/download/TR-348.pdf
>