[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?]
- [Banana] Draft Charter Text Margaret Cullen
- Re: [Banana] Draft Charter Text Margaret Cullen