Re: [Banana] BOF Description and Agenda

Margaret Cullen <mrcullen42@gmail.com> Wed, 02 November 2016 10:59 UTC

Return-Path: <mrcullen42@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 C8CA1129566 for <banana@ietfa.amsl.com>; Wed, 2 Nov 2016 03:59:12 -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, HTML_MESSAGE=0.001, 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 4KyCzP5eCrw2 for <banana@ietfa.amsl.com>; Wed, 2 Nov 2016 03:59:10 -0700 (PDT)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 0B142129AD7 for <banana@ietf.org>; Wed, 2 Nov 2016 03:59:10 -0700 (PDT)
Received: by mail-qk0-x229.google.com with SMTP id q130so13131698qke.1 for <banana@ietf.org>; Wed, 02 Nov 2016 03:59:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=IPXlYjOzECNEfuU9hfNLuNYRnTeA5alqrBbSVVVF8MY=; b=P7+hEZPIRa3C5gDl6VP8/eOnIP5JWGB8zvY/H760Q+SCgFVOqG877eM8mnaem9iCb+ 6Vj/PAjXBn0sFuAkeaKBVdLRiivf7CCRItfQ3bTfo0vjTse6zB+lZet2VttilPIeCpxR a+peSG1MwibXa/fyHlS0SzBIkEA945hz1g8m15zkJ5GK4zwiUs453T+B5xTFvqkq6Y50 AwkKOAYbofD8mVxppD3ZghowUmtUiM3xvNbQL4P49bRwYpnk76LJen9LY/acCUyPeRYu 1junGh/zFldtEUiYkbI+yggfjIrskkvZ/B3aN4eLIZUEgOrRVUvk75RZvVD6ah1lUMsq EhDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=IPXlYjOzECNEfuU9hfNLuNYRnTeA5alqrBbSVVVF8MY=; b=Bb4NWq/VrHyt1oDd4drwYiPg7XzSJRcZfzA4wHvlI8WMuOI38H+t5m9Id8S6KCTvVD djvnqHmTyAcYZ/AFgaeTXJiXspbZwUPxuQzZGrQ+wpptq77dCqAUmz7v7kwlhHk7o0U4 QitM/Qo8i08EA4cMQdI02zyqSqWKqDrnji2UpTFUTB4zjofuzetlMAUJYjU7w6y4psbH h8vxIFrdMdCB45QxgAfMlf97Tx1o/qCVC5AA+k5pjyKZn8tcQ3WKx0wyUqSI947tXWM1 vdElZy+DUxiKM6znJXLd1TnyEFKc45d71UlJQ9LX5F5NAbXCs1iZoiNvLkUe3MNvXzrD ZrSw==
X-Gm-Message-State: ABUngvcOeOZx3XP06sjJiXhvm2AlcVP2AhylqtOnarRtv/tXGe5HCHqYWOV4NEN3twEINw==
X-Received: by 10.55.124.198 with SMTP id x189mr2727778qkc.95.1478084348995; Wed, 02 Nov 2016 03:59:08 -0700 (PDT)
Received: from ?IPv6:2601:18c:504:200e:6d30:1abe:415:3423? ([2601:18c:504:200e:6d30:1abe:415:3423]) by smtp.gmail.com with ESMTPSA id j39sm798321qte.34.2016.11.02.03.59.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 02 Nov 2016 03:59:08 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_EFBE1383-0D62-4D27-A65E-3181800A634C"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Margaret Cullen <mrcullen42@gmail.com>
In-Reply-To: <D66DDDA4-CCB4-4AF0-8C11-C78C97EA4B72@gmail.com>
Date: Wed, 02 Nov 2016 06:59:07 -0400
Message-Id: <92B4FC9B-9FEB-4B75-A3FB-B4B7648EC891@gmail.com>
References: <D66DDDA4-CCB4-4AF0-8C11-C78C97EA4B72@gmail.com>
To: banana@ietf.org
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/banana/2ag_pFHdf-C-JXmZ5Il5j1A1ge8>
Cc: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, Brian Trammell <ietf@trammell.ch>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Suresh Krishnan <suresh.krishnan@ericsson.com>
Subject: Re: [Banana] BOF Description and Agenda
X-BeenThere: banana@ietf.org
X-Mailman-Version: 2.1.17
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, 02 Nov 2016 10:59:13 -0000

Oh, it might have helped to include the description… :-)

- Name: BANdwidth Aggregation for interNet Access (BANANA)

- Description: 
This BOF will discuss how we can take advantage of multiple access links, provided by one or more access providers, in cases where end nodes and applications may not be multi-access-aware.  Use of multiple access links could provide bandwidth aggregation when multiple links are available (i.e. improved performance), and session continuation when a link becomes unavailable (i.e. increased reliability).  

