IETF Logo Mail Archive

Re: [multipathtcp] Multipath deployment and fate sharing

"Laganier, Julien" <julienl@qualcomm.com> Mon, 14 December 2009 17:40 UTC

Return-Path: <julienl@qualcomm.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 2834C3A6A1C for <multipathtcp@core3.amsl.com>; Mon, 14 Dec 2009 09:40:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.979
X-Spam-Level:
X-Spam-Status: No, score=-103.979 tagged_above=-999 required=5 tests=[AWL=1.380, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100]
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 be5GvLrZKvPI for <multipathtcp@core3.amsl.com>; Mon, 14 Dec 2009 09:40:35 -0800 (PST)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 1D8553A6A1B for <multipathtcp@ietf.org>; Mon, 14 Dec 2009 09:40:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1260812422; x=1292348422; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20<julienl@qualcomm.com> |To:=20Iljitsch=20van=20Beijnum=20<iljitsch@muada.com> |CC:=20Joe=20Touch=20<touch@ISI.EDU>,=0D=0A=20=20=20=20 =20=20=20=20"multipathtcp@ietf.org=20List"=0D=0A=09<multi pathtcp@ietf.org>|Date:=20Mon,=2014=20Dec=202009=2009:40: 20=20-0800|Subject:=20RE:=20[multipathtcp]=20Multipath=20 deployment=20and=20fate=20sharing|Thread-Topic:=20[multip athtcp]=20Multipath=20deployment=20and=20fate=20sharing |Thread-Index:=20Acp83lz6KAimpEwoQ1yKHGvZ8s8TNgABQgfg |Message-ID:=20<BF345F63074F8040B58C00A186FCA57F1C6758405 4@NALASEXMB04.na.qualcomm.com>|References:=20<E9EE0C1A-C9 D3-4EBC-97FD-E1B1628CD2E7@iki.fi>=0D=0A=20<3c3e3fca091109 0542h54e45784qbdbf1f338a4c3e90@mail.gmail.com>=0D=0A=20<E 03D46E1-51EA-4273-A8A7-4F37F88B2E92@iki.fi>=0D=0A=20<2009 1123.092214.140617438.nishida@sfc.wide.ad.jp>=0D=0A=20<48 DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi>=0D=0A=20<3c3e3 fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com>=0D =0A=20<C622F375-EE67-46AE-AC28-6617CFEF6D12@lurchi.franke n.de>=0D=0A=20<BF345F63074F8040B58C00A186FCA57F1C65FB29B9 @NALASEXMB04.na.qualcomm.com>=0D=0A=20<4B0C607A.6060503@i si.edu>=0D=0A=20<BF345F63074F8040B58C00A186FCA57F1C65FB29 C0@NALASEXMB04.na.qualcomm.com>=0D=0A=20<4B0C6590.9010000 @isi.edu>=0D=0A=20<BF345F63074F8040B58C00A186FCA57F1C65FB 29C6@NALASEXMB04.na.qualcomm.com>=0D=0A=20<4B0C6C13.20601 03@isi.edu>=0D=0A=20<BF345F63074F8040B58C00A186FCA57F1C65 FB29CB@NALASEXMB04.na.qualcomm.com>=0D=0A=20<4B0C6FBE.400 03@isi.edu>=0D=0A=20<alpine.DEB.2.00.0911250211520.23603@ ayourtch-lnx.stdio.be>=0D=0A=20<alpine.DEB.2.00.091125042 8590.23603@ayourtch-lnx.stdio.be>=0D=0A=20<BE063B0C-BB34- 4C75-A57E-1BAB0BE6780A@cs.ucl.ac.uk>=0D=0A=20<4B0D52D5.90 90403@isi.edu>=20<58B2A4B2-F!=0D=0A=20276-4E96-87FB-F8273 FD78ED0@muada.com>=0D=0A=20<BF345F63074F8040B58C00A186FCA 57F1C67584040@NALASEXMB04.na.qualcomm.com>=0D=0A=20<C6411 A99-FB39-40E8-8F66-93ACA7B18016@muada.com>|In-Reply-To: =20<C6411A99-FB39-40E8-8F66-93ACA7B18016@muada.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=GA45Kl1CPWDWAUXHCzV46cZ2Xb4OA0B5c+mRGYqzjcg=; b=e3Y6J1bjHtyAjDeDHnt9XgL9JP2e61zZSjFlcsMsOFEPipF/xLfq8yJc XLKv1/zwZiFNleVOSqjfiuS54sRYb617JVrT1e2Wmv5rbQdQgIv4Hnh4l sDNnUojKucLsyTWfzeSB1Jx1Eo97+mF6XFQf6jeYluDCYirGYYdh+2ijP Y=;
X-IronPort-AV: E=McAfee;i="5400,1158,5832"; a="29877770"
Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 14 Dec 2009 09:40:22 -0800
Received: from ironstorm.qualcomm.com (ironstorm.qualcomm.com [172.30.39.153]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nBEHeLEJ009907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <multipathtcp@ietf.org>; Mon, 14 Dec 2009 09:40:22 -0800
X-IronPort-AV: E=Sophos;i="4.47,395,1257148800"; d="scan'208";a="23157116"
Received: from nasanexhub02.na.qualcomm.com ([10.46.143.120]) by ironstorm.qualcomm.com with ESMTP/TLS/RC4-MD5; 14 Dec 2009 09:40:21 -0800
Received: from nasanex14h01.na.qualcomm.com (10.46.94.107) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 14 Dec 2009 09:40:21 -0800
Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanex14h01.na.qualcomm.com (10.46.94.107) with Microsoft SMTP Server (TLS) id 14.0.639.21; Mon, 14 Dec 2009 09:40:21 -0800
Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Mon, 14 Dec 2009 09:40:20 -0800
From: "Laganier, Julien" <julienl@qualcomm.com>
To: Iljitsch van Beijnum <iljitsch@muada.com>
Date: Mon, 14 Dec 2009 09:40:20 -0800
Thread-Topic: [multipathtcp] Multipath deployment and fate sharing
Thread-Index: Acp83lz6KAimpEwoQ1yKHGvZ8s8TNgABQgfg
Message-ID: <BF345F63074F8040B58C00A186FCA57F1C67584054@NALASEXMB04.na.qualcomm.com>
References: <E9EE0C1A-C9D3-4EBC-97FD-E1B1628CD2E7@iki.fi> <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <E03D46E1-51EA-4273-A8A7-4F37F88B2E92@iki.fi> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> <C622F375-EE67-46AE-AC28-6617CFEF6D12@lurchi.franken.de> <BF345F63074F8040B58C00A186FCA57F1C65FB29B9@NALASEXMB04.na.qualcomm.com> <4B0C607A.6060503@isi.edu> <BF345F63074F8040B58C00A186FCA57F1C65FB29C0@NALASEXMB04.na.qualcomm.com> <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>
In-Reply-To: <C6411A99-FB39-40E8-8F66-93ACA7B18016@muada.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "multipathtcp@ietf.org List" <multipathtcp@ietf.org>, Joe Touch <touch@ISI.EDU>
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 17:40:36 -0000

Iljitsch van Beijnum wrote:
> On 14 dec 2009, at 17:38, Laganier, Julien wrote:
> > With IPv4 of course the situation would be different due to the IPv4
> > address space exhaustion, presence of NATs, and DHCP allocation with
> > short term leases. So in IPv4 we can't rule out situation #2, and thus
> > we want to make fate sharing the default IPv4.
> 
> I don't see that. With NAT you don't know who you're going to encounter
> behind a given address, anyway.

This is a valid point. 

Thus it seems that whether or not MPTCP implements fate sharing, a host can never be sure who's really behind a given IPv4 address. Essentially the address semantic is broken end-to-end.

For purely local matters, fate-sharing can be used to maintain some applications' expectations regarding the relationship between local addresses and the transport connections that are bound on them.

--julien

v2.23.0 | Report a Bug | By Email