IETF Logo Mail Archive

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

Mark Handley <M.Handley@cs.ucl.ac.uk> Tue, 03 November 2009 00:40 UTC

Return-Path: <mark.j.handley@gmail.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 751023A6847 for <multipathtcp@core3.amsl.com>; Mon, 2 Nov 2009 16:40:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.724
X-Spam-Level:
X-Spam-Status: No, score=-1.724 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 x2KhDEk3+0JV for <multipathtcp@core3.amsl.com>; Mon, 2 Nov 2009 16:40:39 -0800 (PST)
Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 9AE9E3A6820 for <multipathtcp@ietf.org>; Mon, 2 Nov 2009 16:40:38 -0800 (PST)
Received: by bwz23 with SMTP id 23so7009895bwz.29 for <multipathtcp@ietf.org>; Mon, 02 Nov 2009 16:40:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=VGVzlRyvN/77rprLG7zsuccNQDRpHb93mc2kn+u4SxA=; b=LRNLb7/wDMwP2r93gqrIXlQ16A2i63kkqSDN4IxvhDwL+CxYpP1iWvp228RRMqtNYC bsbHZG1S0nsahXQwHkNIS82ksojHMTu8/cxbVqza9VP9rYywWoqK58WGXJMAohdZqwnd lrwUtl4hpeB8v4tabd1SHMBHoWPnBGGMv4WvA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=jabzSyfOsAm2l6L3PPOaSo3Otub3p7E7DVtUfvvK6nFlMADtjYSTuVdOjCxqaIwmNH Nhq7JHf+DjwqBYsqXfD52VyWhAQ0N3ooXmIyy/Jnxi1xcOmrAI2Ilmy135GE0jRiCEOa cx5zfDWRa31GRrJGkB3mSd4Bz9XfpxAmF0LuU=
MIME-Version: 1.0
Sender: mark.j.handley@gmail.com
Received: by 10.223.16.72 with SMTP id n8mr838958faa.26.1257208854259; Mon, 02 Nov 2009 16:40:54 -0800 (PST)
In-Reply-To: <3c3e3fca0911021538y3ebd3f3fx6a03e7bc5b03f246@mail.gmail.com>
References: <4A916DBC72536E419A0BD955EDECEDEC06363A62@E03MVB1-UKBR.domain1.systemhost.net> <3c3e3fca0911021328h2ef65493v9f0290f384f7b800@mail.gmail.com> <4AEF6114.6070106@it.uc3m.es> <3c3e3fca0911021538y3ebd3f3fx6a03e7bc5b03f246@mail.gmail.com>
From: Mark Handley <M.Handley@cs.ucl.ac.uk>
Date: Tue, 03 Nov 2009 00:40:34 +0000
X-Google-Sender-Auth: 4dc22fe94be2c2a6
Message-ID: <84a612dd0911021640s3820b7b1w3602b63f3d568527@mail.gmail.com>
To: William Herrin <bill@herrin.us>
Content-Type: text/plain; charset="ISO-8859-1"
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 00:40:42 -0000

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.

 - Mark

v2.23.0 | Report a Bug | By Email