Subject: [Banana] Charter Text w/Milestones

From: Margaret Cullen <[email-masked]>
Date: Thu, 30 Mar 2017 11:10:24 -0500

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

---

From: Dave Dolson <[email-masked]>
Date: Thu, 30 Mar 2017 16:33:35 +0000

Margaret,
It seems like we should explicitly mention protocols to signal packet loss from receiving BANANA box to sending BANANA box so that senders can learn the performance of each link.
I think this should include both packet loss and ECN marking on each link.

I didn't realize this was in scope until we discussed in the hall.

-Dave

-----Original Message-----
From: Banana [mailto:[email-masked]] On Behalf Of Margaret Cullen
Sent: Thursday, March 30, 2017 11:10 AM
To: [email-masked]
Cc: Mirja Kuehlewind; Suresh Krishnan
Subject: [Banana] Charter Text w/Milestones

Thoughts?  Comments?

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:

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.

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
[email-masked]
https://www.ietf.org/mailman/listinfo/banana

---

From: Margaret Cullen <[email-masked]>
Date: Thu, 30 Mar 2017 11:35:51 -0500

Hi Dave,

> On Mar 30, 2017, at 11:33 AM, Dave Dolson <[email-masked]> wrote:
> 
> Margaret,

Whether these specific things are needed depends on what encapsulation is used.  For instance MPTCP proxies would not need these things, whereas a GRE tunneling protocol would.  I think it is premature to define exactly what will be signaled until we have agreed on what sort of encapsulation we are going to define.

> I didn't realize this was in scope until we discussed in the hall.

I absolutely agree that this will in scope for the signaling protocol if we choose an encapsulation that doesn’t already handle these things.

Margaret

---

From: <[email-masked]>
Date: Thu, 30 Mar 2017 16:52:55 +0000

Thnking about this more, I think a first exercise (ie before a bog /wg) is to think about what a signalling protocol would have to do for the different bonding wolutions. To see what the overlap in signalling requirements is. If the requirements are too disjoint, then a singl eprotocol is not sensible; etc
phil

-----Original Message-----
From: Banana [mailto:[email-masked]] On Behalf Of Margaret Cullen
Sent: 30 March 2017 11:36
To: Dave Dolson <[email-masked]>
Cc: Mirja Kuehlewind <[email-masked]>; Suresh Krishnan <[email-masked]>; [email-masked]
Subject: Re: [Banana] Charter Text w/Milestones

Hi Dave,

Margaret

> 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.
> 
> - Work with other IETF WGs defining BANANA encapsulations  (if any) to 
> ensure that the discovery mechanism and signalling  protocol will meet 
> their needs.
> 
> 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
>

---

From: Dave Dolson <[email-masked]>
Date: Thu, 30 Mar 2017 17:00:00 +0000

Generically then, is this right?
"The working group will define a method for sending BANANA boxes to measure and adapt to changes‎ on the local links to the receiving BANANA boxes. The working group may define a signaling protocol to achieve this."

-Dave

  Original Message
From: Margaret Cullen
Sent: Thursday, March 30, 2017 11:35 AM
To: Dave Dolson
Cc: [email-masked]; Mirja Kuehlewind; Suresh Krishnan
Subject: Re: [Banana] Charter Text w/Milestones

Hi Dave,

Margaret

---

From: Jordan Melzer <[email-masked]>
Date: Thu, 30 Mar 2017 17:06:01 +0000

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:[email-masked]] On Behalf Of Margaret Cullen
Sent: March 30, 2017 12:10 PM
To: [email-masked]
Cc: Mirja Kuehlewind; Suresh Krishnan
Subject: [Banana] Charter Text w/Milestones

Thoughts?  Comments?

Margaret

MILESTONES

---

From: Margaret Cullen <[email-masked]>
Date: Thu, 30 Mar 2017 12:46:05 -0500

There is already a signaling protocol listed in the draft charter text with a bullet point that says “information about link properties and status”.  Whether that would include congestion information would depend on whether the encapsulation in use hands congestion itself, or expects that to be handled via the BANANA signaling mechanism.

