Re: [multipathtcp] High-level design decisions /architecture

Lars Eggert <lars.eggert@nokia.com> Tue, 03 November 2009 04:07 UTC

Return-Path: <lars.eggert@nokia.com>
X-Original-To: multipathtcp@core3.amsl.com
Delivered-To: multipathtcp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 522803A6809 for <multipathtcp@core3.amsl.com>; Mon, 2 Nov 2009 20:07:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sl5IazfHN4sr for <multipathtcp@core3.amsl.com>; Mon, 2 Nov 2009 20:07:37 -0800 (PST)
Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 515983A67E3 for <multipathtcp@ietf.org>; Mon, 2 Nov 2009 20:07:37 -0800 (PST)
Received: from [172.20.100.59] ([66.201.48.54]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id nA347YRf088913 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 3 Nov 2009 06:07:42 +0200 (EET) (envelope-from lars.eggert@nokia.com)
Mime-Version: 1.0 (Apple Message framework v1076)
Content-Type: multipart/signed; boundary="Apple-Mail-78--258825711"; protocol="application/pkcs7-signature"; micalg="sha1"
From: Lars Eggert <lars.eggert@nokia.com>
In-Reply-To: <4AEF7FB3.4020604@isi.edu>
Date: Mon, 02 Nov 2009 20:07:28 -0800
Message-Id: <98B687E1-CB11-47E2-84A6-2F7F7ECAFB95@nokia.com>
References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> <4AEF6114.6070106@it.uc3m.es> <3c3e3fca0911021538y3ebd3f3fx6a03e7bc5b03f246@mail.gmail.com> <84a612dd0911021640s3820b7b1w3602b63f3d568527@mail.gmail.com> <4AEF7FB3.4020604@isi.edu>
To: Joe Touch <touch@ISI.EDU>
X-Mailer: Apple Mail (2.1076)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [195.148.124.194]); Tue, 03 Nov 2009 06:07:46 +0200 (EET)
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Subject: Re: [multipathtcp] High-level design decisions /architecture
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Nov 2009 04:07:38 -0000

Hi,

On 2009-11-2, at 16:56, Joe Touch wrote:
> How do you know whether 5.6.7.8 is the same place as the first
> connection, or a new place? Don't you need to figure that out to know
> whether you end up with new capacity, or need to share capacity?


I don't think you care whether it's the same location or not - the  
linked congestion control proposal doesn't infer topology information  
from IP addresses.

Lars