Re: [Banana] BOF Description and Agenda

[Brian Trammell <[e-mail]>]

hi Mingui,

A clarification question and (I think) agreement, below...

> On 08 Dec 2016, at 04:05, Mingui Zhang <[e-mail]> wrote:
> 
> Hi,
> 
> From our discussions, I observe the measurement feedback loop is a very good thing to be standardized. The information about latency, loss rate, connection state, etc. exposed by the feedback could be used (e.g., as the input into the load distribution function at the ingress).

The measurement feedback loop you envision here is sent from the bonding tunnel egress back to the bonding tunnel ingress, correct?

> Flow control and congestion control can fit into this loop. It has been well motivated since users/providers are able to see higher throughput & reliability out of the bandwidth aggregation with this measurement-feedback loop. I would be happy to contribute to it.

This seems reasonable, though I suspect there is some OAM work in the routing area (with which I have only passing familiarity) that could be (re-)used here.

Cheers,

Brian

> Thanks,
> Mingui
> 
>> -----Original Message-----
>> From: Banana [mailto:[e-mail]] On Behalf Of Brian Trammell
>> Sent: Thursday, December 08, 2016 12:57 AM
>> To: [e-mail]
>> Subject: Re: [Banana] BOF Description and Agenda
>> 
>> Hello, Banana!
>> 
>> I've posted draft minutes at
>> https://datatracker.ietf.org/doc/minutes-97-banana/ -- please send
>> corrections/clarifications to the chairs (I suppose [e-mail]
>> works for this?)
>> 
>> Another mail framing the problem statement discussion to follow shortly (for
>> some value of shortly), but there's no need to wait for the chairs to kick off the
>> discussion. :)
>> 
>> Cheers,
>> 
>> Brian
>> 
>>> On 06 Dec 2016, at 16:40, Brian Trammell <[e-mail]> wrote:
>>> 
>>> hi Phil,
>>> 
>>> These are in my queue for completion last Friday (as you can see, I'm running a
>> bit behind), along with kicking off the "next steps" discussion that we identified
>> needs to happen on the list.
>>> 
>>> (In the meantime, those who came up to the microphone in Seoul who
>>> stated interest in solving a problem in this space: please be prepared
>>> draft a paragraph or two on what you think the important parts of the
>>> problem to solve are, to send to the list :) )
>>> 
>>> Cheers,
>>> 
>>> Brian
>>> 
>>>> On 06 Dec 2016, at 16:37, <[e-mail]> <[e-mail]>
>> wrote:
>>>> 
>>>> Is it possible to send the minutes, even if they’re draft, please? Or
>>>> a summary of next steps after the BoF. I wanted to catch up with what
>>>> happened, as unfortunately I didn’t make it to Seoul Thanks phil
>>>> 
>>>> From: Banana [mailto:[e-mail]] On Behalf Of Margaret
>>>> Cullen
>>>> Sent: 02 November 2016 10:59
>>>> To: [e-mail]
>>>> Cc: [e-mail]; Brian Trammell <[e-mail]>;
>>>> Mirja Kühlewind <[e-mail]>; Suresh Krishnan
>>>> <[e-mail]>
>>>> Subject: Re: [Banana] BOF Description and Agenda
>>>> 
>>>> Oh, it might have helped to include the description… :-)
>>>> 
>>>> - Name: BANdwidth Aggregation for interNet Access (BANANA)
>>>> 
>>>> - Description:
>>>> This BOF will discuss how we can take advantage of multiple access links,
>> provided by one or more access providers, in cases where end nodes and
>> applications may not be multi-access-aware.  Use of multiple access links could
>> provide bandwidth aggregation when multiple links are available (i.e. improved
>> performance), and session continuation when a link becomes unavailable (i.e.
>> increased reliability).
>>>> 
>>>> Solutions to this problem are intended to apply to home and small-office
>> networks, so solutions must support load-sharing of a small number of flows (in
>> some cases only one) over multiple paths, recombining the traffic in ways that do
>> not cause problems for the network (i.e. congestion, multi-level retransmission,
>> etc.) or for upper-layer protocols (i.e. packet reordering within flows).  Solutions
>> in this area must allow for some traffic to bypass bandwidth aggregation (e.g. for
>> flows that are mandated to travel a specific path, or for flows that are already
>> using a more end-to-end bandwidth aggregation solution).  Solutions should
>> provide minimal (if any) performance degradation when multiple links are not
>> available, or when one or more of the links is not performing sufficiently to
>> support increased performance to the end nodes.
>>>> 
>>>> This is a Non-WG-forming BOF.  The purposes of the BOF are to discuss the
>> problem space, and determine if there is sufficient interest and energy in the
>> IETF to pursue any work in this area.  If the interest and energy exist, further
>> effort may be exerted to scope and charter an IETF WG.
>>>> 
>>>> There has been an informal group, also called BANANA, looking at a subset of
>> this space:  the case where multiple links are provided by a single Internet
>> access provider/operator.  Multiple solutions that could apply to this subset
>> have been discussed within that group, including:  a MIP-Based Solution
>> (draft-ietf-dmm-mag-multihoming), an MPTCP Proxy-based solution (merged
>> draft forthcoming), a GRE Tunnel Bonding Solution
>> (draft-zhang-gre-tunnel-bonding), and a 3GPP-specific solution
>> (draft-muley-bonding-solution-hybrid-access).  The MIP-based solution was
>> developed in the DMM WG and is proposed for publication as a Standards Track
>> RFC.  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).  Some of the solutions
>> that have been under discussion may apply (with or without additional signaling
>> mechanisms) to the broader problem space where the access links may not be
>> provided by a single operator.  This ongoing work will be discussed during the
>> BOF, as it applies to the more general problem.
>>>> 
>>>> There has also been ongoing work in multiple other standards organizations to
>> describe related problems.   The Broadband Forum has produced a “Hybrid
>> Access” problem statement for DSL/LTE bandwidth aggregation specifically for
>> the case where the DSL and LTE links are provided by a single operator (TR-348).
>> Documents from the other groups are not yet publicly available.
>>>> 
>>>> - Agenda:
>>>> 0) Administrivia (5 mins)
>>>> 1) BOF Scope and Problem Description (Chairs, 10 min)
>>>> 2) BANANA Solution Space & Experiences
>>>>  - GRE Tunnel Bonding
>>>>               - Solution Overview (Mingui Zhang, 5 min)
>>>>               - Deployment Experience (Nicolai Leymann, 5 min)
>>>>  - MPTCP Proxy (??, 10 min)
>>>>  - Others?
>>>> 3) Related Research
>>>>  - Multipath Bonding at Layer 3 (Brian Trammel, 10 min)
>>>> 4) Related Work in Other SDOs
>>>>  - Broadband Forum TR-348 (Dave Allan, 5 mins)
>>>>  - Others?
>>>> 5) Open Discussion (30 mins)
>>>> 6) Questions & Next Steps (Chairs & ADs, 10 mins)
>>>> 
>>>> - Status: Non-WG Forming
>>>> - Responsible AD: Suresh Krishnan <[e-mail]>
>>>> - BoF proponents: Mingui Zhang <[e-mail]>, Nicolai
>>>> Leymann <[e-mail]>, Margaret Cullen
>>>> <[e-mail]>
>>>> - BoF chairs: Brian Trammel <[e-mail]>, Margaret Cullen
>>>> <[e-mail]>
>>>> - Number of people expected to attend: 100
>>>> - Length of session (1, 1.5, 2, or 2.5 hours): 1.5 hours
>>>> - Conflicts to avoid (whole Areas and/or WGs): Entire INT Area,
>>>> Entire TSV area, TSVAREA, INTAREA WG, MPTCP, DMM, TRILL, HOMENET,
>>>> BABEL, CAPPORT
>>>> - Mailing List: https://www.ietf.org/mailman/listinfo/banana
>>>> - Draft charter:  None
>>>> 
>>>> - Relevant drafts/documents:
>>>> 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
>>>> https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-multihoming-02
>>>> https://www.ietf.org/staging/draft-muley-bonding-solution-hybrid-acce
>>>> ss-00.txt https://irtf.org/anrw/2016/anrw16-final21.pdf
>>>> https://www.broadband-forum.org/technical/download/TR-348.pdf
>>>> 
>>>> 
>>>> On Nov 2, 2016, at 6:57 AM, Margaret Cullen <[e-mail]> wrote:
>>>> 
>>>> Hi All,
>>>> 
>>>> Here is the current BOF description and agenda (which will be posted in the
>> next few minutes) for our upcoming BANANA BOF.
>>>> 
>>>> As you can see, there is room in the agenda for someone to do a short
>> presentation on the state of the MPTCP solution(s) that are applicable to this
>> problem space, however a presenter has not been assigned.  We know that
>> Olivier will not be in Seoul.  Will any of the advocates of an MPTCP solution
>> (Med, perhaps?) be in Seoul and willing to present a quick overview?
>>>> 
>>>> Also, please let us know if you have any comments on the description or
>> would like to add anything to the agenda.
>>>> 
>>>> Margaret
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Banana mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/banana
>>> 
>