[Banana] Charter Text w/Milestones

Margaret Cullen <margaretw42@gmail.com> Thu, 30 March 2017 16:10 UTC

Return-Path: <margaretw42@gmail.com>
X-Original-To: banana@ietfa.amsl.com
Delivered-To: banana@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2E91294C7 for <banana@ietfa.amsl.com>; Thu, 30 Mar 2017 09:10:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0636qysEIEl1 for <banana@ietfa.amsl.com>; Thu, 30 Mar 2017 09:10:29 -0700 (PDT)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88317129613 for <banana@ietf.org>; Thu, 30 Mar 2017 09:10:26 -0700 (PDT)
Received: by mail-io0-x22d.google.com with SMTP id z13so22407987iof.2 for <banana@ietf.org>; Thu, 30 Mar 2017 09:10:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:subject:date:message-id:cc:to :mime-version; bh=W34vtDwa1WI//sg9ObtUrJZb2iV6vrPff0k8aeyw+M8=; b=QSXxe42qeNc36NCpo0J1X0VeilqW9yOIvrXrtfdZPEXaFzvFJn9fXPVDfZZOIXrSrS dc/SvKAl9BMOrpzQP/1772bUtCWLL0MHMLMSYB8xlV/qzswwC0l9bbGcOh3IOkrxoCSl 7bWuwNI68GnBWfPn2uqnl5egfzCaRo1Cf4036BKW5cfx2rijswheJ+UR1eYyua/5zTJb 3IDSyfdqnkvPsORVJlWBC8+kiPeTn8RDdnMm5XYibEcPFg4gqdpiLwfTkOa2cKFObCre qcxkQ6paB7/iYjWKB1XgPj+QYjPQ40VYP17lGOXPFQ2BHIJTozJGiXMwUuQav1TmgX18 0CdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:subject:date :message-id:cc:to:mime-version; bh=W34vtDwa1WI//sg9ObtUrJZb2iV6vrPff0k8aeyw+M8=; b=CGG6/S9PpbLv9TJtlL4PGLEoy3KpF97/vboLmtUTAMlASZiIS/I2SUzpjGaN0V1EIC +26/31HSq0iAL44xifRLMPQYhWRg+gwd0ojiAFQazcwZ1dD5sq1hxvvdOFmQEeSod8au BBQz1NuCNkXFZzZlNkzG/iDFV1+z6q6AINix0EmxSoGXgR7LeF3Dr+3vAXJYC5/4NQfE m2nZSvxHckMW0hE50cL4q/xaW4/BVlr52DZCBBzZAmwOsUc1s17z9/Y4sTGA2RIAFZo6 PnfWcHeHVb08hekY3xjmX1pj96W1BBAQ5tmjyocPSNLkSJwdjy9Uk74iKczLeGlHBo4s cF0Q==
X-Gm-Message-State: AFeK/H2aZvAtLYl0qYQXi+Z8oSejwkZhKAyXoPLCZRjBRdkm2xdgnoERfGUxrWMYgFAzsQ==
X-Received: by 10.107.46.198 with SMTP id u67mr1457669iou.8.1490890225846; Thu, 30 Mar 2017 09:10:25 -0700 (PDT)
Received: from [172.16.37.177] (dtrscolumbus03.d.subnet.rcn.com. [207.229.135.146]) by smtp.gmail.com with ESMTPSA id r10sm1538483iod.33.2017.03.30.09.10.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 30 Mar 2017 09:10:25 -0700 (PDT)
From: Margaret Cullen <margaretw42@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 30 Mar 2017 11:10:24 -0500
Message-Id: <96A7BC33-FB64-487A-A60D-7AB8504C9DDF@gmail.com>
Cc: Suresh Krishnan <suresh.krishnan@ericsson.com>, Mirja Kuehlewind <ietf@kuehlewind.net>
To: banana@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/banana/_7RJCjOsFSzyQlCfiFglZtCHaNk>
Subject: [Banana] Charter Text w/Milestones
X-BeenThere: banana@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Bandwidth Aggregation for interNet Access: Discussion of bandwidth aggregation solutions based on IETF technologies." <banana.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/banana>, <mailto:banana-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/banana/>
List-Post: <mailto:banana@ietf.org>
List-Help: <mailto:banana-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/banana>, <mailto:banana-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Mar 2017 16:10:31 -0000

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