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

Joe Touch <touch@ISI.EDU> Tue, 03 November 2009 01:03 UTC

Return-Path: <touch@ISI.EDU>
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 40BA13A6862 for <multipathtcp@core3.amsl.com>; Mon, 2 Nov 2009 17:03:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.567
X-Spam-Level:
X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.033, 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 EyoGNmzMwjLh for <multipathtcp@core3.amsl.com>; Mon, 2 Nov 2009 17:03:51 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 78DEA3A684C for <multipathtcp@ietf.org>; Mon, 2 Nov 2009 17:03:51 -0800 (PST)
Received: from [75.212.97.118] (118.sub-75-212-97.myvzw.com [75.212.97.118]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nA30uJSV020781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Nov 2009 16:56:22 -0800 (PST)
Message-ID: <4AEF7FB3.4020604@isi.edu>
Date: Mon, 02 Nov 2009 16:56:19 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Mark Handley <M.Handley@cs.ucl.ac.uk>
References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> <4AEF6114.6070106@it.uc3m.es> <3c3e3fca0911021538y3ebd3f3fx6a03e7bc5b03f246@mail.gmail.com> <84a612dd0911021640s3820b7b1w3602b63f3d568527@mail.gmail.com>
In-Reply-To: <84a612dd0911021640s3820b7b1w3602b63f3d568527@mail.gmail.com>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: 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 01:03:52 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Mark Handley wrote:
> 2009/11/2 William Herrin <bill@herrin.us>:
>> Consider the following scenario:
>>
>> Host A comes online with 1.2.3.4.
>> Host A requests a new TCP connection to 5.6.7.8.
>> Established with host B at 5.6.7.8.
>> Host B adds 8.7.6.5
>> Host B removes 5.6.7.8
>> Host C comes online with 5.6.7.8.
>> Host A requests a new TCP connection to 5.6.7.8.
>>
>> Which host does A connect to?
> 
> I'm not sure I see the problem.
> 
> When host B removes 5.6.7.8, that address is removed from that
> connection only.  It has no relation with any other connections,
> ongoing or future.  If A has any other connections with 5.6.7.8, they
> are unaffected (after all, 5.6.7.8 may be a NAT with several hosts
> behind it) unless they also explicitly remove the address.
> 
> When A requests a new TCP connection to 5.6.7.8, that's what A's app
> specified at that moment in the connect call, and that's the address
> the SYN will be sent to.  No previous behaviour for any other
> connection affects that.

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?

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkrvf7MACgkQE5f5cImnZruzbgCePtU/NMkZd/JxuEPcYDZp8RmO
ZzcAn1JyiFj5q5iZqpFgS0pc6b8veSxf
=Jukr
-----END PGP SIGNATURE-----