Re: [Banana] Reaching Consensus on Problem Statement

Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> Fri, 03 February 2017 16:52 UTC

Return-Path: <mirja.kuehlewind@tik.ee.ethz.ch>
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 A1C0B129692 for <banana@ietfa.amsl.com>; Fri, 3 Feb 2017 08:52:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.098
X-Spam-Level:
X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 2TqeCMplyp3d for <banana@ietfa.amsl.com>; Fri, 3 Feb 2017 08:52:34 -0800 (PST)
Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E084A129669 for <banana@ietf.org>; Fri, 3 Feb 2017 08:52:33 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3vFNFr3l3Pz15Ly5; Fri, 3 Feb 2017 17:52:32 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch
Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vj7q8A704DyF; Fri, 3 Feb 2017 17:52:31 +0100 (CET)
X-MtScore: NO score=0
Received: from [192.168.178.33] (p5DEC295F.dip0.t-ipconnect.de [93.236.41.95]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Fri, 3 Feb 2017 17:52:31 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
In-Reply-To: <B25C09F5-205A-49B0-A1A7-677702C01E30@gmail.com>
Date: Fri, 03 Feb 2017 17:52:30 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <C6A24E90-BAD4-4F40-ABC8-619FC1876EBA@tik.ee.ethz.ch>
References: <EE162993-F96F-458A-846C-D722EEF7A3B8@gmail.com> <BBB875EC-629F-4B43-B528-11F5299BFE71@tik.ee.ethz.ch> <B25C09F5-205A-49B0-A1A7-677702C01E30@gmail.com>
To: Margaret Cullen <margaretw42@gmail.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/banana/9gzyDIkAT0xtqB73bjb0AZ6G2tE>
Cc: banana@ietf.org
Subject: Re: [Banana] Reaching Consensus on Problem Statement
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: Fri, 03 Feb 2017 16:52:35 -0000

Yes, that's right, also increasing the total bandwidth (for adaptive traffic) is a use case.


> Am 03.02.2017 um 16:45 schrieb Margaret Cullen <margaretw42@gmail.com>:
> 
> 
>> On Feb 3, 2017, at 5:14 AM, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> wrote:
>> 
>> Hi Margaret,
>>> 
>> This is related to point 4 and combining both is the interesting problem from my point of view. If you have multiple flows and multiple interfaces, it's rather easy to simply route/schedule different flows over different links (a la ECMP). The problem comes up if you have a service with one flow that needs more capacity than a single link can provide. The example we’ve been working on is HD video streaming in rural areas where the DSL is limited but LTE is provided and sparely used. In this case you need re-oder buffers and additional signaling between the tunnel endpoints.
> 
> This is an interesting way of putting it — that a single flow needs more bandwidth than a single link can provide.  I think I would say, though, that this is useful when a single flow needs _or can benefit from_ more bandwidth than a single link provides, because a solution is also desirable in this area to allow, for example, content downloads to finish more quickly, even if they do not _need_ to finish more quickly in order to be useful.  Does that make sense?
> 
> Margaret
>