Re: [multipathtcp] Multipath deployment and fate sharing

Joe Touch <touch@ISI.EDU> Mon, 14 December 2009 18:54 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 ACCA43A6822 for <multipathtcp@core3.amsl.com>; Mon, 14 Dec 2009 10:54:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.139
X-Spam-Level:
X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=0.460, 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 ZvwoQBV32CQZ for <multipathtcp@core3.amsl.com>; Mon, 14 Dec 2009 10:54:07 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id E3AE23A67DF for <multipathtcp@ietf.org>; Mon, 14 Dec 2009 10:54:06 -0800 (PST)
Received: from [75.214.253.111] (111.sub-75-214-253.myvzw.com [75.214.253.111]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nBEIqigE028300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Dec 2009 10:52:50 -0800 (PST)
Message-ID: <4B268976.3030105@isi.edu>
Date: Mon, 14 Dec 2009 10:52:38 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: "Laganier, Julien" <julienl@qualcomm.com>
References: <E9EE0C1A-C9D3-4EBC-97FD-E1B1628CD2E7@iki.fi> <4B0C6590.9010000@isi.edu> <BF345F63074F8040B58C00A186FCA57F1C65FB29C6@NALASEXMB04.na.qualcomm.com> <4B0C6C13.2060103@isi.edu> <BF345F63074F8040B58C00A186FCA57F1C65FB29CB@NALASEXMB04.na.qualcomm.com> <4B0C6FBE.40003@isi.edu> <alpine.DEB.2.00.0911250211520.23603@ayourtch-lnx.stdio.be> <alpine.DEB.2.00.0911250428590.23603@ayourtch-lnx.stdio.be> <BE063B0C-BB34-4C75-A57E-1BAB0BE6780A@cs.ucl.ac.uk> <4B0D52D5.9090403@isi.edu> <58B2A4B2-F! 276-4E96-87FB-F8273FD78ED0@muada.com> <BF345F63074F8040B58C00A186FCA57F1C67584040@NALASEXMB04.na.qualcomm.com> <C6411A99-FB39-40E8-8F66-93ACA7B18016@muada.com> <BF345F63074F8040B58C00A186FCA57F1C67584054@NALASEXMB04.na.qualcomm.com> <4B2679D0.8040207@isi.edu> <BF345F63074F8040B58C00A186FCA57F1C67584057@NALASEXMB04.na.qualcomm.com> <4B2685A8.5070201@isi.edu> <BF345F63074F8040B58C00A186FCA57F1C67584063@NALASEXMB04.na.qualcomm.com>
In-Reply-To: <BF345F63074F8040B58C00A186FCA57F1C67584063@NALASEXMB04.na.qualcomm.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 List" <multipathtcp@ietf.org>
Subject: Re: [multipathtcp] Multipath deployment and fate sharing
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: Mon, 14 Dec 2009 18:54:07 -0000

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



Laganier, Julien wrote:
...
>> I agree fate sharing doesn't solve the issue, but its absence
>> definitely does make it "worse", where "worse" is considered 
>> (by me) to be "not what existing TCP does".
> 
> So the situation is already "worse" without MPTCP to the extent that
> "existing TCP" on SHIM6 already modifies the range of event that are
> visible to applications compared to the "existing TCP" on "existing IPv6".

Agreed. See below.

>> IMO, if you want to use TCP as the basis of MPTCP, then you need to
>> have defaults that do what TCP does, as visible to the app. layer, 
>> w.r.t. addresses.
> 
> If I apply that same logic to SHIM6 it should be turned off by
> default for all transport connections where the application hasn't opted in.

Agreed. That's what it should do. If SHIM6 breaks the rules, that's not
permission for MPTCP to do the same, though.

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

iEYEARECAAYFAksmiXQACgkQE5f5cImnZrutYACfbBrfBDwh8hIWWs4zIYk5HBg1
LTMAn1STfdF13CA8ncdW2y/UCJZVk902
=+jyj
-----END PGP SIGNATURE-----