Solutions to this problem are intended to apply to home and small-office networks, so solutions must support load-sharing of a small number of flows (in some cases only one) over multiple paths, recombining the traffic in ways that do not cause problems for the network (i.e. congestion, multi-level retransmission, etc.) or for upper-layer protocols (i.e. packet reordering within flows).  Solutions in this area must allow for some traffic to bypass bandwidth aggregation (e.g. for flows that are mandated to travel a specific path, or for flows that are already using a more end-to-end bandwidth aggregation solution).  Solutions should provide minimal (if any) performance degradation when multiple links are not available, or when one or more of the links is not performing sufficiently to support increased performance to the end nodes.

This is a Non-WG-forming BOF.  The purposes of the BOF are to discuss the problem space, and determine if there is sufficient interest and energy in the IETF to pursue any work in this area.  If the interest and energy exist, further effort may be exerted to scope and charter an IETF WG.

There has been an informal group, also called BANANA, looking at a subset of this space:  the case where multiple links are provided by a single Internet access provider/operator.  Multiple solutions that could apply to this subset have been discussed within that group, including:  a MIP-Based Solution (draft-ietf-dmm-mag-multihoming), an MPTCP Proxy-based solution (merged draft forthcoming), a GRE Tunnel Bonding Solution (draft-zhang-gre-tunnel-bonding), and a 3GPP-specific solution (draft-muley-bonding-solution-hybrid-access).  The MIP-based solution was developed in the DMM WG and is proposed for publication as a Standards Track RFC.  The GRE Tunnel Bonding solution, proposed for publication as an Independent Stream RFC, has been deployed by Deutsche Telecom in a large-scale operational network.  The MPTCP solution, though not yet fully documented, presents a promising, minimal-overhead solution, especially for situations where it is only necessary to share TCP traffic between multiple links.  There are significant differences between these proposals, resulting in different technical trade-offs, many of which have been explored in the BANANA Considerations Draft (draft-mrc-banana-considerations).  Some of the solutions that have been under discussion may apply (with or without additional signaling mechanisms) to the broader problem space where the access links may not be provided by a single operator.  This ongoing work will be discussed during the BOF, as it applies to the more general problem.

There has also been ongoing work in multiple other standards organizations to describe related problems.   The Broadband Forum has produced a “Hybrid Access” problem statement for DSL/LTE bandwidth aggregation specifically for the case where the DSL and LTE links are provided by a single operator (TR-348).  Documents from the other groups are not yet publicly available.

- Agenda:
0) Administrivia (5 mins)
1) BOF Scope and Problem Description (Chairs, 10 min)
2) BANANA Solution Space & Experiences
   - GRE Tunnel Bonding
     	 - Solution Overview (Mingui Zhang, 5 min)
	 - Deployment Experience (Nicolai Leymann, 5 min)
   - MPTCP Proxy (??, 10 min)
   - Others?
3) Related Research
   - Multipath Bonding at Layer 3 (Brian Trammel, 10 min)
4) Related Work in Other SDOs
   - Broadband Forum TR-348 (Dave Allan, 5 mins)
   - Others?
5) Open Discussion (30 mins)
6) Questions & Next Steps (Chairs & ADs, 10 mins)

- Status: Non-WG Forming 
- Responsible AD: Suresh Krishnan <suresh.krishnan@ericsson.com>
- BoF proponents: Mingui Zhang <zhangmingui@huawei.com>, Nicolai Leymann <n.laymann@telekom.de>, Margaret Cullen <mrcullen42@gmail.com>
- BoF chairs: Brian Trammel <ietf@trammell.ch>, Margaret Cullen <mrcullen42@gmail.com>
- 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): Entire INT Area, Entire TSV area, TSVAREA, INTAREA WG, MPTCP, DMM, TRILL, HOMENET, BABEL, CAPPORT
- Mailing List: https://www.ietf.org/mailman/listinfo/banana 
- Draft charter:  None

- Relevant drafts/documents:
https://datatracker.ietf.org/doc/draft-zhang-banana-problem-statement 
https://datatracker.ietf.org/doc/draft-mrc-banana-considerations 
https://datatracker.ietf.org/doc/draft-zhang-gre-tunnel-bonding 
https://datatracker.ietf.org/doc/draft-boucadair-mptcp-plain-mode
https://datatracker.ietf.org/doc/draft-peirens-mptcp-transparent
https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-multihoming-02
https://www.ietf.org/staging/draft-muley-bonding-solution-hybrid-access-00.txt
https://irtf.org/anrw/2016/anrw16-final21.pdf
https://www.broadband-forum.org/technical/download/TR-348.pdf


> On Nov 2, 2016, at 6:57 AM, Margaret Cullen <mrcullen42@gmail.com> wrote:
> 
> Hi All,
> 
> Here is the current BOF description and agenda (which will be posted in the next few minutes) for our upcoming BANANA BOF. 
> 
> As you can see, there is room in the agenda for someone to do a short presentation on the state of the MPTCP solution(s) that are applicable to this problem space, however a presenter has not been assigned.  We know that Olivier will not be in Seoul.  Will any of the advocates of an MPTCP solution (Med, perhaps?) be in Seoul and willing to present a quick overview?
> 
> Also, please let us know if you have any comments on the description or would like to add anything to the agenda.
> 
> Margaret
> 
> 
>