IETF Logo Mail Archive

Re: [Banana] Reaching Consensus on Problem Statement

Joe Touch <touch@isi.edu> Mon, 06 February 2017 19:13 UTC

Return-Path: <touch@isi.edu>
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 2FBCC12941A for <banana@ietfa.amsl.com>; Mon, 6 Feb 2017 11:13:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 lmCXzHI1j90C for <banana@ietfa.amsl.com>; Mon, 6 Feb 2017 11:13:21 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 AF9DE129484 for <banana@ietf.org>; Mon, 6 Feb 2017 11:13:18 -0800 (PST)
Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v16JCo6x021689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 6 Feb 2017 11:12:51 -0800 (PST)
To: Alan Ford <alan.ford@gmail.com>, Margaret Cullen <margaretw42@gmail.com>
References: <EE162993-F96F-458A-846C-D722EEF7A3B8@gmail.com> <2E42EA57-A7E4-45B1-8E26-08183FE8AF7A@gmail.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <07c0bd81-cdb4-701a-c7cc-b18ffbeaab3c@isi.edu>
Date: Mon, 06 Feb 2017 11:12:50 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <2E42EA57-A7E4-45B1-8E26-08183FE8AF7A@gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/banana/RkdhMms0kVyAD6xTQ7ePqvOqe1o>
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: Mon, 06 Feb 2017 19:13:22 -0000


On 2/4/2017 1:00 PM, Alan Ford wrote:
> One observation is that I think it is implied that this requires some
> kind of device in the network to assist with these scenarios (since
> otherwise end-to-end MPTCP would solve most of this for stream-based
> transports), but this is not stated.

It seems like it requires *two* such devices (tunnel endpoints) to make
this work.

The point is that you're essentially hiding dynamic multipath routing
inside what looks like a tunnel (which looks like a link).

I.e., this is really just a recursive router (of which LISP is one
example) with two edge devices.

There are other considerations, e.g., this has more potential impact on
reordering and less problems with egress determination for new flows
(since there's only one egress in each direction), but there might be
useful similarities to consider, FWIW.

Joe

v2.23.0 | Report a Bug | By Email