IETF Logo Mail Archive

Re: [Banana] Reaching Consensus on Problem Statement

Margaret Cullen <margaretw42@gmail.com> Fri, 03 February 2017 15:45 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 CCA4212940D for <banana@ietfa.amsl.com>; Fri, 3 Feb 2017 07:45:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level:
X-Spam-Status: No, score=-2.448 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 w3r9sDwmB4EK for <banana@ietfa.amsl.com>; Fri, 3 Feb 2017 07:45:37 -0800 (PST)
Received: from mail-qt0-x242.google.com (mail-qt0-x242.google.com [IPv6:2607:f8b0:400d:c0d::242]) (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 3834C129437 for <banana@ietf.org>; Fri, 3 Feb 2017 07:45:37 -0800 (PST)
Received: by mail-qt0-x242.google.com with SMTP id s58so5421233qtc.2 for <banana@ietf.org>; Fri, 03 Feb 2017 07:45:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=snc/J+lQ90Vys7xVvQJHv9x85RSRdr18XyrXEnquY08=; b=bIDqtfGsNB5SCK7QXGRkwAZwckomqm9DrEcff1eZGILxFQX8IMTv4iGNofonfw98sZ Ug0Y/oxZx1pFT69L3LehSvsEIRh57M+fnGWyiXP//nd8yv5IOYhTKGLeEfPT3cKFd0/d IxLQ1+ft9PB1Q75O1w7w2x1RV+KCF6nxGLMyfD9bfk0g9g4mMPL2YCVw/3HWh/vhIaUK LxgJu2xtbzFDVdHum1AhxhRzqI8w06vFvPNNOfnz7Q4d5XU6TKgemkzyfkaXdwxT9BIy 69w/i+tgK8ew18+yQ9u2OL4a6gv7rDEste68v03WX1ptVyuwRoXv4+BLhQVjMWDLouGL OAaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=snc/J+lQ90Vys7xVvQJHv9x85RSRdr18XyrXEnquY08=; b=WGgheJRszl0G86/izgsodhtQEpd4PaRMS73yWF9lx7uQ3yX5ng+3GHPgZ2kcfYjkIK evYCXaJSlfLyU2j65dRMghrHhuQer3OrAPCFMkFQCM8kFFYJ7C3rs4LnykaJ+zDIbggM cKRjetmVc1358F3kLa+e5eOMehX/t77fzt7eG6lMdVa/pQE8nas3yPR2UH4xh3VhBwNz f5ZSeQQ7Dq1/AUVuUXcSakKO5fmO/6elvgkxMoafsLRkLb5L1qukR6DsCJpCHNwQk3TF LYXE/F5H/NkVeLFi3PktsuRCFLWTqrzVequV+OEVCp6+flrEYtqXN24KKr0vtxzL3xGs SkNg==
X-Gm-Message-State: AIkVDXJTZwyqhNo5Spfq+rmF/HOfpoGEBTnBSbOyNEC/L5rGd6AnGyxcizkST1M/iPBq8Q==
X-Received: by 10.237.39.222 with SMTP id m30mr13018688qtg.118.1486136736365; Fri, 03 Feb 2017 07:45:36 -0800 (PST)
Received: from ?IPv6:2601:18d:4700:100:5426:28dc:a759:1449? ([2601:18d:4700:100:5426:28dc:a759:1449]) by smtp.gmail.com with ESMTPSA id m143sm22119102qke.18.2017.02.03.07.45.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 03 Feb 2017 07:45:35 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_054FC4AF-89FD-48A8-9EB3-0C7EC9A06709"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Margaret Cullen <margaretw42@gmail.com>
In-Reply-To: <BBB875EC-629F-4B43-B528-11F5299BFE71@tik.ee.ethz.ch>
Date: Fri, 03 Feb 2017 10:45:34 -0500
Message-Id: <B25C09F5-205A-49B0-A1A7-677702C01E30@gmail.com>
References: <EE162993-F96F-458A-846C-D722EEF7A3B8@gmail.com> <BBB875EC-629F-4B43-B528-11F5299BFE71@tik.ee.ethz.ch>
To: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/banana/s0sy3C76h-SotjBoz_sf2aSK0F4>
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 15:45:39 -0000

> 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

v2.23.0 | Report a Bug | By Email