[Banana] Draft Charter Text

Margaret Cullen <margaretw42@gmail.com> Wed, 29 March 2017 21:39 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 3BA90129465 for <banana@ietfa.amsl.com>; Wed, 29 Mar 2017 14:39:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 ecn6rLL5vZMA for <banana@ietfa.amsl.com>; Wed, 29 Mar 2017 14:39:57 -0700 (PDT)
Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (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 DCA351250B8 for <banana@ietf.org>; Wed, 29 Mar 2017 14:39:56 -0700 (PDT)
Received: by mail-it0-x243.google.com with SMTP id e75so11298654itd.1 for <banana@ietf.org>; Wed, 29 Mar 2017 14:39:56 -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=Ne9zhsL++hIXUdMqPiIzlUBgdKmXTYshN1vUI+t8pio=; b=DhZ0B/G4iydiPQenQig0CIhibFs+r5V9I/+VPa5LNjUFmzQ8I4d6JBnKuOiv+0NT/1 Emr+LIgK/7wtccBxKhIEEvwhf+FKLeyy6dh5z5p6fOUYiAmSju99KZiL/MURaNExfaNq 20/EQZ80zENoUy4aMf2lV7N9dM7x7uGYDT9CyDIoZdQKTSzJm0u8ncCGK/mniejROEPB PsKZIkuLjN4YtuLBB/AHpjJf5xyZjthr51Unvs65Ep4ZVDxvcwd3Kj9bQiZQZSuNK/oQ CigP3FJgwIb+wafS36mulRmM8nrBeC3+9uIoRYUdMcO7H2Tb0+YgiJ51xviOjCDBNVju mGow==
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=Ne9zhsL++hIXUdMqPiIzlUBgdKmXTYshN1vUI+t8pio=; b=RdUlrLP+hrj91e0OOYhGxDQ3HEfpbNELq+8t/GGDAPDLfy+R1TFwxugM/WtUEEDw1Z scGetTwfYIWRuPA2pT6R7S8GnRgLqQwUAgzMtBAJbeYHji9x/CbZoysmCCpkPXcubEBj NAn6zRB8/FPdQwaiAMM0Exx4xhOy92StQL1IV3F9nM8N+UduMs3GmktrPeAowYbuGa00 PC4QC/t0nww5r0zWlzigkYHMfHaRxMztUyLIC0WPmhiCg5uwjyi6E8qM9qRsSXAa669U GJyfyQkfAUp9eh++3lKZGxpz2RcBi61zAxGEGmwGJgk1oyRzcafGepgLwNJjlQb6tsnl pd7Q==
X-Gm-Message-State: AFeK/H2kAcViJtR6c193JtcE/9bnKx/x/y5fDsZV/N8OXJjyNkS6MZpupfJuQ0D3LS23Ow==
X-Received: by 10.36.112.149 with SMTP id f143mr659933itc.50.1490823596067; Wed, 29 Mar 2017 14:39:56 -0700 (PDT)
Received: from [172.16.37.177] (dtrscolumbus03.d.subnet.rcn.com. [207.229.135.146]) by smtp.gmail.com with ESMTPSA id 189sm289581itx.25.2017.03.29.14.39.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 29 Mar 2017 14:39:55 -0700 (PDT)
From: Margaret Cullen <margaretw42@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 29 Mar 2017 16:39:55 -0500
Message-Id: <AF0E99D5-70E8-4E62-A651-D6F3B334F60C@gmail.com>
Cc: Suresh Krishnan <suresh.krishnan@ericsson.com>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
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/BhHNTww-YhI_gowB6wr4zahhc0Q>
Subject: [Banana] Draft Charter Text
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: Wed, 29 Mar 2017 21:39:58 -0000

Hi All,

Here is my proposed charter text, which we will be discussing tonight from 7pm to 9pm in the Lugano room.  

Am I getting close?  Any feedback on the mailing list, before or after the meeting tonight, would be greatly appreciated!


Margaret

---

The BANdwidth Aggregation for Network Access (BANANA) Working 
Group is chartered to develop one or more solutions [Should we say 
“an IP-Layer, tunnel-based solution", instead, and assume any MPTCP
solution will be done in the MPTCP WG?] to support dynamic path
selection on a per-packet basis in unmanaged (home/small-office)
networks.

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 to home/small-office users:

(1) 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.

(2) 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.

(3) Increased Reliability: When one Internet link goes down, ongoing
application flows can be moved to another link, preventing service
disruption.

The Bandwidth Aggregation solution should work whether the attached
links are provided by a single Internet Service Provider or multiple
Providers.

The solution should include a by-pass mechanism that allows specified
flows to be ignored by the Bandwidth Aggregation mechanism.  This
mechanism should make it possible to bypass any traffic that is using
the same mechanism, and to bypass traffic that is using multipath
transport-layer mechanisms, such as MPTCP.  

The Bandwidth Aggregation mechanism should be as transparent as
possible.  It should not modify traffic en-route (beyond encapsulation
and decapsulation), it should not terminate transport-layer sessions,
and it should continue to work (perhaps on less granular flows) when
transport-layer headers are encrypted.  If a single flow is split
across multiple paths, the Bandwidth Aggregation mechanism should
restore the original packet ordering before the traffic reaches its
final destination.

[Anything else we should say here?  Have I said too much already?]

[Do we want to specifically say that (one of) the solutions will be
based on GRE?  On the Bonding Tunnels solution?  Or leave that 
up to the WG?]