It isn’t a good idea, IMO, to be over-specific in the charter.  Once we know what encapsulation(s) we are defining, it will be easier for us to determine the specifics of the signaling protocol.

Margaret

> On Mar 30, 2017, at 12:00 PM, Dave Dolson <[email-masked]> wrote:
>

---

From: Margaret Cullen <[email-masked]>
Date: Thu, 30 Mar 2017 12:51:09 -0500

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 <[email-masked]> wrote:
> 
> Thanks, Margaret.
>

---

From: Margaret Cullen <[email-masked]>
Date: Thu, 30 Mar 2017 12:55:52 -0500

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 <[email-masked]> wrote:
> 
>

---

From: David Allan I <[email-masked]>
Date: Thu, 30 Mar 2017 18:12:45 +0000

HI

I have to admit I have a few problems with this....

First, two items in the interest of full disclosure,

1) I'm focused on the converged operator case where this is likely to be a managed service, and my comments are a result of viewing the problem through that lens. As such, operators already have tools to do a chunk of this (e.g. policy and configuration) which they will simply extend as necessary vs. deploy new protocols.

2) I have a leadership position in Broadband Forum where we have been working this space for some time. We expect to do further work as part of efforts to add fixed access/hybrid access directly to a 5G core. This is to satisfy the aspirations of a number of European carriers of have both wireless and wireline offerings and wish to converge them. This is a project we are initiating in cooperation with 3GPP with deliverables to be complete for release 16(YE 2018), and I would expect this to address a chunk of the wishlist in the charter independently of any BANANA efforts. My reasons for thinking this outlined above, the bootstrapping and configuration I would expect to be achieved by augmenting already specified and deployed tools.

IF this were to go forward I would want to see the necessary functions decomposed, and separate out initial bootstrapping of the service from steady state operation. A toolbox of protocols that could be individually adopted would serve the industry better than a god protocol. That being said, if bootstrapping and initial configuration is taken off the table as not of use to my constituency,  I am highly skeptical that the steady state operation of any of a number of solutions can be genericized to be common to the set of approaches currently on the table... Off the top of my head I would characterize the steady state functions as:
	- routing to an off path proxy <-- property of the individual protocol solution
	- flow control <-- property of the individual protocol solution, e.g. TCP can be dealt with differently than UDP, differently than something like QUIC
	- maintaining ordering guarantees <-- property of the individual protocol solution
	- fault detection <-- COULD be separate OAM, or bundled into the individual solution's flow control, ergo part of the specific solution....

So before progressing, I think more effort needs to be put into demonstrating that there is a common problem to be solved that is any more than configuration of what I believe to be a boutique use case.

I hope this helps
Dave

-----Original Message-----
From: Banana [mailto:[email-masked]] On Behalf Of Margaret Cullen
Sent: Thursday, March 30, 2017 11:10 AM
To: [email-masked]
Cc: Mirja Kuehlewind <[email-masked]>; Suresh Krishnan <[email-masked]>
Subject: [Banana] Charter Text w/Milestones

Thoughts?  Comments?

Margaret

MILESTONES

---

From: Jordan Melzer <[email-masked]>
Date: Thu, 30 Mar 2017 19:24:28 +0000

If MPTCP is any indicator, there are different use cases for multipath.  The top examples I have seen
	1) Path-rich data-center use cases
	2) Smart-phone: LTE+WiFi
	3) Residential / commercial multi-WAN -- the WT-378 hybrid access use case falls into this, but is only part of the category
	4) Multi-LAN: 2.4GHz + 5GHz + powerline / 60 GHz

None of these are boutique use cases.

If BANANA can produce an encapsulation technique that doesn't break higher layer protocols by doing packet retransmission but does rate control, maintains ordering across multiple links, and is reasonably robust to real internet environments (eg NAT, policers), that would be great.  To David's point, support mechanisms can come after, and there may be lots of ways to deliver them.

