[Banana] BANANA BOF in Prague?
Margaret Cullen <margaretw42@gmail.com> Tue, 23 May 2017 00:11 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 2D040129462 for <banana@ietfa.amsl.com>; Mon, 22 May 2017 17:11:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 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, URIBL_BLOCKED=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 or6V5wbGz1T7 for <banana@ietfa.amsl.com>; Mon, 22 May 2017 17:11:31 -0700 (PDT)
Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 8BC32128D3E for <banana@ietf.org>; Mon, 22 May 2017 17:11:31 -0700 (PDT)
Received: by mail-qt0-x229.google.com with SMTP id t26so115167849qtg.0 for <banana@ietf.org>; Mon, 22 May 2017 17:11:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=vY3mZENAWSh8hI5nTGm/Rta2WMUBdzwRxzWgACwEiDg=; b=GlIlV3rQH2jkZLNzi/1XFghxoW9Im6vWMT1NQnggZbWUExT5jYqjLQxXX0LEFbtTLk W9ShvxLWx2iXCjq62G+yZGloqDK5xNMyxL+3dlKXqSxF5t923bb3rG29YgXwOjMBH9fh tPdkpteHRlLXZyLTLKzk1oNXZQ2fYXfKMsfLONEQJ9o1T9wshqt5xin3flYZ8qWMXJmV kUsIVcAPTGb7mQEkO1w6wLCx9gsplO0LTHjGyRJw6w5IcNXsWh0GH15JHelkrN9Sn+e/ sjWCiHo46JObKZL4O/p9Q1STFiMisPFomp4/SBODfBgGEOB0zjYfMVzQZOnorY+2N73i Burw==
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 :message-id:date:to:mime-version; bh=vY3mZENAWSh8hI5nTGm/Rta2WMUBdzwRxzWgACwEiDg=; b=onWY1Z2SdwcFYiagHbVmwB/qPvo+V11H5+neuTiuVpAc87SBZAXnRiR9XcM4c2tU8B fICYXLYkeT989sB2gbCzkuGLfkwrWTDDFAFiZOfRsHcgLPgNT4ffI2udqAaWsUz8s8Nb NOZbgGFgiwQsGJnpdkxg4/UJup3rsjtoWKUzJjhtDQE2Rs/jCT92OLog4buY4k4LkPPb fV3dTCdED2/ToXID+Xdd3lkKNcXD1TLnYGALPmP30RJ/EYZVNi+A/wFc563eV8oqc+hQ NfW2oBx5J9NmHdMeJ1J/zn5rSRY7QOAHZSWrd8PaLNT1mMLmjZmS06MQ069nqtzjFg0e QmDw==
X-Gm-Message-State: AODbwcAOf80j+ZzFyZPAwCr+WO3I764Q2riGyiOVoyNeDoK2Rqr9+MlB sdq9DYuygPEeZrO/qng=
X-Received: by 10.200.37.26 with SMTP id 26mr26257874qtm.278.1495498290350; Mon, 22 May 2017 17:11:30 -0700 (PDT)
Received: from ?IPv6:2601:18c:580:21e0:4519:e17:3645:6f3e? ([2601:18c:580:21e0:4519:e17:3645:6f3e]) by smtp.gmail.com with ESMTPSA id x139sm12551959qkb.21.2017.05.22.17.11.29 for <banana@ietf.org> (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 22 May 2017 17:11:29 -0700 (PDT)
From: Margaret Cullen <margaretw42@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <9F593A48-A745-4B6B-A6D1-1509B985B689@gmail.com>
Date: Mon, 22 May 2017 20:11:29 -0400
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/iaAc9iHh8b5x2rNiKOFOZiaiYvQ>
Subject: [Banana] BANANA BOF in Prague?
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: Tue, 23 May 2017 00:11:33 -0000
Just FYI — I have submitted a request for a WG Forming BANANA BOF in Prague with the information included below. This information has also been added to the BOF Wiki. Please let me know if you notice any errors or omissions, or if you have any questions or suggestions. Thanks, Margaret BOF Name: Bandwidth Aggregation for Network Access (BANANA) Description: 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. Agenda - Agenda bash, scribe, minute taker [5min] - Review of proposed charter text (see below) [10 mins] - Charter discussion [45 mins] - Questions: [30 mins] - Is the charter text clear and understandable? - Should the IETF do this work? - Are you willing to contribute (write, review, email, etc.) Status: WG Forming Responsible AD: Suresh Krishnan BoF proponents: Margaret Cullen / Brian Trammel / Mingui Zhang BoF chairs: Margaret Cullen / Brian Trammel 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): Internet area, Homenet, TRILL, MPTCP, QUIC - Mailing List: https://www.ietf.org/mailman/listinfo/banana - Draft charter: see below - Relevant drafts: [[BR]] https://datatracker.ietf.org/doc/draft-leymann-banana-signalling https://datatracker.ietf.org/doc/draft-leymann-banana-data-encap https://datatracker.ietf.org/doc/draft-leymann-banana-integration https://datatracker.ietf.org/doc/draft-leymann-banana-discard-load-rebalance https://datatracker.ietf.org/doc/draft-leymann-banana-discard-timer https://tools.ietf.org/html/draft-kanugovi-intarea-mams-protocol-04 https://tools.ietf.org/html/draft-zhu-intarea-mams-control-protocol-01 Proposed Charter Text and Milestones: 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 Apr 2018 Adopt WG draft for discovery/configuration mechanism Apr 2018 Adopt WG draft for signalling proocol Apr 2018 Adopt WG draft for tunnel encapsulation Feb 2019 WGLC on discovery/configuration mechanism Feb 2019 WGLC on signalling protocol Feb 2019 WGLC on tunnel encapsulation Aug 2019 Send discovery/configuration mechanism to the IESG Aug 2019 Send signalling protocl to the IESG Aug 2019 Send tunnel encapsulation to the IESG
- [Banana] BANANA BOF in Prague? Margaret Cullen
- Re: [Banana] BANANA BOF in Prague? Dave Dolson
- Re: [Banana] BANANA BOF in Prague? Zhangmingui (Martin)
- Re: [Banana] BANANA BOF in Prague? Dave Dolson
- Re: [Banana] BANANA BOF in Prague? Zhangmingui (Martin)
- Re: [Banana] BANANA BOF in Prague? Brian Trammell (IETF)
- Re: [Banana] BANANA BOF in Prague? Zhangmingui (Martin)
- Re: [Banana] BANANA BOF in Prague? Dave Dolson
- Re: [Banana] BANANA BOF in Prague? Brian Trammell (IETF)
- Re: [Banana] BANANA BOF in Prague? Mirja Kühlewind
- Re: [Banana] BANANA BOF in Prague? Zhangmingui (Martin)
- Re: [Banana] BANANA BOF in Prague? Dave Dolson
- Re: [Banana] BANANA BOF in Prague? Margaret Cullen
- Re: [Banana] BANANA BOF in Prague? Dave Dolson
- Re: [Banana] BANANA BOF in Prague? Mirja Kühlewind
- Re: [Banana] BANANA BOF in Prague? Dave Dolson
- Re: [Banana] BANANA BOF in Prague? Mirja Kühlewind
- Re: [Banana] BANANA BOF in Prague? Dave Dolson