-----Original Message-----
From: Banana [mailto:[email-masked]] On Behalf Of David Allan I
Sent: March 30, 2017 02:13 PM
To: Margaret Cullen; [email-masked]
Cc: Mirja Kuehlewind; Suresh Krishnan
Subject: Re: [Banana] Charter Text w/Milestones

HI

I hope this helps
Dave

-----Original Message-----
From: Banana [mailto:[email-masked]] On Behalf Of Margaret Cullen
Sent: Thursday, March 30, 2017 11:10 AM
To: [email-masked]
Cc: Mirja Kuehlewind <[email-masked]>; Suresh Krishnan <[email-masked]>
Subject: [Banana] Charter Text w/Milestones

Thoughts?  Comments?

Margaret

MILESTONES

---

From: David Allan I <[email-masked]>
Date: Thu, 30 Mar 2017 19:39:52 +0000

HI Jordan

So I'm a bit confused. I think there are a lot of uses for multipath as well,  but several of the ones you mention are e2e and not BANANA Box scenarios. IMO there is nothing to be solved there.

What am I missing?
Dave

-----Original Message-----
From: Banana [mailto:[email-masked]] On Behalf Of David Allan I
Sent: March 30, 2017 02:13 PM
To: Margaret Cullen; [email-masked]
Cc: Mirja Kuehlewind; Suresh Krishnan
Subject: Re: [Banana] Charter Text w/Milestones

HI

I hope this helps
Dave

-----Original Message-----
From: Banana [mailto:[email-masked]] On Behalf Of Margaret Cullen
Sent: Thursday, March 30, 2017 11:10 AM
To: [email-masked]
Cc: Mirja Kuehlewind <[email-masked]>; Suresh Krishnan <[email-masked]>
Subject: [Banana] Charter Text w/Milestones

Thoughts?  Comments?

Margaret

MILESTONES

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 31 Mar 2017 10:41:49 -0500

Hi David,

one question:

> Am 30.03.2017 um 13:12 schrieb David Allan I <[email-masked]>:
> 

Can you provide more information which tools/protocols are in use? I think one important comment for the charter is that also the signaling protocol can be an extension to an existing protocol or multiple existing protocols if bootstrapping and state control are done by different protocols, if suitable. Especially if those protocols are IETF protocols this is IETF work. But yes, cooperation with 3GPP as well as BBF seems important here. Usually we use our liaisons for this!

---

From: David Allan I <[email-masked]>
Date: Fri, 31 Mar 2017 16:52:23 +0000

Hi Mirja:

This in some ways will probably be an unsatisfactory answer, simply as some of this is work in progress. But I'll see what I can do.

CPE configuration is currently specified in the BBF based on TR-69 with the various data models for services in the home specified in TR-181 which has a lost list of amendments to extend it . We are expecting to carry this forward as part of our cooperation with 3GPP on "5G fixed access" including hybrid access, which will mean a data model for hybrid access is to be defined.  The consensus for the providers interested in Hybrid access is that the 3GPP Gx interface (Diameter based) would be used for at least the policy aspects of the HAG/network side proxy.  IIRC TR-69 today is bootstrapped via a DHCP option and then RPC like calls to a configuration server, and we expect to extend that into the 5G N1 interface procedures for network attachment.

I'm not 100% clear on what is considered to be in the scope of signaling in this discussion. The solutions the BBF has agreements to make normative (at least draft-zhang-gre-tunnel-bonding and mp-tcp) seem to be self contained from the point of view of peer exchanges between the proxies for flow control etc.   The value we are expecting to add is in the form of deployment scenarios, addressing, and policy models.

I hope this helps
Dave

-----Original Message-----
From: Mirja Kuehlewind (IETF) [mailto:[email-masked]] 
Sent: Friday, March 31, 2017 10:42 AM
To: David Allan I <[email-masked]>
Cc: Margaret Cullen <[email-masked]>; [email-masked]; Suresh Krishnan <[email-masked]>
Subject: Re: [Banana] Charter Text w/Milestones

Hi David,