From nishida@sfc.wide.ad.jp Tue Dec 1 01:21:23 2009 Return-Path: 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 AD8073A69FF for ; Tue, 1 Dec 2009 01:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.09 X-Spam-Level: * X-Spam-Status: No, score=1.09 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] 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 l7yoZTNgUwEh for ; Tue, 1 Dec 2009 01:21:23 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id DF47F3A67A3 for ; Tue, 1 Dec 2009 01:21:22 -0800 (PST) Received: from localhost (cpu.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 5DC004C5EF; Tue, 1 Dec 2009 18:21:10 +0900 (JST) Date: Tue, 01 Dec 2009 18:21:10 +0900 (JST) Message-Id: <20091201.182110.212700015.nishida@sfc.wide.ad.jp> To: Michael.Tuexen@lurchi.franken.de From: Yoshifumi Nishida In-Reply-To: <4DA55308-08B9-442D-AA0B-37975B816E47@lurchi.franken.de> References: <20091126.041514.183027096.nishida@sfc.wide.ad.jp> <4DA55308-08B9-442D-AA0B-37975B816E47@lurchi.franken.de> X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Multipath Address Family X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 09:21:23 -0000 From: Michael T=FCxen Subject: Re: [multipathtcp] Multipath Address Family Date: Fri, 27 Nov 2009 18:06:51 +0100 Message-ID: <4DA55308-08B9-442D-AA0B-37975B816E47@lurchi.franken.de> > > If connectx() sends multiple SYNs simultaneously to the multiple d= estinations, > > it will be problematic. But, if connectx() has the following logic= , > > it tries to send a SYN one-by-one to each destination > > it gets SYN-ACK, it stops to send a SYN and return. > But then it can take long until you setup you transport connection. > The application could just run a loop over the peer addresses and ca= ll connect() > to it, see if it works. If it fails try the next. This might take a = long time > you you have a lot of addresses to try and some of them are not work= ing. Yes, but, if the definitoin of connectx() is just to connect only one o= f given = addresses, we could try other addresses after first timeout of SYN or w= e might able to try simultaneous SYN sending under some conditions. (we might need t= o send reset = to some destinations, but I hope it will be acceptable price to pay) In my feeling, this kind of mechanism can be generic for multiple trans= port protocols. -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From touch@ISI.EDU Tue Dec 1 14:57:26 2009 Return-Path: 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 D374F3A6783 for ; Tue, 1 Dec 2009 14:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 BrVDRIJ4iZb3 for ; Tue, 1 Dec 2009 14:57:26 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 0DBCB3A6827 for ; Tue, 1 Dec 2009 14:57:17 -0800 (PST) Received: from [70.213.188.6] (6.sub-70-213-188.myvzw.com [70.213.188.6]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nB1Muesu004976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Dec 2009 14:56:42 -0800 (PST) Message-ID: <4B159F27.4020008@isi.edu> Date: Tue, 01 Dec 2009 14:56:39 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "multipathtcp@ietf.org List" , Christian Vogt Subject: Re: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 22:57:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rémi Després wrote: > Le 27 nov. 2009 à 11:57, Scott Brim a écrit : > >> IIRC in Christian's idea the transport layer itself works on names. >> It's more than a proposal for a name-based API. > > Agreed. > I haven't studied all details of Christian's proposal, but I fully support that: > - A name-capable API is an essential objective. I'm not sure this is a desirable objective. When you specify a name, you're not specifying a single address; you're specifying any one of a set of addresses. It's presumed that these are equivalent, but not that they are to the same host. A name-based system could easily end up with a sequence of connections going to different hosts. That's avoided today as: adr = first(dns("name")) -- or adr = pickone(dns("name")) connect(adr) connect(adr) connect(adr) There doesn't seem to be a way to achieve this with: connect("name") connect("name") connect("name") This destroys the utility of HTTP cookies, e.g. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksVnycACgkQE5f5cImnZrti8QCgtmz8tlQLsVc+FJBrv/DHsVtt oc8AoN3o2nwh78vgS//7vu+FkMfLpp7b =i0zn -----END PGP SIGNATURE----- From remi.despres@free.fr Wed Dec 2 02:26:38 2009 Return-Path: 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 A50573A6A94 for ; Wed, 2 Dec 2009 02:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.634 X-Spam-Level: X-Spam-Status: No, score=-1.634 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] 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 E43-kpzrtub2 for ; Wed, 2 Dec 2009 02:26:38 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id A7BCD3A6A8D for ; Wed, 2 Dec 2009 02:26:36 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 1B0A8E08140; Wed, 2 Dec 2009 11:26:22 +0100 (CET) Received: from [192.168.0.15] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 00873E08120; Wed, 2 Dec 2009 11:26:19 +0100 (CET) Message-ID: <4B1642BC.30508@free.fr> Date: Wed, 02 Dec 2009 11:34:36 +0100 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 1.5.0.14ubu (X11/20090105) MIME-Version: 1.0 To: Joe Touch References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> In-Reply-To: <4B159F27.4020008@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "multipathtcp@ietf.org List" , Stuart Cheshire , Christian Vogt Subject: Re: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 10:26:38 -0000 Hi Joe, Comments below. Stuart Cheshire added to the list (AFAIK, the leading advocate of connect-by-name). Regards, RD Joe Touch wrote : ... > Rémi Després wrote: ... >> I haven't studied all details of Christian's proposal, but I fully support that: >> - A name-capable API is an essential objective. > I'm not sure this is a desirable objective. > > When you specify a name, you're not specifying a single address; you're > specifying any one of a set of addresses. It's presumed that these are > equivalent, but not that they are to the same host. A name-based system > could easily end up with a sequence of connections going to different > hosts. > > That's avoided today as: > > adr = first(dns("name")) -- or adr = pickone(dns("name")) > connect(adr) > connect(adr) > connect(adr) > There doesn't seem to be a way to achieve this with: > > connect("name") > connect("name") > connect("name") > > This destroys the utility of HTTP cookies, e.g. Note that: - If backward compatibility is maintained, as required in the proposal, a name-capable API doesn't imply that it be address-unable. - Connect-by-name is already mentioned for Shim6 in RFC 5533 - sec. 13, (a way to save time when multiple addresses have to be tried for a given domain name) Applications that may depend on successive connections to go to the same host, they can use: ConnectByName(name) which returns the chosen adr Connect(adr) Connect(adr) Connect(adr) The useful novelty ahead is IMHO the following: - If a connection initiator includes its domain name in its connection request (e.g. in a TCP option) the API of the reached application, if it is name-capable, provides both the address AND the name of the connection initiator. - A consistency check between address and name is done by the transport laye before connection acceptance. This check needs only a DNS query. It is therefore compatible with DNS dynamic updates and DNSSEC (no need for a DNS supported reverse mapping). From caozhenpku@gmail.com Wed Dec 2 06:28:45 2009 Return-Path: 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 477A628C1F1 for ; Wed, 2 Dec 2009 06:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 WwKf1Ot8k5ZT for ; Wed, 2 Dec 2009 06:28:44 -0800 (PST) Received: from mail-px0-f184.google.com (mail-px0-f184.google.com [209.85.216.184]) by core3.amsl.com (Postfix) with ESMTP id 7AB5928C1EF for ; Wed, 2 Dec 2009 06:28:44 -0800 (PST) Received: by pxi14 with SMTP id 14so175340pxi.31 for ; Wed, 02 Dec 2009 06:28:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=P2o8zWJSct4g2C5JXXHaufTG9QWRscfDhurN1pxdCdo=; b=LhObfYAwrQLPsHPqsyZOpZKQNduksag+LlPmOrrPDyHBodiNU43VX8Nbl8R7uV15U6 FN3cKVYgPVwqWdCLl1CNer1b/QzYjGBYYcGJ5exq96zAHT1PXBNK8HbNw7V/tUj5r8FM 9JI9OF08zpgkqwyEAPKj9evfZ1vCF2e2Fi5m8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ICdZe2NVo+kdMW9uiVC4J1Hw4bKn1eVwRkY+HglEd+1T0+QjagmhmbCdljKLFudFKB izFINofO8SxxEImDKzKD4lJ/eCoTUKQAzboxfz4nE5rKSG4/jIGYuWSQgwQMNwrCq6Kl SF9duD/pzq5IwDX0jjdvNQZLeB3LaTOtZglmw= MIME-Version: 1.0 Received: by 10.142.61.19 with SMTP id j19mr17193wfa.201.1259764114027; Wed, 02 Dec 2009 06:28:34 -0800 (PST) In-Reply-To: <4B1642BC.30508@free.fr> References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> <4B1642BC.30508@free.fr> Date: Wed, 2 Dec 2009 22:28:33 +0800 Message-ID: From: Zhen Cao To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "multipathtcp@ietf.org List" , Stuart Cheshire , Christian Vogt Subject: Re: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 14:28:45 -0000 On Wed, Dec 2, 2009 at 6:34 PM, R=E9mi Despr=E9s wro= te: > Hi Joe, > > Comments below. > Stuart Cheshire added to the list (AFAIK, the leading advocate of > connect-by-name). > > Regards, > RD > > Joe Touch wrote : > ... >> >> R=E9mi Despr=E9s wrote: > > ... >>> >>> I haven't studied all details of Christian's proposal, but I fully >>> support that: >>> - A name-capable API is an essential objective. > > >> I'm not sure this is a desirable objective. >> >> When you specify a name, you're not specifying a single address; you're >> specifying any one of a set of addresses. It's presumed that these are >> equivalent, but not that they are to the same host. A name-based system >> could easily end up with a sequence of connections going to different >> hosts. >> >> That's avoided today as: >> >> =A0 =A0 =A0 =A0adr =3D first(dns("name")) =A0-- or adr =3D pickone(dns("= name")) >> =A0 =A0 =A0 =A0connect(adr) >> =A0 =A0 =A0 =A0connect(adr) >> =A0 =A0 =A0 =A0connect(adr) >> There doesn't seem to be a way to achieve this with: >> >> =A0 =A0 =A0 =A0connect("name") >> =A0 =A0 =A0 =A0connect("name") >> =A0 =A0 =A0 =A0connect("name") >> >> This destroys the utility of HTTP cookies, e.g. > > Note that: > - If backward compatibility is maintained, as required in the proposal, a > name-capable API doesn't imply that it be address-unable. I have a question here. How does a host know if its peer support the name oriented sockets or not? > - Connect-by-name is already mentioned for Shim6 in RFC 5533 - sec. 13, (= a > way to save time when multiple addresses have to be tried for a given dom= ain > name) > > Applications that may depend on successive connections to go to the same > host, they can use: > =A0 =A0 =A0 =A0ConnectByName(name) which returns the chosen adr > =A0 =A0 =A0 =A0Connect(adr) > =A0 =A0 =A0 =A0Connect(adr) > =A0 =A0 =A0 =A0Connect(adr) > > The useful novelty ahead is IMHO the following: > - If a connection initiator includes its domain name in its connection > request (e.g. in a TCP option) the API of the reached application, if it = is > name-capable, provides both the address AND the name of the connection > initiator. > - A consistency check between address and name is done by the transport l= aye > before connection acceptance. This check needs only a DNS query. It is > therefore compatible with DNS dynamic updates and DNSSEC (no need for a D= NS > supported reverse mapping). > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > From c.raiciu@cs.ucl.ac.uk Wed Dec 2 06:50:47 2009 Return-Path: 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 6CF4E3A685B for ; Wed, 2 Dec 2009 06:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=-0.667, 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 vnoDqathOzlF for ; Wed, 2 Dec 2009 06:50:45 -0800 (PST) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id 7CAF43A67EC for ; Wed, 2 Dec 2009 06:50:45 -0800 (PST) Received: from blackie2.cs.ucl.ac.uk ([128.16.68.58]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1NFqMv-000HWL-CQ for multipathtcp@ietf.org; Wed, 02 Dec 2009 14:39:49 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Costin Raiciu In-Reply-To: Date: Wed, 2 Dec 2009 14:50:32 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <6B27A5F3-9F3C-48C0-A3BC-2D99E6A35298@cs.ucl.ac.uk> References: <2181C5F19DD0254692452BFF3EAF1D6808D7BB51@rsys005a.comm.ad.roke.co.uk> <3c3e3fca0911091838w6620d955m68074495027d7c5d@mail.gmail.com> To: "multipathtcp@ietf.org List" X-Mailer: Apple Mail (2.1077) Subject: Re: [multipathtcp] Options or Payload: pros and cons X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 14:50:47 -0000 Hi Bryan, Your mail is not late. It's spot on, as we're still trying to figure out = the best solution.=20 You make some very good points. Thanks for the thoughts. Costin On 30 Nov 2009, at 15:24, Bryan Ford wrote: > Trying to catch up on the list activity before, during, and after the = Hiroshima meeting, I'm wondering if there's a summary of any significant = progress on the "options vs payload" debate. To add my $.02 to part of = the list discussion that might already be obsolete, but maybe not... >=20 > On Nov 10, 2009, at 9:21 PM, Costin Raiciu wrote: >> Options >> + nice with tcp >> + single subflow mptcp if friendly with IDSes, and traffic = normalizers (i.e. data flow is what the app receives). >> - reliability is more difficult (how often do you retransmit?) drop = packets? what's the failure mode when options don't get through? >> - boxes may crash when parsing unknown stuff. The hope is that on SYN = processing is more robust with unknown options. ECN story is frightening = :). Murari (Microsoft) >> says that even changing position of padding bits in options crashes = some middleboxes; I've heard a similar story from the Linux kernel = experience. However, we can't (cleanly) avoid sending options on SYNs. >=20 > Not to mention the show-stopper in my view: > - there just isn't enough free option space left to do what needs to = be done, as has been pointed out before (e.g., by Bill Herrin). = Especially given that some of these options would need to carry = cryptographically unpredictable identifiers (Connection IDs, Subflow = IDs, etc.), which will need to be either "fairly big" or "growable" or = both. >=20 >> Payload >> + option space limits no longer matter; can do funkier stuff later, = like negotiate keys, etc. >> + easier to get reliability; retransmit of control data linked to = data retransmit >> + easier to deal with middleboxes that resegment (it just works!) >> + new options on syns may be allowed, but not on data (is this true)? >> - feels like a hack, not the traditional way to evolve tcp >=20 > =46rom my architectural perspective MPTCP is a new, separate transport = protocol that happens to use legacy TCP as an underlying "Flow/Endpoint = Layer" protocol for legacy network compatibility purposes. As such, = from my perspective, adding a bunch of new options to legacy TCP feels = like the hack to me. In contrast, putting the new protocol's new stuff = into a new "multipath transport layer" cleanly layered atop and = independent of the legacy TCP "flow/endpoint layer" - i.e., encoded = within the legacy TCP payloads - feels like the architecturally clean = approach. All a matter of perspective, of course. >=20 >> - implies encoding of any data sent MUST be ASCII; middleboxes (ids, = traffic normalizers) that look at content and see binary stuff will = probably drop the data; finally, if we used binary stuff, there is no = guarantee for fate sharing. . Text encoding is less space efficient; = does it matter? >=20 > This issue seems like either a red herring or just the tip of the = iceberg. Any way you cut it, the stuff a NAT/firewall is going to see = within an MPTCP subflow is often going to look a lot different from the = same application running atop classic TCP. That's going to confuse some = middleboxes; the question is just how hard we want to work to avoid = that. >=20 > Consider the obvious "common case" of an HTTP conversation atop a = classic TCP flow versus two or more MPTCP subflows. Suppose the HTTP = request and response headers are small, as they typically are, and are = (sometimes) followed by a large binary blob, e.g., a JPEG. Assume as is = likely the HTTP request/response text fits in one IP packet. If MPTCP = is doing its job, then that first payload segment containing the HTTP = request/response header will flow over only one subflow (most likely the = initial subflow); the first TCP payload data any middlebox sees flowing = on any OTHER subflow is going to come from somewhere in the middle of = the binary blob. Unless MPTCP deliberately takes some really special = measures to hack around this (e.g., by redundantly sending the initial = HTTP request/response on all subflows), this binary blob data IS going = to confuse any middlebox that is trying to look into one of those other = subflows expecting a parseable HTTP request or response. The question = is then just how badly the middlebox behaves in that situation, and I = expect to find a wide range of answers in the real world. >=20 > The problem here is that, unlike most incremental, backward-compatible = TCP enhancements of the past like SACK, PAWS, etc., MPTCP is not just a = control-plane tweak but fundamentally involves slicing and dicing the = payload data. If a legacy middlebox is looking at an MPTCP subflow, = ignoring any new MPTCP negotiation options but expecting to find an HTTP = header in the payload because the subflow is directed at port 80, it's = going to get confused because what's running on top of the legacy TCP = subflow is not really HTTP anymore (as the port number 80 suggests it = should be) but rather an MPTCP payload with HTTP somehow more deeply = layered/embedded atop that. If we really want to avoid such forms of = confusion, I see at least the following options: >=20 > 1. Have MPTCP use a different TCP port number: e.g., allocate one TCP = port number for all MPTCP subflows, and embed the "real" = application-visible port number in an MPTCP header embedded in TCP = payload. Then legacy middleboxes just see legacy TCP connections to an = unknown port: on the upside, they are unlikely to expect to see an HTTP = header and fall over if they don't; on the downside, such TCP = connections will be less likely to get through many firewalls, will = break applications' attempts at doing TCP-based NAT traversal, etc. >=20 > 2. Have MPTCP use the application's port number in the initial flow = but a "special" port number for other subflows, in the hopes that the = middlebox only really cares about the beginning of the stream and will = "stop paying attention" in any detail after it sees, e.g., the expected = HTTP header. Non-initial subflows are still likely to get filtered as = above, but at least the initial flow will look "normal" up until the = point MPTCP starts actually distributing traffic. Application-directed = NAT traversals will probably work to the extent they work under classic = TCP, though only on the initial flow: other subflows will probably just = fail, effectively disabling MPTCP for such connections. >=20 > 3. Design MPTCP to use not just TCP but in fact HTTP-over-TCP as its = legacy-network-compatibility "Flow/Endpoint Layer". That is, _every_ = MPTCP subflow looks like an HTTP connection to port 80 (regardless of = the application running atop MPTCP), and its TCP payload starts with its = own pseudo-HTTP header whose purpose is merely to get through legacy = middleboxes. This is likely to get through more middleboxes, but adds = overhead and all the usual complications of tunneling. Furthermore, = based on Microsoft's experience with DirectAccess I hear even = HTTP-over-TCP is often not adequate to get through many middleboxes - = therefore, one might even consider... >=20 > 4. Encapsulate MPTCP within an HTTP-over-SSL-over-TCP tunnel, as = Microsoft did with IP-over-HTTPS = (http://msdn.microsoft.com/en-us/library/dd358571(PROT.10).aspx). All = MPTCP subflows look to the network like HTTPS connections to port 443. = The internal HTTP layer doesn't matter to the network since it's = encrypted; its presence is just so that port 443 can be shared with = other conventional web server functions on the responder side of the = connection. >=20 > I'm not seriously suggesting that the MPTCP spec should necessarily = incorporate any of these alternatives; just pointing out how slippery = this slope is once we start down it. Perhaps it does at least represent = a further argument that MPTCP needs the architectural flexibility to = have multiple compatibility Flow/Endpoint layers "plugged into" it = underneath the multipath transport logic, each providing varying = compatibility/efficiency/desperation tradeoffs. >=20 > Bryan >=20 From john@jlc.net Wed Dec 2 07:01:39 2009 Return-Path: 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 50E6D3A62C1 for ; Wed, 2 Dec 2009 07:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.745 X-Spam-Level: X-Spam-Status: No, score=-5.745 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_MED=-4] 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 TLvKB2W5GbQf for ; Wed, 2 Dec 2009 07:01:38 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 3FD9728C1EC for ; Wed, 2 Dec 2009 07:01:38 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id C72CC33C2E; Wed, 2 Dec 2009 10:01:29 -0500 (EST) Date: Wed, 2 Dec 2009 10:01:29 -0500 From: John Leslie To: R?mi Despr?s Message-ID: <20091202150129.GN37915@verdi> References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> <4B1642BC.30508@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B1642BC.30508@free.fr> User-Agent: Mutt/1.4.1i Cc: "multipathtcp@ietf.org List" , Stuart Cheshire , Christian Vogt , Joe Touch Subject: Re: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 15:01:39 -0000 R?mi Despr?s wrote: > > Stuart Cheshire added to the list (AFAIK, the leading advocate of > connect-by-name). Hi, Stuart! > Joe Touch wrote : > >> I'm not sure this is a desirable objective. >> >> When you specify a name, you're not specifying a single address; you're >> specifying any one of a set of addresses. It's presumed that these are >> equivalent, but not that they are to the same host. A name-based system >> could easily end up with a sequence of connections going to different >> hosts. True. >> That's avoided today as: >> >> adr = first(dns("name")) -- or adr = pickone(dns("name")) >> connect(adr) >> connect(adr) >> connect(adr) >> There doesn't seem to be a way to achieve this with: >> >> connect("name") >> connect("name") >> connect("name") >> >> This destroys the utility of HTTP cookies, e.g. Only if both ends are blind to the issue... > Note that: > - If backward compatibility is maintained, as required in the proposal, > a name-capable API doesn't imply that it be address-unable. > - Connect-by-name is already mentioned for Shim6 in RFC 5533 - sec. 13, > (a way to save time when multiple addresses have to be tried for a > given domain name) > > Applications that may depend on successive connections to go to the same > host, they can use: > ConnectByName(name) which returns the chosen adr > Connect(adr) > Connect(adr) > Connect(adr) That's one way to think about the problem... > The useful novelty ahead is IMHO the following: > - If a connection initiator includes its domain name in its connection > request (e.g. in a TCP option) the API of the reached application, if > it is name-capable, provides both the address AND the name of the > connection initiator. I would argue that any ConnectByName API SHOULD contain the _name_ by which your end wants to be known by the other end. ("Connect" should imply establishing a "connection" IMHO.) > - A consistency check between address and name is done by the transport > layer before connection acceptance. This check needs only a DNS query. > It is therefore compatible with DNS dynamic updates and DNSSEC (no > need for a DNS supported reverse mapping). I'm not sure that's necessary, but it's certainly appropriate to discuss what consistency checks _are_ necessary... I would argue that our charter calls for work on " " e. An extended API describing how applications can exploit additional " features of multipath transport. While MPTCP needs to be usable " without any application changes, this API should be an optional " extension that provides access to multipath information and enables " control over the usage of multipath. and further that "an extended API" should enable extension to protocol extensions yet to be defined. Thus: - the same "extended API" should be able to request legacy TCP, MPTCP, or even other transports (such as SCTP); - the "extended API" should be able to use DNS names or some other name format to be defined later (for one example, IPv6 "address" space is large enough to contain many "name" spaces); - the "extended API" should return an indication of which names and/or addresses the other end of the connection uses. -- John Leslie From touch@ISI.EDU Wed Dec 2 07:14:04 2009 Return-Path: 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 7319A28C1FB for ; Wed, 2 Dec 2009 07:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 qzLNbF3qY15W for ; Wed, 2 Dec 2009 07:14:02 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 3A3E828C1E7 for ; Wed, 2 Dec 2009 07:14:02 -0800 (PST) Received: from [192.168.1.43] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nB2FCk45029369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Dec 2009 07:12:48 -0800 (PST) Message-ID: <4B1683ED.9090602@isi.edu> Date: Wed, 02 Dec 2009 07:12:45 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> <4B1642BC.30508@free.fr> In-Reply-To: <4B1642BC.30508@free.fr> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "multipathtcp@ietf.org List" , Stuart Cheshire , Christian Vogt Subject: Re: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 15:14:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rémi Després wrote: > Hi Joe, > > Comments below. > Stuart Cheshire added to the list (AFAIK, the leading advocate of > connect-by-name). > > Regards, > RD > > Joe Touch wrote : > ... >> Rémi Després wrote: > ... >>> I haven't studied all details of Christian's proposal, but I fully >>> support that: >>> - A name-capable API is an essential objective. > > >> I'm not sure this is a desirable objective. >> >> When you specify a name, you're not specifying a single address; you're >> specifying any one of a set of addresses. It's presumed that these are >> equivalent, but not that they are to the same host. A name-based system >> could easily end up with a sequence of connections going to different >> hosts. >> >> That's avoided today as: >> >> adr = first(dns("name")) -- or adr = pickone(dns("name")) >> connect(adr) >> connect(adr) >> connect(adr) >> There doesn't seem to be a way to achieve this with: >> >> connect("name") >> connect("name") >> connect("name") >> >> This destroys the utility of HTTP cookies, e.g. > > Note that: > - If backward compatibility is maintained, as required in the proposal, > a name-capable API doesn't imply that it be address-unable. > - Connect-by-name is already mentioned for Shim6 in RFC 5533 - sec. 13, > (a way to save time when multiple addresses have to be tried for a given > domain name) > > Applications that may depend on successive connections to go to the same > host, they can use: > ConnectByName(name) which returns the chosen adr > Connect(adr) > Connect(adr) > Connect(adr) This cannot work for multipath TCP. If you do not have "fate sharing" with the original address, subsequent connections to an address could go to a different host (e.g., that is reassigned an IP address). If you do have fate-sharing with the original address, an endpoint will never be able to connect to an address once reassigned. I.e., neither way is viable. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksWg+0ACgkQE5f5cImnZrvnfwCg79TScwg+MI5O3rD+HGXcAj7Q AfsAn0pcwmwUgSOBI++VnqR/psF21bX8 =LqS7 -----END PGP SIGNATURE----- From julienl@qualcomm.com Wed Dec 2 08:29:12 2009 Return-Path: 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 6C4243A67D8 for ; Wed, 2 Dec 2009 08:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.49 X-Spam-Level: X-Spam-Status: No, score=-105.49 tagged_above=-999 required=5 tests=[AWL=0.809, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 YlILKZvdC2xP for ; Wed, 2 Dec 2009 08:29:11 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 497403A6403 for ; Wed, 2 Dec 2009 08:29:11 -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=1259771343; x=1291307343; 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:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Joe=20Touch=20,=0D=0A=20=20=20=20 =20=20=20=20=3D?iso-8859-1?Q?R=3DE9mi_Despr=3DE9s?=3D=0D =0A=09|CC:=20"multipathtcp@ietf.org =20List"=20,=0D=0A=20=20=20=20=20 =20=20=20Christian=20Vogt=0D=0A=09|Date:=20Wed,=202=20Dec=202009=2008:29:00=20-0800 |Subject:=20RE:=20[multipathtcp]=20Fwd:=20[rrg]=20New=20P aper=20On=20Name-Oriented=20Sockets=0D=0A=20Interface |Thread-Topic:=20[multipathtcp]=20Fwd:=20[rrg]=20New=20Pa per=20On=20Name-Oriented=20Sockets=0D=0A=20Interface |Thread-Index:=20Acpy2aVLerApD6SjSXuKfYEsDV1t3AAkAl4w |Message-ID:=20|References:=20=0D=0A=09<3C622E25 -DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com>=0D=0A=09<4B0FB0AA .2060303@gmail.com>=09=0D=0A=20<4B159F27.4020008@isi.edu> |In-Reply-To:=20<4B159F27.4020008@isi.edu> |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"iso-8 859-1"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 400,1158,5820"=3B=20a=3D"28890209"; bh=OCSc4jjnHSF41wJpm5wbL7YkTDAoyBSZbfAg39EUy+w=; b=r4uuYxY8i1zux9KJGlHHv3KPEHnxgZr41dDRAOAa3WeYJp0rjI8iGlDr 01okr5CN83jyYZNsEw3xBCaZLqJuISWnVKW404FENDvq9SB02wsMHLpIh 9aMg5XbGj5un1E/jiQR2HGFg18Ws8JWb71PVua5j7tlhJHmsjzzCUFDr+ g=; X-IronPort-AV: E=McAfee;i="5400,1158,5820"; a="28890209" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 02 Dec 2009 08:29:03 -0800 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nB2GT3Sd027547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Dec 2009 08:29:03 -0800 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nB2GT2js020460 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 2 Dec 2009 08:29:02 -0800 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 2 Dec 2009 08:29:02 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Wed, 2 Dec 2009 08:29:02 -0800 From: "Laganier, Julien" To: Joe Touch , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Date: Wed, 2 Dec 2009 08:29:00 -0800 Thread-Topic: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface Thread-Index: Acpy2aVLerApD6SjSXuKfYEsDV1t3AAkAl4w Message-ID: References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> In-Reply-To: <4B159F27.4020008@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "multipathtcp@ietf.org List" , Christian Vogt Subject: Re: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 16:29:12 -0000 Hi Joe, Joe Touch wrote=20 >=20 > R=E9mi Despr=E9s wrote: > > Le 27 nov. 2009 =E0 11:57, Scott Brim a =E9crit : > > > >> IIRC in Christian's idea the transport layer itself works on names. > >> It's more than a proposal for a name-based API. > > > > Agreed. > > I haven't studied all details of Christian's proposal, but I fully > support that: > > - A name-capable API is an essential objective. >=20 > I'm not sure this is a desirable objective. >=20 > When you specify a name, you're not specifying a single address; you're > specifying any one of a set of addresses. It's presumed that these are > equivalent, but not that they are to the same host. A name-based system > could easily end up with a sequence of connections going to different > hosts. >=20 > That's avoided today as: >=20 > adr =3D first(dns("name")) -- or adr =3D pickone(dns("name")) > connect(adr) > connect(adr) > connect(adr) >=20 > There doesn't seem to be a way to achieve this with: >=20 > connect("name") > connect("name") > connect("name") >=20 > This destroys the utility of HTTP cookies, e.g. Looking at this from a different perspective: Since the resolution of a dom= ain name into an address is only valid for the TTL of the returned resource= record, it also makes sense that an application that want to connect to a = name always call the name to address resolver before connecting to the addr= ess. The resolver has knowledge of the TTL, and can return the same address= if the resource record hasn't expired, or issue another DNS query and retu= rn the result if the resource record had expired. So in terms of your sequence examples: adr =3D first(dns("name")) -- DNS query return A RR with TTL 255 connect(adr) adr =3D first(dns("name")) -- A RR TTL is now 32, no DNS query connect(adr) ... -- A RR TTL is zero, resolver cache is flushed=20 adr =3D first(dns("name")) -- DNS query return A RR with TTL 255=20 connect(adr) So if the service provided at "name" is stateful across different connectio= ns, it seems like it is the service provider responsibility to ensure that = a given client always connect to the same server (possibly via different ad= dresses), or the client state be replicated amongst different servers whose= addresses are returned from the DNS. That can be achieved in various ways = which are protocol and deployment specific, e.g., L7 load balancer, cluster= ing... =20 So either ways (the one you outlined or the one above) seem 'legal' and pos= sible, thus I don't think we should assume a specific DNS semantic (e.g., o= ne name corresponds to one server) or application behavior (e.g., applicati= on queries a name for an address and then (re)connect to the address) in th= e API discussion. Situations varies with protocols and deployments. --julien=20 From touch@ISI.EDU Wed Dec 2 08:39:13 2009 Return-Path: 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 8962E3A6ADB for ; Wed, 2 Dec 2009 08:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 3vcE1kMzqIkk for ; Wed, 2 Dec 2009 08:39:12 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id C1B983A6839 for ; Wed, 2 Dec 2009 08:39:12 -0800 (PST) Received: from [192.168.1.43] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id nB2GcY19005524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Dec 2009 08:38:36 -0800 (PST) Message-ID: <4B16980A.4@isi.edu> Date: Wed, 02 Dec 2009 08:38:34 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Laganier, Julien" References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: nB2GcY19005524 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "multipathtcp@ietf.org List" , Christian Vogt Subject: Re: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 16:39:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Julien, Laganier, Julien wrote: > Hi Joe, ... >> There doesn't seem to be a way to achieve this with: >> >> connect("name") >> connect("name") >> connect("name") >> >> This destroys the utility of HTTP cookies, e.g. > > Looking at this from a different perspective: Since the resolution of > a domain name into an address is only valid for the TTL of the returned > resource record, it also makes sense that an application that want to > connect to a name always call the name to address resolver before > connecting to the address. The resolver has knowledge of the TTL, and > can return the same address if the resource record hasn't expired, or > issue another DNS query and return the result if the resource record had > expired. Yes, but do you want behavior to change depending on whether the TTL has expired? I.e., occasionally your HTTP cookies fail? Current use caches the address at the application because the name was relevant only for the connection; subsequent connections are intended for the same *endpoint*, not just the same name. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksWmAoACgkQE5f5cImnZruj6ACg+XbT/ZwKWEAOqv/12zCO0yPP izcAn0LWRN4cOvxpeHfw/C5NaGu888y2 =EjPG -----END PGP SIGNATURE----- From julienl@qualcomm.com Wed Dec 2 09:02:05 2009 Return-Path: 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 EA4913A6ACB for ; Wed, 2 Dec 2009 09:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.664 X-Spam-Level: X-Spam-Status: No, score=-105.664 tagged_above=-999 required=5 tests=[AWL=0.935, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 GHC+gP2hXix1 for ; Wed, 2 Dec 2009 09:02:02 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 87E533A67A5 for ; Wed, 2 Dec 2009 09:02:02 -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=1259773315; x=1291309315; 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:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Joe=20Touch=20|CC:=20=3D?iso-8859-1 ?Q?R=3DE9mi_Despr=3DE9s?=3D=20,=0D =0A=20=20=20=20=20=20=20=20"multipathtcp@ietf.org=20List" =20,=0D=0A=20=20=20=20=20=20=20=20 Christian=20Vogt=0D=0A=09 |Date:=20Wed,=202=20Dec=202009=2009:01:51=20-0800 |Subject:=20RE:=20[multipathtcp]=20Fwd:=20[rrg]=20New=20P aper=20On=20Name-Oriented=20Sockets=0D=0A=20Interface |Thread-Topic:=20[multipathtcp]=20Fwd:=20[rrg]=20New=20Pa per=20On=20Name-Oriented=20Sockets=0D=0A=20Interface |Thread-Index:=20AcpzbgBtlez+wCx1R76BGnq5a6nS/AAADHTg |Message-ID:=20|References:=20=0D=0A=09<3C622E25 -DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com>=0D=0A=09<4B0FB0AA .2060303@gmail.com>=09=0D=0A=20<4B159F27.4020008@isi.edu>=0D=0A=20=0D=0A=20<4B16980A.4@isi.edu>|In-Reply-To: =20<4B16980A.4@isi.edu>|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"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 400,1158,5820"=3B=20a=3D"28892664"; bh=BNBaqQd/KEMRooBdDB//Jkib70oOvVxyCXfwqlJ0BL0=; b=NzJAaEdN3oN532H0BSx1EznXghrrSfXq/k80jfsV5t8xzrvUpgf44Cef y6oQA/7pElUl9Fmekws93cwz/t0e0axG7NOPRVKmoY4kVDT+WGupWD4xv V4t8eZW4ZpbHX/R15pZqTw+9pYeHTlm06gc6l+TMpbg55YUC55S1OpB4C 4=; X-IronPort-AV: E=McAfee;i="5400,1158,5820"; a="28892664" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 02 Dec 2009 09:01:54 -0800 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nB2H1sML031215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Dec 2009 09:01:54 -0800 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nB2H1rK1013892 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 2 Dec 2009 09:01:53 -0800 (PST) Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 2 Dec 2009 09:01:53 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Wed, 2 Dec 2009 09:01:52 -0800 From: "Laganier, Julien" To: Joe Touch Date: Wed, 2 Dec 2009 09:01:51 -0800 Thread-Topic: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface Thread-Index: AcpzbgBtlez+wCx1R76BGnq5a6nS/AAADHTg Message-ID: References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> <4B16980A.4@isi.edu> In-Reply-To: <4B16980A.4@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "multipathtcp@ietf.org List" , Christian Vogt Subject: Re: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 17:02:05 -0000 Joe Touch wrote: > ... > Laganier, Julien wrote: > >... > >> There doesn't seem to be a way to achieve this with: > >> > >> connect("name") > >> connect("name") > >> connect("name") > >> > >> This destroys the utility of HTTP cookies, e.g. > > > > Looking at this from a different perspective: Since the resolution of > > a domain name into an address is only valid for the TTL of the > > returned resource record, it also makes sense that an application that > > want to connect to a name always call the name to address resolver > > before connecting to the address. The resolver has knowledge of the=20 > > TTL, and can return the same address if the resource record hasn't=20 > > expired, or issue another DNS query and return the result if the=20 > > resource record had expired. >=20 > Yes, but do you want behavior to change depending on whether the TTL > has expired? I.e., occasionally your HTTP cookies fail? >=20 > Current use caches the address at the application because the name was > relevant only for the connection; subsequent connections are intended > for the same *endpoint*, not just the same name. My point was that the address might be cached or not at the application, bo= th are possible. The application might make sure it's connecting to the sam= e address, or make sure it's connecting to a fresh address for the name. So if a specific application want to make sure it's connecting to the same = address it can cache the address both with connect() and, as Remi pointed o= ut, with connect_to_name(). --julien From touch@ISI.EDU Wed Dec 2 09:21:02 2009 Return-Path: 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 D10AF3A6954 for ; Wed, 2 Dec 2009 09:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=-0.040, 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 iXckD2xZzu8S for ; Wed, 2 Dec 2009 09:21:02 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 079703A6953 for ; Wed, 2 Dec 2009 09:21:02 -0800 (PST) Received: from [192.168.1.43] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id nB2HJJw2014230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Dec 2009 09:19:20 -0800 (PST) Message-ID: <4B16A197.8050902@isi.edu> Date: Wed, 02 Dec 2009 09:19:19 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Laganier, Julien" References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> <4B16980A.4@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: nB2HJJw2014230 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "multipathtcp@ietf.org List" , Christian Vogt Subject: Re: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 17:21:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Laganier, Julien wrote: > Joe Touch wrote: >> ... >> Laganier, Julien wrote: >>> ... >>>> There doesn't seem to be a way to achieve this with: >>>> >>>> connect("name") >>>> connect("name") >>>> connect("name") >>>> >>>> This destroys the utility of HTTP cookies, e.g. >>> Looking at this from a different perspective: Since the resolution of >>> a domain name into an address is only valid for the TTL of the >>> returned resource record, it also makes sense that an application that >>> want to connect to a name always call the name to address resolver >>> before connecting to the address. The resolver has knowledge of the >>> TTL, and can return the same address if the resource record hasn't >>> expired, or issue another DNS query and return the result if the >>> resource record had expired. >> Yes, but do you want behavior to change depending on whether the TTL >> has expired? I.e., occasionally your HTTP cookies fail? >> >> Current use caches the address at the application because the name was >> relevant only for the connection; subsequent connections are intended >> for the same *endpoint*, not just the same name. > > My point was that the address might be cached or not at the > application, both are possible. The application might make sure it's > connecting to the same address, or make sure it's connecting to a fresh > address for the name. The former is not possible with multipath TCP if the original IP addresses disappear. > So if a specific application want to make sure it's connecting to the > same address it can cache the address both with connect() and, as Remi > pointed out, with connect_to_name(). If it does, then we're back to the existing API. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksWoZYACgkQE5f5cImnZrs6QQCfWZxwRbA3otwYQRE9O3KCIGjI NaMAoPxG0dsuJQngvtr5sslWDKVOT+NX =lm2g -----END PGP SIGNATURE----- From julienl@qualcomm.com Wed Dec 2 10:28:02 2009 Return-Path: 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 5D4733A69DD for ; Wed, 2 Dec 2009 10:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.69 X-Spam-Level: X-Spam-Status: No, score=-105.69 tagged_above=-999 required=5 tests=[AWL=0.909, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 Y1h+5puHSDa9 for ; Wed, 2 Dec 2009 10:28:01 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 6478F3A69C4 for ; Wed, 2 Dec 2009 10:28:01 -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=1259778473; x=1291314473; 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:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Joe=20Touch=20|CC:=20=3D?iso-8859-1 ?Q?R=3DE9mi_Despr=3DE9s?=3D=20,=0D =0A=20=20=20=20=20=20=20=20"multipathtcp@ietf.org=20List" =20,=0D=0A=20=20=20=20=20=20=20=20 Christian=20Vogt=0D=0A=09 |Date:=20Wed,=202=20Dec=202009=2010:27:48=20-0800 |Subject:=20RE:=20[multipathtcp]=20Fwd:=20[rrg]=20New=20P aper=20On=20Name-Oriented=20Sockets=0D=0A=20Interface |Thread-Topic:=20[multipathtcp]=20Fwd:=20[rrg]=20New=20Pa per=20On=20Name-Oriented=20Sockets=0D=0A=20Interface |Thread-Index:=20Acpzc876jN7sc8K7Q6KGpyBwBV8h1QABW0GQ |Message-ID:=20|References:=20=0D=0A=09<3C622E25 -DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com>=0D=0A=09<4B0FB0AA .2060303@gmail.com>=09=0D=0A=20<4B159F27.4020008@isi.edu>=0D=0A=20=0D=0A=20<4B16980A.4@isi.edu>=0D=0A=20=0D=0A=20<4B16A197.8050902@isi.edu>|In-Reply-To: =20<4B16A197.8050902@isi.edu>|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"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 400,1158,5820"=3B=20a=3D"28899157"; bh=pm1WHn0m0ohHyW1+pQ+MyNjDWA2KJSmiAdfVLiQ70X0=; b=JgskZC/AgnNo1VGxYOt945VleSWJPDloMbt3Pnld7LjRsLEK6IAD+3df ppbfHNfwMHFpAOpBHY1A2lDMxcTV2ltTOyUKYBA9lcQqi+JBgO5vbH5XA NSVvxPGLRNvJM/uM//iRpUeoC5XGYYKLiB7lEZ7Gdj+5Aocsg2XzFt2q3 Y=; X-IronPort-AV: E=McAfee;i="5400,1158,5820"; a="28899157" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 02 Dec 2009 10:27:53 -0800 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nB2IRrrL026738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Dec 2009 10:27:53 -0800 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nB2IRmSM002776 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 2 Dec 2009 10:27:52 -0800 Received: from nasanex14h01.na.qualcomm.com (10.46.94.107) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 2 Dec 2009 10:27:51 -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; Wed, 2 Dec 2009 10:27:51 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Wed, 2 Dec 2009 10:27:51 -0800 From: "Laganier, Julien" To: Joe Touch Date: Wed, 2 Dec 2009 10:27:48 -0800 Thread-Topic: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface Thread-Index: Acpzc876jN7sc8K7Q6KGpyBwBV8h1QABW0GQ Message-ID: References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> <4B16980A.4@isi.edu> <4B16A197.8050902@isi.edu> In-Reply-To: <4B16A197.8050902@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "multipathtcp@ietf.org List" , Christian Vogt Subject: Re: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 18:28:02 -0000 Joe Touch wrote: >=20 > > > > My point was that the address might be cached or not at the > > application, both are possible. The application might make sure it's > > connecting to the same address, or make sure it's connecting to a > > fresh address for the name. >=20 > The former is not possible with multipath TCP if the original IP > addresses disappear. If the original IP address disappear, the connect() to that address will fa= il, period.=20 > > So if a specific application want to make sure it's connecting to the > > same address it can cache the address both with connect() and, as > > Remi pointed out, with connect_to_name(). >=20 > If it does, then we're back to the existing API. No we're not. We still have the advantage that the initial connection can b= e established to the fastest IPv{4,6} endpoint. --julien From touch@ISI.EDU Wed Dec 2 11:00:13 2009 Return-Path: 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 11C843A688A for ; Wed, 2 Dec 2009 11:00:13 -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=[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 GZN5x2vMa8jz for ; Wed, 2 Dec 2009 11:00:12 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 50ACE3A67DB for ; Wed, 2 Dec 2009 11:00:12 -0800 (PST) Received: from [75.213.146.151] (151.sub-75-213-146.myvzw.com [75.213.146.151]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nB2IxeWk002260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Dec 2009 10:59:43 -0800 (PST) Message-ID: <4B16B91C.6020409@isi.edu> Date: Wed, 02 Dec 2009 10:59:40 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Laganier, Julien" References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> <4B16980A.4@isi.edu> <4B16A197.8050902@isi.edu> In-Reply-To: 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" , Christian Vogt Subject: Re: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 19:00:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Laganier, Julien wrote: > Joe Touch wrote: >>> My point was that the address might be cached or not at the >>> application, both are possible. The application might make sure it's >>> connecting to the same address, or make sure it's connecting to a >>> fresh address for the name. >> The former is not possible with multipath TCP if the original IP >> addresses disappear. > > If the original IP address disappear, the connect() to that address will fail, period. Right - but that's not what you want to happen in multipath TCP, right? >>> So if a specific application want to make sure it's connecting to the >>> same address it can cache the address both with connect() and, as >>> Remi pointed out, with connect_to_name(). >> If it does, then we're back to the existing API. > > No we're not. We still have the advantage that the initial connection > can be established to the fastest IPv{4,6} endpoint. Fastest? I think this means you leave the decision to another layer, but I haven't heard anyone explain 'fastest' yet. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksWuRwACgkQE5f5cImnZrvibwCgiuWnhLrONXDwMHzBPTsavB0g neYAn2LyIBbZ66/J8uVic9Lb+j5h0xlm =xk/N -----END PGP SIGNATURE----- From julienl@qualcomm.com Wed Dec 2 11:08:02 2009 Return-Path: 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 BF3A33A6A45 for ; Wed, 2 Dec 2009 11:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.716 X-Spam-Level: X-Spam-Status: No, score=-103.716 tagged_above=-999 required=5 tests=[AWL=-1.117, BAYES_00=-2.599, 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 Jpl01NcjuWyj for ; Wed, 2 Dec 2009 11:08:01 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 9DFED3A6A0B for ; Wed, 2 Dec 2009 11:08:01 -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=1259780874; x=1291316874; 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:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Joe=20Touch=20|CC:=20=3D?iso-8859-1 ?Q?R=3DE9mi_Despr=3DE9s?=3D=20,=0D =0A=20=20=20=20=20=20=20=20"multipathtcp@ietf.org=20List" =20,=0D=0A=20=20=20=20=20=20=20=20 Christian=20Vogt=0D=0A=09 |Date:=20Wed,=202=20Dec=202009=2011:07:19=20-0800 |Subject:=20RE:=20[multipathtcp]=20Fwd:=20[rrg]=20New=20P aper=20On=20Name-Oriented=20Sockets=0D=0A=20Interface |Thread-Topic:=20[multipathtcp]=20Fwd:=20[rrg]=20New=20Pa per=20On=20Name-Oriented=20Sockets=0D=0A=20Interface |Thread-Index:=20AcpzgbKT7U/Ht8MURwOfTlq0Z62JhwAACv3w |Message-ID:=20|References:=20=0D=0A=09<3C622E25 -DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com>=0D=0A=09<4B0FB0AA .2060303@gmail.com>=09=0D=0A=20<4B159F27.4020008@isi.edu>=0D=0A=20=0D=0A=20<4B16980A.4@isi.edu>=0D=0A=20=0D=0A=20<4B16A197.8050902@isi.edu>=0D=0A=20=0D=0A=20<4B16B91C.6020409@isi.edu> |In-Reply-To:=20<4B16B91C.6020409@isi.edu> |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"iso-8 859-1"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 400,1158,5820"=3B=20a=3D"28909016"; bh=AK8YbyoCuR5dYFwX54mUV1iX+jIyeMXRk2IB+VEgyHE=; b=zN/ijmUtp+Yz82n9p7pkfHSfFyBy4MPc3SJ727kf768XOEYhJJpHXKjO vrv6RgBECTzTRFl6qpGkJL3HUe9m0ZlcIS5+3Wg2m5F6imcvQvKewyJSN URjm37VT2wTT5Hl3zzkKTAmGSuf1rqF1ZIvt8jF7UUIuCWC70YC/4U4cD M=; X-IronPort-AV: E=McAfee;i="5400,1158,5820"; a="28909016" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP; 02 Dec 2009 11:07:35 -0800 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nB2J7Z4p000442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Dec 2009 11:07:35 -0800 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nB2J78Bc020722 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 2 Dec 2009 11:07:35 -0800 (PST) Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 2 Dec 2009 11:07:21 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Wed, 2 Dec 2009 11:07:21 -0800 From: "Laganier, Julien" To: Joe Touch Date: Wed, 2 Dec 2009 11:07:19 -0800 Thread-Topic: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface Thread-Index: AcpzgbKT7U/Ht8MURwOfTlq0Z62JhwAACv3w Message-ID: References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> <4B16980A.4@isi.edu> <4B16A197.8050902@isi.edu> <4B16B91C.6020409@isi.edu> In-Reply-To: <4B16B91C.6020409@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "multipathtcp@ietf.org List" , Christian Vogt Subject: Re: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 19:08:02 -0000 Joe Touch wrote:=20 > Laganier, Julien wrote: > > Joe Touch wrote: > >>> My point was that the address might be cached or not at the > >>> application, both are possible. The application might make sure > >>> it's connecting to the same address, or make sure it's connecting > >>> to a fresh address for the name. > >> > >> The former is not possible with multipath TCP if the original IP > >> addresses disappear. > > > > If the original IP address disappear, the connect() to that address > will fail, period. >=20 > Right - but that's not what you want to happen in multipath TCP, right? In the case we're discussing this is a further connect() after an initial c= onnect_by_name() and thus another MPTCP connection, so it should fail.=20 This is different from a single MPTCP connection surviving the disappearanc= e of the original IP address (i.e., not implementing fate sharing b/w an MP= TCP connection and the original address.)=20 =20 > >>> So if a specific application want to make sure it's connecting to > the > >>> same address it can cache the address both with connect() and, as > >>> Remi pointed out, with connect_to_name(). > >> If it does, then we're back to the existing API. > > > > No we're not. We still have the advantage that the initial connection > > can be established to the fastest IPv{4,6} endpoint. >=20 > Fastest? >=20 > I think this means you leave the decision to another layer, but I > haven't heard anyone explain 'fastest' yet. For example, send SYN to a a couple of the addresses (v4 or v6) return in t= he DNS response, and only complete the TCP handshake with the address from = which you received the first SYN-ACK. --julien=20 From touch@ISI.EDU Wed Dec 2 11:13:24 2009 Return-Path: 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 7946D3A6944 for ; Wed, 2 Dec 2009 11:13:24 -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 R3VNiVeQ953s for ; Wed, 2 Dec 2009 11:13:21 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id D57053A6AC8 for ; Wed, 2 Dec 2009 11:13:20 -0800 (PST) Received: from [75.213.146.151] (151.sub-75-213-146.myvzw.com [75.213.146.151]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nB2JCs80007061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Dec 2009 11:12:56 -0800 (PST) Message-ID: <4B16BC36.80905@isi.edu> Date: Wed, 02 Dec 2009 11:12:54 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Laganier, Julien" References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> <4B16980A.4@isi.edu> <4B16A197.8050902@isi.edu> <4B16B91C.6020409@isi.edu> In-Reply-To: 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" , Christian Vogt Subject: Re: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 19:13:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Laganier, Julien wrote: ... >>> No we're not. We still have the advantage that the initial connection >>> can be established to the fastest IPv{4,6} endpoint. >> Fastest? >> >> I think this means you leave the decision to another layer, but I >> haven't heard anyone explain 'fastest' yet. > > For example, send SYN to a a couple of the addresses (v4 or v6) return > in the DNS response, and only complete the TCP handshake with the > address from which you received the first SYN-ACK. That gives you the fastest SYN-ACK time. Which has nothing to do with many other desirable properties (largest BW, lowest data packet latency, etc.) And that's already possible at the app layer, FWIW. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksWvDUACgkQE5f5cImnZrvMAACgkqo7kbLgsKdm/L1xqTinLb/P /GUAnj7sH91O8uG6yj6hvBMPofT+6W1t =YTPq -----END PGP SIGNATURE----- From remi.despres@free.fr Thu Dec 3 00:56:24 2009 Return-Path: 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 2AF223A68AD for ; Thu, 3 Dec 2009 00:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3] 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 MsiPQFV5rJAx for ; Thu, 3 Dec 2009 00:56:23 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 40BA93A69E3 for ; Thu, 3 Dec 2009 00:56:21 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id A7DD1E0802C; Thu, 3 Dec 2009 09:56:08 +0100 (CET) Received: from [192.168.0.15] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 6E585E08028; Thu, 3 Dec 2009 09:56:05 +0100 (CET) Message-ID: <4B177D24.8090505@free.fr> Date: Thu, 03 Dec 2009 09:56:04 +0100 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 1.5.0.14ubu (X11/20090105) MIME-Version: 1.0 To: Joe Touch References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> <4B1642BC.30508@free.fr> <4B1683ED.9090602@isi.edu> In-Reply-To: <4B1683ED.9090602@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "multipathtcp@ietf.org List" , Stuart Cheshire , Christian Vogt Subject: Re: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 08:56:24 -0000 Joe Touch wrote : > Rémi Després wrote: >> Applications that may depend on successive connections to go to the same >> host, they can use: >> ConnectByName(name) which returns the chosen adr >> Connect(adr) >> Connect(adr) >> Connect(adr) > > This cannot work for multipath TCP. I don't see why this would work less than what you described, namely: adr = first(dns("name")) -- or adr = pickone(dns("name")) connect(adr) connect(adr) connect(adr) It seems that,like in RFC 5533 sec 1.3 for Mip6, the adr that is selected in the initial contact with the remote peer can be used as the preserved upper layer identifier (ULID). RD From remi.despres@free.fr Thu Dec 3 01:31:29 2009 Return-Path: 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 12A8228C137 for ; Thu, 3 Dec 2009 01:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.067 X-Spam-Level: X-Spam-Status: No, score=-1.067 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_51=0.6, MIME_8BIT_HEADER=0.3] 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 1USoU96zen70 for ; Thu, 3 Dec 2009 01:31:28 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id E6ACA3A68B6 for ; Thu, 3 Dec 2009 01:31:26 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 79A72E081DE; Thu, 3 Dec 2009 10:31:12 +0100 (CET) Received: from [192.168.0.15] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 04AF1E080A7; Thu, 3 Dec 2009 10:31:07 +0100 (CET) Message-ID: <4B17855B.5030609@free.fr> Date: Thu, 03 Dec 2009 10:31:07 +0100 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 1.5.0.14ubu (X11/20090105) MIME-Version: 1.0 To: John Leslie References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> <4B1642BC.30508@free.fr> <20091202150129.GN37915@verdi> In-Reply-To: <20091202150129.GN37915@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "multipathtcp@ietf.org List" , Stuart Cheshire , Christian Vogt , Joe Touch Subject: Re: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 09:31:29 -0000 John Leslie wrote : > R?mi Despr?s wrote: >> The useful novelty ahead is IMHO the following: >> - If a connection initiator includes its domain name in its connection >> request (e.g. in a TCP option) the API of the reached application, if >> it is name-capable, provides both the address AND the name of the >> connection initiator. > > I would argue that any ConnectByName API SHOULD contain the _name_ > by which your end wants to be known by the other end. ("Connect" should > imply establishing a "connection" IMHO.) Agreed. It can be a useful extension that the connection initiator may provide both the name of the target endpoint but also its own name, and that the called endpoint would be in this case informed of both the name of the initiator provided name and the name provided as target endpoint. >> - A consistency check between address and name is done by the transport >> layer before connection acceptance. This check needs only a DNS query. >> It is therefore compatible with DNS dynamic updates and DNSSEC (no >> need for a DNS supported reverse mapping). > > I'm not sure that's necessary, but it's certainly appropriate to > discuss what consistency checks _are_ necessary... Agreed to discuss it, but hoping to conclude positively: Making consistency checks mandatory as soon as they are possible, greatly simplifies security in general, and anti-spoofing in particular. (Letting errors or malevolent inconsistencies to propagate greatly increases higher maintenance costs and insecurity.) > - the same "extended API" should be able to request legacy TCP, MPTCP, > or even other transports (such as SCTP); Agreed. > - the "extended API" should be able to use DNS names Agreed. > or some other name > format to be defined later (for one example, IPv6 "address" space is > large enough to contain many "name" spaces); To be seen, but agreed that using some ad-hoc-format IPv6 addresses as names has IMHO an interesting potential. > > - the "extended API" should return an indication of which names and/or > addresses the other end of the connection uses. Agreed. RD From remi.despres@free.fr Thu Dec 3 01:55:32 2009 Return-Path: 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 12DC73A6855 for ; Thu, 3 Dec 2009 01:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.638 X-Spam-Level: X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] 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 WXcToyLAxDK2 for ; Thu, 3 Dec 2009 01:55:31 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 304D13A6A06 for ; Thu, 3 Dec 2009 01:55:29 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id BB752E08195; Thu, 3 Dec 2009 10:55:16 +0100 (CET) Received: from [192.168.0.15] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 5D77DE080E9; Thu, 3 Dec 2009 10:55:11 +0100 (CET) Message-ID: <4B178AFE.3020309@free.fr> Date: Thu, 03 Dec 2009 10:55:10 +0100 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 1.5.0.14ubu (X11/20090105) MIME-Version: 1.0 To: Zhen Cao References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> <4B1642BC.30508@free.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "multipathtcp@ietf.org List" , Stuart Cheshire , Christian Vogt Subject: Re: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 09:55:32 -0000 Zhen Cao wrote : > On Wed, Dec 2, 2009 at 6:34 PM, Rémi Després wrote: >> - If backward compatibility is maintained, as required in the proposal, a >> name-capable API doesn't imply that it be address-unable. > > I have a question here. How does a host know if its peer support the > name oriented sockets or not? A connection initiator that supports name-oriented sockets doesn't need to know whether the peer supports them or not: it just adds name informations, i.e. initiator name and target name, in options of its connection requests . A connection acceptor that doesn't support name-oriented sockets automatically ignores these name informations because they are in non-recognized options. A connection acceptor that supports name-oriented sockets determines whether a peer supports them when it finds, or doesn't find, name-information options in a connection request it receives. RD From scott.brim@gmail.com Thu Dec 3 05:48:09 2009 Return-Path: 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 5FE3F28C149 for ; Thu, 3 Dec 2009 05:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 DifeD3wtWrLT for ; Thu, 3 Dec 2009 05:48:08 -0800 (PST) Received: from mail-vw0-f193.google.com (mail-vw0-f193.google.com [209.85.212.193]) by core3.amsl.com (Postfix) with ESMTP id 781DC28C0EA for ; Thu, 3 Dec 2009 05:48:08 -0800 (PST) Received: by vws31 with SMTP id 31so588263vws.29 for ; Thu, 03 Dec 2009 05:47:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=+Grmvg+LP1cOSv1xnaUCjJxRNIXS2vqS0u6za6fh7oc=; b=QBTohCKWb4c0I1kaMy83S1wtY++/9qoW5Z9SQXkf9ZfQRzPNZ2ISCm1f7IGrlxflQ3 bfRyKrOhBqQwptZK9KmvwtjdGODYa9MRhedn+/V4nzNR27lEvalnoTeffcNg/teFA9Rw h+eU8WQycwMtIgE97Q2CpOSUJMnbLWUZOwHOM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=SGf1XR3OJ8295WF0LnQeNKLgwhIU4dBMKiVSgtOxeAC5YS2CLp8X2O2j0zSBfTLRpO hez92qU155tJnqzgOpsXEJxtTi8vHIoUtbm5dVM+GlbhMYeU117RLeDrEREtfIqkUyO/ 2Elm2VKElVjPTjQL+rDYChTFT5+0ne5lXci4M= Received: by 10.220.123.105 with SMTP id o41mr1944970vcr.28.1259848077388; Thu, 03 Dec 2009 05:47:57 -0800 (PST) Received: from sbrim-mbp.local (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id 23sm4336619vws.5.2009.12.03.05.47.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Dec 2009 05:47:55 -0800 (PST) Message-ID: <4B17C187.8030505@gmail.com> Date: Thu, 03 Dec 2009 08:47:51 -0500 From: Scott Brim User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Joe Touch References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> <4B16980A.4@isi.edu> <4B16A197.8050902@isi.edu> <4B16B91C.6020409@isi.edu> <4B16BC36.80905@isi.edu> In-Reply-To: <4B16BC36.80905@isi.edu> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "multipathtcp@ietf.org List" , Christian Vogt Subject: Re: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 13:48:09 -0000 Joe Touch allegedly wrote on 12/02/2009 2:12 PM: > > > Laganier, Julien wrote: > ... >>>> No we're not. We still have the advantage that the initial connection >>>> can be established to the fastest IPv{4,6} endpoint. >>> Fastest? >>> >>> I think this means you leave the decision to another layer, but I >>> haven't heard anyone explain 'fastest' yet. >> For example, send SYN to a a couple of the addresses (v4 or v6) return >> in the DNS response, and only complete the TCP handshake with the >> address from which you received the first SYN-ACK. > > That gives you the fastest SYN-ACK time. Which has nothing to do with > many other desirable properties (largest BW, lowest data packet latency, > etc.) > > And that's already possible at the app layer, FWIW. > > Joe Joe, this is a "time and space" tradeoff. You quickly gather enough information to get _some_ decent connectivity, and then refine it as necessary over the life of the flow. From touch@ISI.EDU Thu Dec 3 07:16:40 2009 Return-Path: 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 62D5E3A68BE for ; Thu, 3 Dec 2009 07:16:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=-0.031, 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 OBrogZ2f-W9z for ; Thu, 3 Dec 2009 07:16:39 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 878653A62C1 for ; Thu, 3 Dec 2009 07:16:39 -0800 (PST) Received: from [192.168.1.43] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nB3FGDKE017107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Dec 2009 07:16:15 -0800 (PST) Message-ID: <4B17D63D.3050702@isi.edu> Date: Thu, 03 Dec 2009 07:16:13 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Scott Brim References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> <4B16980A.4@isi.edu> <4B16A197.8050902@isi.edu> <4B16B91C.6020409@isi.edu> <4B16BC36.80905@isi.edu> <4B17C187.8030505@gmail.com> In-Reply-To: <4B17C187.8030505@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 List" , Christian Vogt Subject: Re: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 15:16:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Scott Brim wrote: > Joe Touch allegedly wrote on 12/02/2009 2:12 PM: >> >> Laganier, Julien wrote: >> ... >>>>> No we're not. We still have the advantage that the initial connection >>>>> can be established to the fastest IPv{4,6} endpoint. >>>> Fastest? >>>> >>>> I think this means you leave the decision to another layer, but I >>>> haven't heard anyone explain 'fastest' yet. >>> For example, send SYN to a a couple of the addresses (v4 or v6) return >>> in the DNS response, and only complete the TCP handshake with the >>> address from which you received the first SYN-ACK. >> That gives you the fastest SYN-ACK time. Which has nothing to do with >> many other desirable properties (largest BW, lowest data packet latency, >> etc.) >> >> And that's already possible at the app layer, FWIW. >> >> Joe > > Joe, this is a "time and space" tradeoff. You quickly gather enough > information to get _some_ decent connectivity, and then refine it as > necessary over the life of the flow. What's being traded? My concern is that for TCP, this technique requires very careful implementation to maintain existing semantics - on which many apps rely - - and doesn't save much effort. For m-TCP, this technique might actually not be appropriate at all (see other posts). Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksX1jwACgkQE5f5cImnZrvyDACfTdVGtLkqXmjSNeALhNs46Axl xLoAnibtUH0gqpnpKcHB3UIICwaYdDcr =x22F -----END PGP SIGNATURE----- From touch@ISI.EDU Thu Dec 3 07:27:31 2009 Return-Path: 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 1810D28C108 for ; Thu, 3 Dec 2009 07:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3] 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 yrCVm-HZa3hs for ; Thu, 3 Dec 2009 07:27:30 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 603FF28C175 for ; Thu, 3 Dec 2009 07:27:30 -0800 (PST) Received: from [192.168.1.43] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nB3FR2KQ020152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Dec 2009 07:27:04 -0800 (PST) Message-ID: <4B17D8C6.5060506@isi.edu> Date: Thu, 03 Dec 2009 07:27:02 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> <4B1642BC.30508@free.fr> <4B1683ED.9090602@isi.edu> <4B177D24.8090505@free.fr> In-Reply-To: <4B177D24.8090505@free.fr> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "multipathtcp@ietf.org List" , Stuart Cheshire , Christian Vogt Subject: Re: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 15:27:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rémi Després wrote: > Joe Touch wrote : > >> Rémi Després wrote: > >>> Applications that may depend on successive connections to go to the same >>> host, they can use: >>> ConnectByName(name) which returns the chosen adr >>> Connect(adr) >>> Connect(adr) >>> Connect(adr) >> >> This cannot work for multipath TCP. > > I don't see why this would work less than what you described, namely: > adr = first(dns("name")) -- or adr = pickone(dns("name")) > connect(adr) > connect(adr) > connect(adr) Agreed - neither one works for multipath tcp. > It seems that,like in RFC 5533 sec 1.3 for Mip6, the adr that is > selected in the initial contact with the remote peer can be used as the > preserved upper layer identifier (ULID). Well, 5533 explains why: However, using a single 128-bit ULID doesn't provide seamless communication when that locator is unreachable. See [18] for further discussion of the application implications. I.e., Shim6 wasn't trying to address a scenario that multipath TCP is focusing on, namely the case where the original IP address disappears. That's *why* I keep raising the fate-sharing issue. Keep fate sharing and you keep TCP semantics. Ditch fate sharing and I have absolutely no idea why this would work. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksX2MUACgkQE5f5cImnZrsfkACgjd+EI+J0UPSnH9iqyHriZ8YE 4DMAoPyjHkGsoNRkucQN+cpWP1Alg8CH =CRCn -----END PGP SIGNATURE----- From julienl@qualcomm.com Thu Dec 3 07:39:35 2009 Return-Path: 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 0E3613A6A6F for ; Thu, 3 Dec 2009 07:39:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.657 X-Spam-Level: X-Spam-Status: No, score=-105.657 tagged_above=-999 required=5 tests=[AWL=0.942, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 ysgD4fd7fTMw for ; Thu, 3 Dec 2009 07:39:34 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 2683A3A693B for ; Thu, 3 Dec 2009 07:39:34 -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=1259854766; x=1291390766; 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:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Joe=20Touch=20,=20Scott=20Brim=20|CC:=20"multipathtcp@ietf.org=20List" =20,=0D=0A=20=20=20=20=20=20=20=20 Christian=20Vogt=0D=0A=09 |Date:=20Thu,=203=20Dec=202009=2007:39:22=20-0800 |Subject:=20RE:=20[multipathtcp]=20Fwd:=20[rrg]=20New=20P aper=20On=20Name-Oriented=20Sockets=0D=0A=20Interface |Thread-Topic:=20[multipathtcp]=20Fwd:=20[rrg]=20New=20Pa per=20On=20Name-Oriented=20Sockets=0D=0A=20Interface |Thread-Index:=20Acp0K6FMqDwZGmVVRKeUyuRAMh0bwwAAoBfA |Message-ID:=20|References:=20=0D=0A=09<3C622E25 -DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com>=0D=0A=09<4B0FB0AA .2060303@gmail.com>=09=0D=0A=09<4B159F27.4020008@isi.edu>=0D=0A=09=0D=0A=09<4B16980A.4@isi.edu>=0D=0A=09=0D=0A=09<4B16A197.8050902@isi.edu>=0D=0A=09=0D=0A=09<4B16B91C.6020409@isi.edu>=0D=0A=09=0D=0A=20<4B16BC36.80905@isi.edu>=20<4B17C18 7.8030505@gmail.com>=0D=0A=20<4B17D63D.3050702@isi.edu> |In-Reply-To:=20<4B17D63D.3050702@isi.edu> |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|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 400,1158,5820"=3B=20a=3D"28972871"; bh=KlAqkcfO0wwCwJ1N8YAUlheFOrV8BE06YYVuaoXYADA=; b=iN/AvrlccKsz1avBAyLAHEaKGcHZ+nq45IN7HCo4PUxVUwRlhTqPbzzX dt6VK4FWqao7IA7Vi8vEK2InATG/N2FJSvNZowQlcVMmRAcUXftAXQscu i9o2+5Br32k+ArjJUzL53DoolsTWnRiclvcAp3J3hnF53AbbANAxad3CF k=; X-IronPort-AV: E=McAfee;i="5400,1158,5820"; a="28972871" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 03 Dec 2009 07:39:25 -0800 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nB3FdPsc023056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Dec 2009 07:39:25 -0800 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nB3FdPV7017123 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 3 Dec 2009 07:39:25 -0800 Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 3 Dec 2009 07:39:25 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Thu, 3 Dec 2009 07:39:24 -0800 From: "Laganier, Julien" To: Joe Touch , Scott Brim Date: Thu, 3 Dec 2009 07:39:22 -0800 Thread-Topic: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface Thread-Index: Acp0K6FMqDwZGmVVRKeUyuRAMh0bwwAAoBfA Message-ID: References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> <4B16980A.4@isi.edu> <4B16A197.8050902@isi.edu> <4B16B91C.6020409@isi.edu> <4B16BC36.80905@isi.edu> <4B17C187.8030505@gmail.com> <4B17D63D.3050702@isi.edu> In-Reply-To: <4B17D63D.3050702@isi.edu> 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" , Christian Vogt Subject: Re: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 15:39:35 -0000 Joe Touche wrote:=20 >=20 > Scott Brim wrote: > > Joe Touch allegedly wrote on 12/02/2009 2:12 PM: > >> > >> Laganier, Julien wrote: > >> ... > >>>>> No we're not. We still have the advantage that the initial > connection > >>>>> can be established to the fastest IPv{4,6} endpoint. > >>>> Fastest? > >>>> > >>>> I think this means you leave the decision to another layer, but I > >>>> haven't heard anyone explain 'fastest' yet. > >>> For example, send SYN to a a couple of the addresses (v4 or v6) > return > >>> in the DNS response, and only complete the TCP handshake with the > >>> address from which you received the first SYN-ACK. > >> That gives you the fastest SYN-ACK time. Which has nothing to do > with > >> many other desirable properties (largest BW, lowest data packet > latency, > >> etc.) > >> > >> And that's already possible at the app layer, FWIW. > >> > >> Joe > > > > Joe, this is a "time and space" tradeoff. You quickly gather enough > > information to get _some_ decent connectivity, and then refine it as > > necessary over the life of the flow. >=20 > What's being traded? >=20 > My concern is that for TCP, this technique requires very careful > implementation to maintain existing semantics - on which many apps rely > - - and doesn't save much effort. Joe, this is simple: An app using the new API will rely on the semantic of = the new API. Semantic of existing APIs and app using them are not affected = by the new API and its semantic. =20 =20 > For m-TCP, this technique might actually not be appropriate at all (see > other posts). Well, I haven't see a convincing argument substantiating this claim. --julien From remi.despres@free.fr Thu Dec 3 08:58:36 2009 Return-Path: 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 AB30D3A66B4 for ; Thu, 3 Dec 2009 08:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.364 X-Spam-Level: X-Spam-Status: No, score=-1.364 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3] 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 N0JsH3QpUurg for ; Thu, 3 Dec 2009 08:58:36 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id A9E103A672F for ; Thu, 3 Dec 2009 08:58:34 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 97ABCE081B8; Thu, 3 Dec 2009 17:58:20 +0100 (CET) Received: from [192.168.0.15] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 02FD7E0817D; Thu, 3 Dec 2009 17:58:14 +0100 (CET) Message-ID: <4B17EE25.4090300@free.fr> Date: Thu, 03 Dec 2009 17:58:13 +0100 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 1.5.0.14ubu (X11/20090105) MIME-Version: 1.0 To: Joe Touch References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> <4B1642BC.30508@free.fr> <4B1683ED.9090602@isi.edu> <4B177D24.8090505@free.fr> <4B17D8C6.5060506@isi.edu> In-Reply-To: <4B17D8C6.5060506@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "multipathtcp@ietf.org List" , Stuart Cheshire , Christian Vogt Subject: Re: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 16:58:36 -0000 Joe Touch wrote : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Rémi Després wrote: >> Joe Touch wrote : >> >>> Rémi Després wrote: >>>> Applications that may depend on successive connections to go to the same >>>> host, they can use: >>>> ConnectByName(name) which returns the chosen adr >>>> Connect(adr) >>>> Connect(adr) >>>> Connect(adr) >>> This cannot work for multipath TCP. >> I don't see why this would work less than what you described, namely: >> adr = first(dns("name")) -- or adr = pickone(dns("name")) >> connect(adr) >> connect(adr) >> connect(adr) > > Agreed - neither one works for multipath tcp. > >> It seems that,like in RFC 5533 sec 1.3 for Mip6, the adr that is >> selected in the initial contact with the remote peer can be used as the >> preserved upper layer identifier (ULID). > > Well, 5533 explains why: > > However, using a single 128-bit ULID doesn't provide seamless > communication when that locator is unreachable. See [18] for further > discussion of the application implications. Thanks for the reference. > I.e., Shim6 wasn't trying to address a scenario that multipath TCP is > focusing on, namely the case where the original IP address disappears. SCTP does work if the original address disappears, and mptcp should do the same. The list of currently valid locators is continuously kept updated by the transport protocol itself. Concerns expressed in [18] apply to Shim6, and to other contexts where current connections are not known but, in my understanding, not to SCTP and mptcp where they are available. RD > > That's *why* I keep raising the fate-sharing issue. Keep fate sharing > and you keep TCP semantics. Ditch fate sharing and I have absolutely no > idea why this would work. > > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > > iEYEARECAAYFAksX2MUACgkQE5f5cImnZrsfkACgjd+EI+J0UPSnH9iqyHriZ8YE > 4DMAoPyjHkGsoNRkucQN+cpWP1Alg8CH > =CRCn > -----END PGP SIGNATURE----- > From touch@ISI.EDU Thu Dec 3 22:29:01 2009 Return-Path: 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 154A03A685D for ; Thu, 3 Dec 2009 22:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.655 X-Spam-Level: X-Spam-Status: No, score=-1.655 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3] 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 9ReqU6qXml1W for ; Thu, 3 Dec 2009 22:28:59 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 25BB83A67E1 for ; Thu, 3 Dec 2009 22:28:58 -0800 (PST) Received: from [75.208.86.151] (151.sub-75-208-86.myvzw.com [75.208.86.151]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nB46SUW6004764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Dec 2009 22:28:33 -0800 (PST) Message-ID: <4B1876E2.2030105@isi.edu> Date: Thu, 03 Dec 2009 18:41:38 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> <4B1642BC.30508@free.fr> <4B1683ED.9090602@isi.edu> <4B177D24.8090505@free.fr> <4B17D8C6.5060506@isi.edu> <4B17EE25.4090300@free.fr> In-Reply-To: <4B17EE25.4090300@free.fr> 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" , Stuart Cheshire , Christian Vogt Subject: Re: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 06:29:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ... >>> It seems that,like in RFC 5533 sec 1.3 for Mip6, the adr that is >>> selected in the initial contact with the remote peer can be used as the >>> preserved upper layer identifier (ULID). >> >> Well, 5533 explains why: >> >> However, using a single 128-bit ULID doesn't provide seamless >> communication when that locator is unreachable. See [18] for further >> discussion of the application implications. > > Thanks for the reference. > >> I.e., Shim6 wasn't trying to address a scenario that multipath TCP is >> focusing on, namely the case where the original IP address disappears. > > SCTP does work if the original address disappears, and mptcp should > do the same. The list of currently valid locators is continuously > kept updated by the transport protocol itself. Concerns expressed in > [18] apply to Shim6, and to other contexts where current connections > are not known but, in my understanding, not to SCTP and mptcp where > they are available. So how do you know the difference in mptcp between trying to open a connection to the old IP (which is gone, but still used as the ULID for existing connections) and the new IP (e.g., whomever now has that IP address now, since it may have been reassigned for all you know)? You can't have it both ways using just an IP address as ULID, and you need to have it both ways or else *any* old connection to an IP address that is no longer where it was when you started is unreachable as a new location until ALL old connections go away. That's a bad kind of fate sharing, IMO. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksYduEACgkQE5f5cImnZrsQiACg2fpVJ/MtRtwi3IM9/SCF9mO0 feYAoJWnqUvZgJLz+R3f7xgvkK4uJ0io =kesC -----END PGP SIGNATURE----- From remi.despres@free.fr Fri Dec 4 02:08:26 2009 Return-Path: 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 A424D3A68B3 for ; Fri, 4 Dec 2009 02:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.663 X-Spam-Level: X-Spam-Status: No, score=-1.663 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] 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 Dhva44y3vG-r for ; Fri, 4 Dec 2009 02:08:26 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id B6CD53A67AF for ; Fri, 4 Dec 2009 02:08:24 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id B2116E080ED; Fri, 4 Dec 2009 11:08:10 +0100 (CET) Received: from [192.168.0.15] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 2220AE08013; Fri, 4 Dec 2009 11:08:05 +0100 (CET) Message-ID: <4B18DF84.2000708@free.fr> Date: Fri, 04 Dec 2009 11:08:04 +0100 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 1.5.0.14ubu (X11/20090105) MIME-Version: 1.0 To: Joe Touch References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> <4B1642BC.30508@free.fr> <4B1683ED.9090602@isi.edu> <4B177D24.8090505@free.fr> <4B17D8C6.5060506@isi.edu> <4B17EE25.4090300@free.fr> <4B1876E2.2030105@isi.edu> In-Reply-To: <4B1876E2.2030105@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "multipathtcp@ietf.org List" , Stuart Cheshire , Christian Vogt Subject: Re: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 10:08:26 -0000 Joe Touch a écrit : > So how do you know the difference in mptcp between trying to open a > connection to the old IP (which is gone, but still used as the ULID for > existing connections) and the new IP (e.g., whomever now has that IP > address now, since it may have been reassigned for all you know)? During an mptcp connection, each endpoint keeps the other endpoint informed of its currently valid address set. Only an address in such a set may be used as IP address of a new mptcp path to be established. In TCP connection requests other than the first one of an mptcp connection, mptcp ULIDs, i.e. IP addresses of the initial TCP connection must be conveyed in some form data (in a TCP option or, better IMO but this is a different discussion, in an mptcp field at the beginning of the TCP payload). For a new mptcp session, valid IP addresses for a given name must be obtained from the DNS. (For obsolete addresses not to remain in name-to-address-set-mapping caches, TTLs of these addresses must be consistent with how quickly these addresses may change.) Anything wrong with this? RD From touch@ISI.EDU Fri Dec 4 16:31:40 2009 Return-Path: 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 DBBC43A68DD for ; Fri, 4 Dec 2009 16:31:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 cN3mMoHET-ve for ; Fri, 4 Dec 2009 16:31:40 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 240713A68DF for ; Fri, 4 Dec 2009 16:31:40 -0800 (PST) Received: from [75.210.133.176] (176.sub-75-210-133.myvzw.com [75.210.133.176]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nB50V54a027147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 4 Dec 2009 16:31:09 -0800 (PST) Message-ID: <4B19A9C9.6050401@isi.edu> Date: Fri, 04 Dec 2009 16:31:05 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> <4B1642BC.30508@free.fr> <4B1683ED.9090602@isi.edu> <4B177D24.8090505@free.fr> <4B17D8C6.5060506@isi.edu> <4B17EE25.4090300@free.fr> <4B1876E2.2030105@isi.edu> <4B18DF84.2000708@free.fr> In-Reply-To: <4B18DF84.2000708@free.fr> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "multipathtcp@ietf.org List" , Stuart Cheshire , Christian Vogt Subject: Re: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2009 00:31:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rémi Després wrote: > Joe Touch a écrit : > >> So how do you know the difference in mptcp between trying to open a >> connection to the old IP (which is gone, but still used as the ULID for >> existing connections) and the new IP (e.g., whomever now has that IP >> address now, since it may have been reassigned for all you know)? > > During an mptcp connection, each endpoint keeps the other endpoint > informed of its currently valid address set. > Only an address in such a set may be used as IP address of a new mptcp > path to be established. > In TCP connection requests other than the first one of an mptcp > connection, mptcp ULIDs, i.e. IP addresses of the initial TCP connection > must be conveyed in some form data (in a TCP option or, better IMO but > this is a different discussion, in an mptcp field at the beginning of > the TCP payload). > > For a new mptcp session, valid IP addresses for a given name must be > obtained from the DNS. > (For obsolete addresses not to remain in name-to-address-set-mapping > caches, TTLs of these addresses must be consistent with how quickly > these addresses may change.) > > Anything wrong with this? Going back to the DNS for subsequent mptcps means that you can't correlate two different mptcp's as "going to the same place". You want to just use an IP address to do that. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksZqckACgkQE5f5cImnZru8DACg4UZOgbVebMJZObEfGYAKtOzx wyQAoL5exuNcLYWRgIzIlPAcAQNlI/Nz =S+wy -----END PGP SIGNATURE----- From remi.despres@free.fr Sat Dec 5 01:31:06 2009 Return-Path: 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 143DF3A6843 for ; Sat, 5 Dec 2009 01:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.683 X-Spam-Level: X-Spam-Status: No, score=-1.683 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] 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 Ssd5Tms9BWZE for ; Sat, 5 Dec 2009 01:31:05 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id C81203A677E for ; Sat, 5 Dec 2009 01:31:03 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 05971E080BD; Sat, 5 Dec 2009 10:30:48 +0100 (CET) Received: from [192.168.0.15] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id D8F3BE08114; Sat, 5 Dec 2009 10:30:45 +0100 (CET) Message-ID: <4B1A283F.6010100@free.fr> Date: Sat, 05 Dec 2009 10:30:39 +0100 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 1.5.0.14ubu (X11/20090105) MIME-Version: 1.0 To: Joe Touch References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> <4B1642BC.30508@free.fr> <4B1683ED.9090602@isi.edu> <4B177D24.8090505@free.fr> <4B17D8C6.5060506@isi.edu> <4B17EE25.4090300@free.fr> <4B1876E2.2030105@isi.edu> <4B18DF84.2000708@free.fr> <4B19A9C9.6050401@isi.edu> In-Reply-To: <4B19A9C9.6050401@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "multipathtcp@ietf.org List" , Stuart Cheshire , Christian Vogt Subject: Re: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2009 09:31:06 -0000 Joe Touch wrote : > Rémi Després wrote: >> During an mptcp connection, each endpoint keeps the other endpoint >> informed of its currently valid address set. >> Only an address in such a set may be used as IP address of a new mptcp >> path to be established. >> In TCP connection requests other than the first one of an mptcp >> connection, mptcp ULIDs, i.e. IP addresses of the initial TCP connection >> must be conveyed in some form data (in a TCP option or, better IMO but >> this is a different discussion, in an mptcp field at the beginning of >> the TCP payload). >> >> For a new mptcp session, valid IP addresses for a given name must be >> obtained from the DNS. >> (For obsolete addresses not to remain in name-to-address-set-mapping >> caches, TTLs of these addresses must be consistent with how quickly >> these addresses may change.) >> >> Anything wrong with this? > > Going back to the DNS for subsequent mptcps means that you can't > correlate two different mptcp's as "going to the same place". You want > to just use an IP address to do that. The goal you express is different from just permitting an application-layer TCP connection to be, at the transport layer, implemented as a group of parallel TCP connections (to increase performance and resilience, in my understanding the specific goal of mptcp). For this new goal, one possible approach, also applicable to ordinary TCP, is that the ConnectByName has an option whereby the application proposes an IP address. If this address is still cached, or present in the set of addresses obtained with a new DNS query, this address is used. Otherwise the connection fails. In another approach, which better separates layers, the ConnectByName has an option to request that the the address to be used be the same as in the previous connection to the same name. The transport layer, which memorizes which address was last used by this application for this name, does the job (cache test, new DNS query if needed). RD From christian.vogt@ericsson.com Sat Dec 5 17:45:42 2009 Return-Path: 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 EDDC13A6947 for ; Sat, 5 Dec 2009 17:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Lg5M1kW6cBoA for ; Sat, 5 Dec 2009 17:45:42 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 2D2F03A677C for ; Sat, 5 Dec 2009 17:45:41 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id nB61jgPc011227; Sat, 5 Dec 2009 19:45:42 -0600 Received: from [155.53.229.75] (147.117.20.212) by eusaamw0711.eamcs.ericsson.se (147.117.20.179) with Microsoft SMTP Server id 8.1.375.2; Sat, 5 Dec 2009 20:45:27 -0500 MIME-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset="us-ascii" From: Christian Vogt In-Reply-To: <4B19A9C9.6050401@isi.edu> Date: Sat, 5 Dec 2009 17:46:53 -0800 Content-Transfer-Encoding: 7bit Message-ID: References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> <4B1642BC.30508@free.fr> <4B1683ED.9090602@isi.edu> <4B177D24.8090505@free.fr> <4B17D8C6.5060506@isi.edu> <4B17EE25.4090300@free.fr> <4B1876E2.2030105@isi.edu> <4B18DF84.2000708@free.fr> <4B19A9C9.6050401@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1077) Cc: Multipath TCP Mailing List , Stuart Cheshire Subject: Re: [multipathtcp] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 01:45:43 -0000 On Dec 4, 2009, Joe Touch wrote: > Going back to the DNS for subsequent mptcps means that you can't > correlate two different mptcp's as "going to the same place". You want > to just use an IP address to do that. Joe - In an Internet where mobility and multi-homing is becoming increasingly common, using an IP address as a host reference is of decreasing utility. Host-specific names would be the more useful host references. Applications that maintain state across sessions should exchange host-specific names, resolvable via the DNS, to enable future sessions between the same host pair. Certainly, to contact a host without DNS-resolvable name, applications must necessarily try to connect to specific IP addresses. Yet this does not mean that sessions have to be bound to a specific IP address pair for their entire lifetime. A more powerful alternative would be to derive names from IP addresses, and endow those with the semantics: "The host which used the underlying IP address at the time of session establishment." Then, sessions established with such names can continue even if the IP address pair used during session establishment becomes defunct. Note that applications are guaranteed to be aware of the semantics of IP-address-derived names, as they have explicitly selected a name-based sockets interface that supports those. The paper being discussed uses IP-address-derived names as well. - Christian From christian.vogt@ericsson.com Sat Dec 5 17:55:39 2009 Return-Path: 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 A7D053A696B for ; Sat, 5 Dec 2009 17:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.438 X-Spam-Level: X-Spam-Status: No, score=-6.438 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 wOhjECfng08z for ; Sat, 5 Dec 2009 17:55:39 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id E177A3A6962 for ; Sat, 5 Dec 2009 17:55:38 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id nB61te0W012051; Sat, 5 Dec 2009 19:55:40 -0600 Received: from [155.53.229.75] (147.117.20.212) by eusaamw0711.eamcs.ericsson.se (147.117.20.179) with Microsoft SMTP Server id 8.1.375.2; Sat, 5 Dec 2009 20:55:24 -0500 MIME-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset="iso-8859-1" From: Christian Vogt In-Reply-To: <4B178AFE.3020309@free.fr> Date: Sat, 5 Dec 2009 17:56:51 -0800 Content-Transfer-Encoding: quoted-printable Message-ID: References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> <4B1642BC.30508@free.fr> <4B178AFE.3020309@free.fr> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1077) Cc: Multipath TCP Mailing List , Stuart Cheshire Subject: Re: [multipathtcp] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 01:55:39 -0000 On Dec 3, 2009, R=E9mi Despr=E9s wrote: >> I have a question here. How does a host know if its peer support the >> name oriented sockets or not? >=20 > A connection initiator that supports name-oriented sockets doesn't = need=20 > to know whether the peer supports them or not [...] This is correct as long as you don't support IP address updates, i.e., mobility or multi-homing. IP address updates require bilateral support, because both peers must switch to a new IP address pair in a coordinated manner. This is why hosts should indeed be able to detect their peer's support of name-based sockets. The paper utilizes a bidirectional name exchange at the beginning of a session for this purpose. - Christian From touch@ISI.EDU Sat Dec 5 17:58:49 2009 Return-Path: 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 385703A696B for ; Sat, 5 Dec 2009 17:58:49 -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=[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 MG4n5W+cpZqE for ; Sat, 5 Dec 2009 17:58:48 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 7CC653A6962 for ; Sat, 5 Dec 2009 17:58:48 -0800 (PST) Received: from [128.9.176.75] (c3-vpn4.isi.edu [128.9.176.75] (may be forged)) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id nB61vv5j017272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 5 Dec 2009 17:57:58 -0800 (PST) Message-ID: <4B1B0FA4.7010303@isi.edu> Date: Sat, 05 Dec 2009 17:57:56 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christian Vogt References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> <4B1642BC.30508@free.fr> <4B1683ED.9090602@isi.edu> <4B177D24.8090505@free.fr> <4B17D8C6.5060506@isi.edu> <4B17EE25.4090300@free.fr> <4B1876E2.2030105@isi.edu> <4B18DF84.2000708@free.fr> <4B19A9C9.6050401@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: nB61vv5j017272 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Multipath TCP Mailing List , Stuart Cheshire Subject: Re: [multipathtcp] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 01:58:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christian Vogt wrote: > On Dec 4, 2009, Joe Touch wrote: > >> Going back to the DNS for subsequent mptcps means that you can't >> correlate two different mptcp's as "going to the same place". You want >> to just use an IP address to do that. > > > Joe - > > In an Internet where mobility and multi-homing is becoming increasingly > common, using an IP address as a host reference is of decreasing > utility. I could not agree more, but I think that this goes too far outside the scope of TCP to still be called TCP if that's the case. As you note, there are challenges with shifting over to a name-based model, and those challenges not only change the TCP API, but also require changes in the DNS API as well. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksbD6QACgkQE5f5cImnZrs//gCdELmEnI9u+sik8BfjhOMSa2+W H24AnRd5uQ/1xpnycsRWDj2uuY4GWq2C =/dUI -----END PGP SIGNATURE----- From christian.vogt@ericsson.com Sat Dec 5 20:01:09 2009 Return-Path: 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 5F8EC3A68D5 for ; Sat, 5 Dec 2009 20:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 2e2kCzP6CmkM for ; Sat, 5 Dec 2009 20:01:08 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 82AD33A68A9 for ; Sat, 5 Dec 2009 20:01:08 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id nB64180v003447; Sat, 5 Dec 2009 22:01:08 -0600 Received: from [155.53.229.75] (147.117.20.212) by eusaamw0711.eamcs.ericsson.se (147.117.20.179) with Microsoft SMTP Server id 8.1.375.2; Sat, 5 Dec 2009 23:00:53 -0500 MIME-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset="us-ascii" From: Christian Vogt In-Reply-To: <4B1B0FA4.7010303@isi.edu> Date: Sat, 5 Dec 2009 20:02:19 -0800 Content-Transfer-Encoding: 7bit Message-ID: <7C062286-9AA9-465D-85BF-F32A3540E63F@ericsson.com> References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> <4B1642BC.30508@free.fr> <4B1683ED.9090602@isi.edu> <4B177D24.8090505@free.fr> <4B17D8C6.5060506@isi.edu> <4B17EE25.4090300@free.fr> <4B1876E2.2030105@isi.edu> <4B18DF84.2000708@free.fr> <4B19A9C9.6050401@isi.edu> <4B1B0FA4.7010303@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1077) Cc: Multipath TCP Mailing List , Stuart Cheshire Subject: Re: [multipathtcp] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 04:01:09 -0000 On Dec 5, 2009, Joe Touch wrote: >> In an Internet where mobility and multi-homing is becoming increasingly >> common, using an IP address as a host reference is of decreasing >> utility. > > I could not agree more, but I think that this goes too far outside the > scope of TCP to still be called TCP if that's the case. Whether we call it "TCP" or something else becomes irrelevant once we introduce a new API, because the new API guarantees that applications are aware of the changes we introduce. More challenging is, in my opinion, the deployment of multi-path TCP in an application-transparent manner, as this indeed requires adhering to the original TCP semantics. > As you note, there are challenges with shifting over to a name-based > model, and those challenges not only change the TCP API, but also > require changes in the DNS API as well. I don't see why changes to the DNS API would be necessary. And regarding changes to the socket API: Yes, this is challenging. But I am optimistic that it can be done. The popularity of existing name- based socket API abstractions, as in Java or MacOS X, demonstrates this. - Christian From remi.despres@free.fr Mon Dec 7 03:13:14 2009 Return-Path: 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 7FBCD28C14A for ; Mon, 7 Dec 2009 03:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] 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 KCLxd+M+ntQP for ; Mon, 7 Dec 2009 03:13:13 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 34BC33A6A26 for ; Mon, 7 Dec 2009 03:13:10 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 014A7E081C8; Mon, 7 Dec 2009 12:12:55 +0100 (CET) Received: from [192.168.0.15] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id BC0A3E08180; Mon, 7 Dec 2009 12:12:52 +0100 (CET) Message-ID: <4B1CE32D.50006@free.fr> Date: Mon, 07 Dec 2009 12:12:45 +0100 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 1.5.0.14ubu (X11/20090105) MIME-Version: 1.0 To: Christian Vogt References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> <4B1642BC.30508@free.fr> <4B178AFE.3020309@free.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Multipath TCP Mailing List , Stuart Cheshire Subject: Re: [multipathtcp] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 11:13:14 -0000 Christian Vogt a écrit : > On Dec 3, 2009, Rémi Després wrote: > >>> I have a question here. How does a host know if its peer support the >>> name oriented sockets or not? >> A connection initiator that supports name-oriented sockets doesn't need >> to know whether the peer supports them or not [...] > > > This is correct as long as you don't support IP address updates, i.e., > mobility or multi-homing. During the connection establishment handshake, yes it is useful that both ends exchange information about their capabilities, in particular about mobility and multihoming support. > IP address updates require bilateral support, > because both peers must switch to a new IP address pair in a coordinated > manner. This is why hosts should indeed be able to detect their peer's > support of name-based sockets. > The paper utilizes a bidirectional name > exchange at the beginning of a session for this purpose. After the initial exchange of addresses, it is still unclear to me whether it is sufficient that both ends become aware of their support of mobility, and/or multihoming, or whether they have also to be aware of their support of name-based sockets. If possible, keeping orthogonality of these features is IMHO preferable. RD From jav@sics.se Mon Dec 7 03:35:03 2009 Return-Path: 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 9C31328C0DC for ; Mon, 7 Dec 2009 03:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.46 X-Spam-Level: X-Spam-Status: No, score=-0.46 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] 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 DuGvxByfz2+T for ; Mon, 7 Dec 2009 03:35:02 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id BA7843A67AE for ; Mon, 7 Dec 2009 03:35:02 -0800 (PST) Received: from [193.10.66.36] (bit.sics.se [193.10.66.36]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 07D9740128; Mon, 7 Dec 2009 12:34:51 +0100 (CET) From: Javier Ubillos To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4B1CE32D.50006@free.fr> References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> <4B1642BC.30508@free.fr> <4B178AFE.3020309@free.fr> <4B1CE32D.50006@free.fr> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-5ShDSRev+eVRTA0OXaen" Date: Mon, 07 Dec 2009 12:34:51 +0100 Message-ID: <1260185691.3039.4.camel@bit> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Cc: Multipath TCP Mailing List , Stuart Cheshire , Christian Vogt Subject: Re: [multipathtcp] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 11:35:03 -0000 --=-5ShDSRev+eVRTA0OXaen Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2009-12-07 at 12:12 +0100, R=C3=A9mi Despr=C3=A9s wrote: >=20 > After the initial exchange of addresses, it is still unclear to me=20 > whether it is sufficient that both ends become aware of their support > of=20 > mobility, and/or multihoming, or whether they have also to be aware > of=20 > their support of name-based sockets. >=20 > If possible, keeping orthogonality of these features is IMHO > preferable.=20 Exchange of addresses as in exchange of names? If the names are exchanged, it's already established that both ends support the name-based sockets. Also, the mechanism of name-exchange is an good and easy platform for capability negotiations. Simply (somehow) append capability information/preferences to the name option. // Javier --=-5ShDSRev+eVRTA0OXaen Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAksc6FkACgkQGBo5FLRz4gp3/ACeNpOs4kDMetwOA8TwCc0EQz8H A74AoKr0DIBH4a7Rb9EJZmC8nCk6p3Co =PSrK -----END PGP SIGNATURE----- --=-5ShDSRev+eVRTA0OXaen-- From remi.despres@free.fr Mon Dec 7 08:15:32 2009 Return-Path: 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 B79D928C1B0 for ; Mon, 7 Dec 2009 08:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.694 X-Spam-Level: X-Spam-Status: No, score=-1.694 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] 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 68Y-jwDU9489 for ; Mon, 7 Dec 2009 08:15:32 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id B672628C1BF for ; Mon, 7 Dec 2009 08:15:30 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id D8B78E08017; Mon, 7 Dec 2009 17:15:15 +0100 (CET) Received: from [192.168.0.15] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 99171E08002; Mon, 7 Dec 2009 17:15:12 +0100 (CET) Message-ID: <4B1D2A0B.8050707@free.fr> Date: Mon, 07 Dec 2009 17:15:07 +0100 From: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= User-Agent: Thunderbird 1.5.0.14ubu (X11/20090105) MIME-Version: 1.0 To: Javier Ubillos References: <3C622E25-DFCA-48A4-A95C-E0F6BABEFD6D@nokia.com> <4B0FB0AA.2060303@gmail.com> <4B159F27.4020008@isi.edu> <4B1642BC.30508@free.fr> <4B178AFE.3020309@free.fr> <4B1CE32D.50006@free.fr> <1260185691.3039.4.camel@bit> In-Reply-To: <1260185691.3039.4.camel@bit> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Multipath TCP Mailing List , Stuart Cheshire , Christian Vogt Subject: Re: [multipathtcp] New Paper On Name-Oriented Sockets Interface X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 16:15:32 -0000 Javier Ubillos a écrit : > On Mon, 2009-12-07 at 12:12 +0100, Rémi Després wrote: >> After the initial exchange of addresses, it is still unclear to me >> whether it is sufficient that both ends become aware of their support >> of >> mobility, and/or multihoming, or whether they have also to be aware >> of >> their support of name-based sockets. >> >> If possible, keeping orthogonality of these features is IMHO >> preferable. > > Exchange of addresses as in exchange of names? The point is about addresses. They can be exchanged even if the connection acceptor doesn't support name-capable sockets. > If the names are exchanged, it's already established that both ends > support the name-based sockets. Right. > Also, the mechanism of name-exchange is an good and easy platform for > capability negotiations. Simply (somehow) append capability > information/preferences to the name option. No objection, but multihoming and mobility already exist, without relationship with name-capable sockets. SCTP and NEMO, for example, should need no change to work in combination with name-capable sockets. Unless we prefer to mix problems, name-capable sockets should IMHO only be sockets where names may be used in place of addresses. RD From philip.eardley@bt.com Thu Dec 10 07:24:53 2009 Return-Path: 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 E42D03A683B for ; Thu, 10 Dec 2009 07:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Thv1rk5wNCJ6 for ; Thu, 10 Dec 2009 07:24:49 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 618A63A6405 for ; Thu, 10 Dec 2009 07:24:48 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2009 15:11:31 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA79AB.0DD84381" Date: Thu, 10 Dec 2009 15:11:31 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363B91@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MPTCP (virtual) Interim meeting Thread-Index: Acp5qwGETV3M/K5jRJWkCYS9CeFVtQ== From: To: X-OriginalArrivalTime: 10 Dec 2009 15:11:31.0895 (UTC) FILETIME=[0E406470:01CA79AB] Subject: [multipathtcp] MPTCP (virtual) Interim meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 15:24:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA79AB.0DD84381 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable It's been suggested to have an interim meeting, by audio etc - not face-to-face. This seems a good idea to us (shout if you disagree). We'd propose to hold it sometime the last week or Jan or the first week of Feb. Please fill in the doodle with your availability if you'd like to join the meeting http://doodle.com/am4vnuzepuw7fzrp Proposal is that the time will be ~3pm or 4pm GMT for 2-3 hours. This is on the assumption that most of the people on the list are in Europe or America. Please let us know if this time doesn't suit you (by email or leave a comment on doodle). The agenda would be to make progress /resolve some of the open issues. We'd need to firm up early in the new year which issues to discuss - as clearly the agenda needs to be out well in advance.=20 Thanks, Phil & Yoshifumi. =20 ------_=_NextPart_001_01CA79AB.0DD84381 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable MPTCP (virtual) Interim meeting

It's been suggested to have an interim = meeting, by audio etc - not face-to-face. This seems a good idea to us = (shout if you disagree).

We'd propose to hold it sometime the = last week or Jan or the first week of Feb.
Please fill in the doodle with your = availability if you'd like to join the meeting http://doodle.com/am4vnuzepuw7fzrp

Proposal is that the time will be ~3pm = or 4pm GMT for 2-3 hours. This is on the assumption that most of the = people on the list are in Europe or America. Please let us know if this = time doesn’t suit you (by email or leave a comment on = doodle).

The agenda would be to make progress = /resolve some of the open issues. We'd need to firm up early in the new = year which issues to discuss - as clearly the agenda needs to be out = well in advance.

Thanks,
Phil & Yoshifumi. 

------_=_NextPart_001_01CA79AB.0DD84381-- From philip.eardley@bt.com Fri Dec 11 03:58:35 2009 Return-Path: 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 583663A6AB8 for ; Fri, 11 Dec 2009 03:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.579, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_ASCII0=1.5, RCVD_IN_DNSWL_LOW=-1] 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 UdUXkq+C7tk4 for ; Fri, 11 Dec 2009 03:58:30 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 6A8C03A67EC for ; Fri, 11 Dec 2009 03:58:30 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Dec 2009 11:58:17 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA7A59.39B10B13" Date: Fri, 11 Dec 2009 11:58:17 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363B96@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC06363B91@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CHANGE: MPTCP (virtual) Interim meeting Thread-Index: Acp5qwGETV3M/K5jRJWkCYS9CeFVtQArfD9g From: To: X-OriginalArrivalTime: 11 Dec 2009 11:58:17.0499 (UTC) FILETIME=[39DDB6B0:01CA7A59] Subject: [multipathtcp] CHANGE: MPTCP (virtual) Interim meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 11:58:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA7A59.39B10B13 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable There have been several requests for the second week of Feb. So i've extended the doodle to add this week in as well. sorry for the people who've already filled it in, please can you update with this week as well thanks phil. -----Original Message----- From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: 10 December 2009 15:12 To: multipathtcp@ietf.org Subject: [multipathtcp] MPTCP (virtual) Interim meeting =09 =09 It's been suggested to have an interim meeting, by audio etc - not face-to-face. This seems a good idea to us (shout if you disagree). We'd propose to hold it sometime the last week or Jan or the first week of Feb.=20 Please fill in the doodle with your availability if you'd like to join the meeting http://doodle.com/am4vnuzepuw7fzrp =20 Proposal is that the time will be ~3pm or 4pm GMT for 2-3 hours. This is on the assumption that most of the people on the list are in Europe or America. Please let us know if this time doesn't suit you (by email or leave a comment on doodle). The agenda would be to make progress /resolve some of the open issues. We'd need to firm up early in the new year which issues to discuss - as clearly the agenda needs to be out well in advance.=20 Thanks,=20 Phil & Yoshifumi. =20 ------_=_NextPart_001_01CA7A59.39B10B13 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
There=20 have been several requests for the second week of Feb. So i've extended = the=20 doodle to add this week in as well. sorry for the people who've already = filled=20 it in, please can you update with this week as well
thanks
phil.
-----Original Message-----
From:=20 multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On=20 Behalf Of philip.eardley@bt.com
Sent: 10 December 2009=20 15:12
To: multipathtcp@ietf.org
Subject: = [multipathtcp]=20 MPTCP (virtual) Interim meeting

It's been suggested to have an interim = meeting, by=20 audio etc - not face-to-face. This seems a good idea to us (shout if = you=20 disagree).

We'd propose to hold it sometime the = last week or=20 Jan or the first week of Feb.
Please fill=20 in the doodle with your availability if you'd like to join the meeting = http://doodle.com/am4vnuzepuw7fzrp

Proposal is that the time will be ~3pm = or 4pm GMT=20 for 2-3 hours. This is on the assumption that most of the people on = the list=20 are in Europe or America. Please let us know if this time = doesn’t suit you (by=20 email or leave a comment on doodle).

The agenda would be to make progress = /resolve some=20 of the open issues. We'd need to firm up early in the new year which = issues to=20 discuss - as clearly the agenda needs to be out well in advance. =

Thanks,
Phil=20 & Yoshifumi. 

=00 ------_=_NextPart_001_01CA7A59.39B10B13-- From iljitsch@muada.com Mon Dec 14 04:06:13 2009 Return-Path: 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 D80243A681C for ; Mon, 14 Dec 2009 04:06:13 -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=[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 DxDrQQecN7ex for ; Mon, 14 Dec 2009 04:06:12 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id F38B63A68AB for ; Mon, 14 Dec 2009 04:05:44 -0800 (PST) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.224]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBEC4qfs037731 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Dec 2009 13:04:52 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <4B0D52D5.9090403@isi.edu> Date: Mon, 14 Dec 2009 13:05:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <58B2A4B2-F276-4E96-87FB-F8273FD78ED0@muada.com> References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> <4B0C607A.6060503@isi.edu> <4B0C6590.9010000@isi.edu> <4B0C6C13.2060103@isi.edu> <4B0C6FBE.40003@isi.edu> <4B0D52D5.9090403@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1077) Cc: "multipathtcp@ietf.org List" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 12:06:14 -0000 [I haven't been keeping up with this list, apologies if I make points = that were discussed previously.] On 25 nov 2009, at 16:52, Joe Touch wrote: >> Coming back to fate sharing of multipath connection and initial >> subflow: I would assume fate sharing will be a sysctl flag on the = host, That can only set the default, we need a socket option to do it per = application. >> a) connection doesn't go down with first subflow >> b) connection dies when local interface dies >> c) connection dies when subflow times out (this implies b) > These are interesting configuration parameters from an implementation > view, but from a protocol view, if we're talking about TCP, there are > only two cases: > a) connection goes down when the whole set of subflows goes down Yes, you still need to have a _session_ timeout. Somewhat related issue: do we explicitly close a session, or implicitly = by closing all subflows? The latter leads to long delays when a subflow = is down. > b) connection goes down when the first subflow goes down > What makes a subflow go down shouldn't be defined separately; We need to avoid sending data over broken subflows, though. > However, anything that would cause the original subflow to fail even > when tunneled over other interfaces still, IMO, needs to cause the = whole > set to go down. The key example is loss of the IP address associated > with the original flow - either when the interface goes down, or when > it's lost via failed DHCP renewals, or when it's otherwise explicitly > reconfigured. There are several issues here. But before we delve in: why didn't we = have this discussion in shim6, where the exact same problem is present? = And what about mobility? I agree that if a host loses an address, it should no longer send = packets that use that address in some way. So in the multiaddress MPTCP = case that means a subflow that uses that address will have to be = terminated when the address is removed. Note though, that some systems = remove addresses when the interface goes down. That in itself is no = reason to release the address. If a DHCP server or RA indicates that an = address may be used for X amount of time, you get to keep it X amount of = time, even if connectivity goes away, temporarily or difinitively, at = some point. But then the question is: what happens to other subflows? My answer: "if a tree falls in the forest, and all the people in the = forest are wearing headphones at maximum volume, did the tree fall?" The problem with a socket option to indicate care is that it's going to = take a long time for all apps to use this socket option, and we still = need a default behavior. I don't think it makes sense to make the = default behavior "care" because then you have to go out of your way to = not care, which by definition people don't do. Especially since it = requires thinking about how to set a socket option that will be unknown = on some systems for portable applications. However, we can deduce that applications care if they bind to a specific = address, or look up the address tied to the remote end of an incoming = session. If neither happens subflows can continue without trouble. By the way: we need to communicate the address loss event to the other = side so the other side can tear down the session if we lose our address = but don't care but the other side cares. Note also that although binding = to a listening address happens before the three-way handshake, looking = up the remote address may happen afterwards. Another class of applications is those that care about the addresses, = but are not bothered by change. For instance, I may log that I'm talking = to 192.0.2.1 but then when that address goes down and communication = continues using 10.0.0.1, I simply log the address addition/change and = all is well. So I think what we need: - mechanism to indicate that a session is bound to an address - mechanism to indicate that an address has been removed - mechanism to indicate "no address agility" (default =3D agility) - mechanism to indicate "no MPTCP" (default =3D MPTCP) Note that "no address agility" and "MPTCP" means that you can have = additional subflows using additional addresses, but only as long as the = primary addresses have reachability. I think this is similar to MIPv6, = where you need to return to the HoA at certain intervals. I don't think it's appropriate to explicitly track interface status in = TCP. If the packets get there you're up, if they don't you time out = eventually and then presumably you're down.= From julienl@qualcomm.com Mon Dec 14 08:39:20 2009 Return-Path: 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 D45A13A68DC for ; Mon, 14 Dec 2009 08:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.937 X-Spam-Level: X-Spam-Status: No, score=-102.937 tagged_above=-999 required=5 tests=[AWL=-1.578, BAYES_00=-2.599, 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 eZvFmpyqrvIn for ; Mon, 14 Dec 2009 08:39:19 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id CF2CA3A686E for ; Mon, 14 Dec 2009 08:39:19 -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=1260808747; x=1292344747; 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 |To:=20Iljitsch=20van=20Beijnum=20, =20Joe=20Touch=20|CC:=20"multipathtcp@ietf .org=20List"=20|Date:=20Mon,=2014 =20Dec=202009=2008:38:54=20-0800|Subject:=20RE:=20[multip athtcp]=20Multipath=20deployment=20and=20fate=20sharing |Thread-Topic:=20[multipathtcp]=20Multipath=20deployment =20and=20fate=20sharing|Thread-Index:=20Acp8tc/QrItNZmxTT VejT7gjgrOQUgAIupWg|Message-ID:=20 |References:=20=0D=0A=09<3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90 @mail.gmail.com>=0D=0A=09=0D=0A=09<20091123.092214.140617438.nishida@ sfc.wide.ad.jp>=0D=0A=09<48DA092B-F3BC-432E-A199-B265DDED 39DA@iki.fi>=0D=0A=09<3c3e3fca0911240434p4d95ec7an34615ae 218faa4f@mail.gmail.com>=0D=0A=09=0D=0A=09 =0D=0A=09<4B0C607A.6060503@isi.edu>=0D=0A=09=0D=0A=09<4B0C6590.9010000@isi.edu>=0D=0A=09=0D=0A=09<4B0C6C13.2060103@isi.edu>=0D=0A=09=0D=0A=09<4B0C6FBE.40003@isi.edu>=0D=0A=09=0D=0A =09=0D=0A=09=0D=0A=09<4B0D52D5.9090403@isi.edu>=20<58B2A4B2-F 276-4E96-87FB-F8273FD78ED0@muada.com>|In-Reply-To:=20<58B 2A4B2-F276-4E96-87FB-F8273FD78ED0@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=awMoJFZl+DxAjPX6FXX0HeYKW5Tvzqsk3B7v5FM2xXc=; b=FRVDAcCMyx5JZn0guHrJfzSFxGVpPgnLTXvKJjDvq4XnkId1vLEGP8yI rzpXTjWSODcvw8lsgNvIT+g0cUxzEsmQMQZIYWHK0NtuM+EClPa1Ws7mY DeMz8XYKjirhtleRbZQF1I1m8e94gM4oBgL5V3/x3RYvQjru5vG5waTRx U=; X-IronPort-AV: E=McAfee;i="5400,1158,5832"; a="29873287" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP; 14 Dec 2009 08:39:06 -0800 Received: from ironstorm.qualcomm.com (ironstorm.qualcomm.com [172.30.39.153]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nBEGcu9x025814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 14 Dec 2009 08:39:06 -0800 X-IronPort-AV: E=Sophos;i="4.47,395,1257148800"; d="scan'208";a="23133176" Received: from nasanexhub04.qualcomm.com (HELO nasanexhub04.na.qualcomm.com) ([129.46.134.222]) by ironstorm.qualcomm.com with ESMTP/TLS/RC4-MD5; 14 Dec 2009 08:38:56 -0800 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 14 Dec 2009 08:38:55 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Mon, 14 Dec 2009 08:38:55 -0800 From: "Laganier, Julien" To: Iljitsch van Beijnum , Joe Touch Date: Mon, 14 Dec 2009 08:38:54 -0800 Thread-Topic: [multipathtcp] Multipath deployment and fate sharing Thread-Index: Acp8tc/QrItNZmxTTVejT7gjgrOQUgAIupWg Message-ID: References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> <4B0C607A.6060503@isi.edu> <4B0C6590.9010000@isi.edu> <4B0C6C13.2060103@isi.edu> <4B0C6FBE.40003@isi.edu> <4B0D52D5.9090403@isi.edu> <58B2A4B2-F276-4E96-87FB-F8273FD78ED0@muada.com> In-Reply-To: <58B2A4B2-F276-4E96-87FB-F8273FD78ED0@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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 16:39:20 -0000 Hello Iljitsch, Iljitsch van Beijnum wrote: > > Joe Touch wrote: > > > > However, anything that would cause the original subflow to fail even=20 > > when tunneled over other interfaces still, IMO, needs to cause the=20 > > whole set to go down. The key example is loss of the IP address=20 > > associated with the original flow - either when the interface goes=20 > > down, or when it's lost via failed DHCP renewals, or when it's=20 > > otherwise explicitly reconfigured. > > There are several issues here. But before we delve in: why didn't we=20 > have this discussion in shim6, where the exact same problem is present? In the MPTCP fate sharing discussion there are two situations to consider: 1- a peer stop to use the original IP address but nobody else uses it 2- a peer stop to use the original IP address but somebody else starts to u= se it (e.g., address is re-allocated via DHCP) In SHIM6 only the situation #1 is likely to occur, because as Marcelo point= ed out earlier, SHIM6 security relies on the use of a specific type of addr= esses (Hash Based Addresses and Cryptographically Generated Addresses) whos= e size and random nature make them unlikely to ever collide, thus situation= #2 cannot happen in SHIM6. So SHIM6 decided that in situation #1 it was perfectly okay that a TCP conn= ection continue to work even though the IPv6 address to which the TCP conne= ction was originally bound (Upper Layer ID in SHIM6 terms) is no longer rea= chable/available. I tend to think that the same applies to MPTCP under situ= ation #1. If we were to base MPTCP security over IPv6 on the use of HBA's a= nd CGA's as well, we could guarantee that situation #2 doesn't occur, and t= hus be left to deal with situation #1 only and maintain same properties as = SHIM6, i.e. no fate sharing for IPv6. With IPv4 of course the situation would be different due to the IPv4 addres= s space exhaustion, presence of NATs, and DHCP allocation with short term l= eases. So in IPv4 we can't rule out situation #2, and thus we want to make = fate sharing the default IPv4.=20 Not a perfect situation of course, but one in which at least we provide bet= ter functionality where possible (with IPv6, by leveraging on its IID addre= ssing space size) and maintain existing functionality and semantic for the = other situations (with IPv4, with NATs and DHCP) --julien PS: it also makes MPTCP over IPv6 more attractive than MPTCP over IPv4 and = gives a good reason to migrate to IPv6 transports :)=20 From iljitsch@muada.com Mon Dec 14 08:56:21 2009 Return-Path: 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 9D5843A68F7 for ; Mon, 14 Dec 2009 08:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 DD2ztMnAQTby for ; Mon, 14 Dec 2009 08:56:20 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 8BEC33A6833 for ; Mon, 14 Dec 2009 08:56:20 -0800 (PST) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.224]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBEGtRg8040001 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Dec 2009 17:55:28 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: Date: Mon, 14 Dec 2009 17:55:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> <4B0C607A.6060503@isi.edu> <4B0C6590.9010000@isi.edu> <4B0C6C13.2060103@isi.edu> <4B0C6FBE.40003@isi.edu> <4B0D52D5.9090403@isi.edu> <58B2A4B2-F! 276-4E96-87FB-F8273FD78ED0@muada.com> To: "Laganier, Julien" X-Mailer: Apple Mail (2.1077) Cc: "multipathtcp@ietf.org List" , Joe Touch 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 16:56:21 -0000 On 14 dec 2009, at 17:38, Laganier, Julien wrote: > In the MPTCP fate sharing discussion there are two situations to = consider: > 1- a peer stop to use the original IP address but nobody else uses it > 2- a peer stop to use the original IP address but somebody else starts = to use it (e.g., address is re-allocated via DHCP) > In SHIM6 only the situation #1 is likely to occur, because as Marcelo = pointed out earlier, SHIM6 security relies on the use of a specific type = of addresses (Hash Based Addresses and Cryptographically Generated = Addresses) whose size and random nature make them unlikely to ever = collide, thus situation #2 cannot happen in SHIM6. Hm, yes. However, in the case of an address with an interface identifier = that comes from a MAC address with the U/L bit set to "unique" we = basically have the same situation as with Shim6 and HBA, except that the = uniqueness is by convention rather than cryptographically protected. But my point in my earlier message was that in a potential case 2 (might = be a case 1 but we can't be sure), after the valid lifetime of the = address expires, we should stop sending packets with the now invalid = address. Other subflows that use different addresses can continue from = the perspective of address uniqueness.=20 Now there is the second issue of whether it's ok to continue = communicating on different addresses when the originally chosen = addresses are no longer valid for reasons of conforming to application = expectations. There, my point was that we can do this without reservation if the = applications on both sides don't perform any API calls that reveal = they're especially interested in the addresses used for a session. So this leaves the situation where we know an address is no longer valid = and the application(s) are interested in the addresses. Eventually we = need to move to a situation where applications need to register their = wishes in this regard and allow MPTCP by default if they don't, because = the opposite situation isn't workable. However, it could be reasonable = to have an interim period during which the default is to make MPTCP = sessions bound to addresses that are no longer valid go down if the = applications have expressed interest in those addresses. > 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.=20 I don't see that. With NAT you don't know who you're going to encounter = behind a given address, anyway. Iljitsch= From touch@ISI.EDU Mon Dec 14 09:40:27 2009 Return-Path: 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 8D30C3A6A13 for ; Mon, 14 Dec 2009 09:40:27 -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 3C6osyLc1fpZ for ; Mon, 14 Dec 2009 09:40:26 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 9122F3A68F9 for ; Mon, 14 Dec 2009 09:40:26 -0800 (PST) Received: from [75.212.111.146] (146.sub-75-212-111.myvzw.com [75.212.111.146]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nBEHcs1R008637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Dec 2009 09:39:00 -0800 (PST) Message-ID: <4B26782D.9080907@isi.edu> Date: Mon, 14 Dec 2009 09:38:53 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> <4B0C607A.6060503@isi.edu> <4B0C6590.9010000@isi.edu> <4B0C6C13.2060103@isi.edu> <4B0C6FBE.40003@isi.edu> <4B0D52D5.9090403@isi.edu> <58B2A4B2-F276-4E96-87FB-F8273FD78ED0@muada.com> In-Reply-To: <58B2A4B2-F276-4E96-87FB-F8273FD78ED0@muada.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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 17:40:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Iljitsch van Beijnum wrote: ... > I agree that if a host loses an address, it should no longer send > packets that use that address in some way. So in the multiaddress MPTCP > case that means a subflow that uses that address will have to be > terminated when the address is removed. Note though, that some systems > remove addresses when the interface goes down. That in itself is no > reason to release the address. If a DHCP server or RA indicates that an > address may be used for X amount of time, you get to keep it X amount of > time, even if connectivity goes away, temporarily or difinitively, at > some point. DHCP assignments shouldn't override explicit interface actions. > But then the question is: what happens to other subflows? > > My answer: "if a tree falls in the forest, and all the people in the > forest are wearing headphones at maximum volume, did the tree fall?" > > The problem with a socket option to indicate care is that it's going > to take a long time for all apps to use this socket option, and we still > need a default behavior. IMO, you need to make the assumption that causes the least amount of chnage to existing apps. I understand why you want to call this TCP and use TCP's protocol number, but that comes with this cost. > I don't think it makes sense to make the > default behavior "care" because then you have to go out of your way to > not care, which by definition people don't do. Especially since it > requires thinking about how to set a socket option that will be unknown > on some systems for portable applications. Yes - that's exactly the cost of playing with TCP. > However, we can deduce that applications care if they bind to a > specific address, or look up the address tied to the remote end of an > incoming session. If neither happens subflows can continue without trouble. Not sure this is sufficient. You can bind to a set of addresses (or ANY), and still care that the IP address doesn't change (e.g., in-band info can be IP-address specific, such as access control, etc.). ... > Another class of applications is those that care about the addresses, > but are not bothered by change. For instance, I may log that I'm talking > to 192.0.2.1 but then when that address goes down and communication > continues using 10.0.0.1, I simply log the address addition/change and > all is well. This presumes that you know the purpose of a log. If the log is just informational, the above may be true. But if the log is used to verify access, or to coordinate future responses, just knowing it's logged to a file isn't sufficient. > So I think what we need: > > - mechanism to indicate that a session is bound to an address I think you need the negative of this, i.e., to find out whether a session is NOT bound to an address, that can respond, YES, NO, or DON'T KNOW (which should behave like YES). > - mechanism to indicate that an address has been removed > - mechanism to indicate "no address agility" (default = agility) As above, default = no agility. > - mechanism to indicate "no MPTCP" (default = MPTCP) Under what conditions would you want to set "no MPTCP"? If you think it will ever change TCP semantics, then the default needs to be "no MPTCP". If not, then why do you ever need this option? > Note that "no address agility" and "MPTCP" means that you can have > additional subflows using additional addresses, but only as long as the > primary addresses have reachability. I think this is similar to MIPv6, > where you need to return to the HoA at certain intervals. > > I don't think it's appropriate to explicitly track interface status > in TCP. If the packets get there you're up, if they don't you time > out eventually and then presumably you're down. See RFC1122 Sec 3.3.4.3, which explicitly ties the transport selection of a source address to an address selected based on the state of the interface. I.e., your assertion changes an existing standard. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksmeC0ACgkQE5f5cImnZrvmEACg7IxWzPLnWygF5rjh+2VfdMuV sTsAoKpJpA9rlMZUUwE/R5IHEf+nPw2t =8L7B -----END PGP SIGNATURE----- From julienl@qualcomm.com Mon Dec 14 09:40:36 2009 Return-Path: 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 ; 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 ; 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 ; 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 |To:=20Iljitsch=20van=20Beijnum=20 |CC:=20Joe=20Touch=20,=0D=0A=20=20=20=20 =20=20=20=20"multipathtcp@ietf.org=20List"=0D=0A=09|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|References:=20=0D=0A=20<3c3e3fca091109 0542h54e45784qbdbf1f338a4c3e90@mail.gmail.com>=0D=0A=20=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=0D=0A=20=0D=0A=20<4B0C607A.6060503@i si.edu>=0D=0A=20=0D=0A=20<4B0C6590.9010000 @isi.edu>=0D=0A=20=0D=0A=20<4B0C6C13.20601 03@isi.edu>=0D=0A=20=0D=0A=20<4B0C6FBE.400 03@isi.edu>=0D=0A=20=0D=0A=20=0D=0A=20=0D=0A=20<4B0D52D5.90 90403@isi.edu>=20<58B2A4B2-F!=0D=0A=20276-4E96-87FB-F8273 FD78ED0@muada.com>=0D=0A=20=0D=0A=20|In-Reply-To: =20 |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 ; 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" To: Iljitsch van Beijnum Date: Mon, 14 Dec 2009 09:40:20 -0800 Thread-Topic: [multipathtcp] Multipath deployment and fate sharing Thread-Index: Acp83lz6KAimpEwoQ1yKHGvZ8s8TNgABQgfg Message-ID: References: <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> <4B0C607A.6060503@isi.edu> <4B0C6590.9010000@isi.edu> <4B0C6C13.2060103@isi.edu> <4B0C6FBE.40003@isi.edu> <4B0D52D5.9090403@isi.edu> <58B2A4B2-F! 276-4E96-87FB-F8273FD78ED0@muada.com> In-Reply-To: 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" , Joe Touch 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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. >=20 > 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.=20 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 ad= dress semantic is broken end-to-end. For purely local matters, fate-sharing can be used to maintain some applica= tions' expectations regarding the relationship between local addresses and = the transport connections that are bound on them. --julien From touch@ISI.EDU Mon Dec 14 09:40:37 2009 Return-Path: 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 EE6A43A68F4 for ; Mon, 14 Dec 2009 09:40:37 -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=[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 FvEEfy8QEEzk for ; Mon, 14 Dec 2009 09:40:37 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 288C73A6A1B for ; Mon, 14 Dec 2009 09:40:37 -0800 (PST) Received: from [75.212.111.146] (146.sub-75-212-111.myvzw.com [75.212.111.146]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nBEHd5VP008669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Dec 2009 09:39:08 -0800 (PST) Message-ID: <4B267839.1000108@isi.edu> Date: Mon, 14 Dec 2009 09:39:05 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> <4B0C607A.6060503@isi.edu> <4B0C6590.9010000@isi.edu> <4B0C6C13.2060103@isi.edu> <4B0C6FBE.40003@isi.edu> <4B0D52D5.9090403@isi.edu> <58B2A4B2-F! 276-4E96-87FB-F8273FD78ED0@muada.com> In-Reply-To: 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 17:40:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Iljitsch van Beijnum wrote: ... > So this leaves the situation where we know an address is no longer > valid and the application(s) are interested in the addresses. Eventually > we need to move to a situation where applications need to register their > wishes in this regard and allow MPTCP by default if they don't, because > the opposite situation isn't workable. Pushing MPTCP on by default in the absence of knowing it won't change TCP semantics is unworkable too. There are two options: 1- use TCP as the basis of this new thing 2- use a new protocol number (1) lets you traverse NATs and be backward compatible with legacy apps, but *ONLY* if you don't change the semantics. It isn't reasonable to pick an alternative that could break existing apps, but to push forward because it furthers the agenda of this WG. > However, it could be reasonable > to have an interim period during which the default is to make MPTCP > sessions bound to addresses that are no longer valid go down if the > applications have expressed interest in those addresses I disagree, as per above. You're playing with TCP by your choice. It's your responsibility to "first do no harm", which means to leave things in legacy mode (captain goes down with the ship) until you know better. If this is that useful, apps. will override that mode explicitly. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksmeDkACgkQE5f5cImnZrvwEgCffV3CMdyit+VtxW1JTQPXAG9i K38AoP4S/u2UWZmMULS0E5pgtZazKob1 =2lEd -----END PGP SIGNATURE----- From touch@ISI.EDU Mon Dec 14 09:47:15 2009 Return-Path: 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 AAC2028C11C for ; Mon, 14 Dec 2009 09:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 i6u7vEsTnQQh for ; Mon, 14 Dec 2009 09:47:15 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 01FA928C108 for ; Mon, 14 Dec 2009 09:47:14 -0800 (PST) Received: from [75.212.111.146] (146.sub-75-212-111.myvzw.com [75.212.111.146]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nBEHjqdV010595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Dec 2009 09:45:55 -0800 (PST) Message-ID: <4B2679D0.8040207@isi.edu> Date: Mon, 14 Dec 2009 09:45:52 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Laganier, Julien" References: <4B0C607A.6060503@isi.edu> <4B0C6590.9010000@isi.edu> <4B0C6C13.2060103@isi.edu> <4B0C6FBE.40003@isi.edu> <4B0D52D5.9090403@isi.edu> <58B2A4B2-F! 276-4E96-87FB-F8273FD78ED0@muada.com> In-Reply-To: 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 17:47:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Laganier, Julien wrote: > 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. Apps have those expectations - local or remote. That's why some apps break when they go through NATs. Let's not compound that situation with by assuming fate sharing can be ignored. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksmec8ACgkQE5f5cImnZrudZACgun8pMImwMSJ7TlmRrQBSnWP7 AuAAoJctRza7cW2sriaHz/jrRWix8erc =gZUU -----END PGP SIGNATURE----- From julienl@qualcomm.com Mon Dec 14 09:57:00 2009 Return-Path: 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 7930028C103 for ; Mon, 14 Dec 2009 09:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.606 X-Spam-Level: X-Spam-Status: No, score=-104.606 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, J_CHICKENPOX_48=0.6, 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 pYa8JavAXc5Q for ; Mon, 14 Dec 2009 09:56:59 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 470003A6918 for ; Mon, 14 Dec 2009 09:56:59 -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=1260813406; x=1292349406; 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 |To:=20Joe=20Touch=20|CC:=20Iljitsch=20van =20Beijnum=20,=0D=0A=20=20=20=20=20 =20=20=20"multipathtcp@ietf.org=20List"=0D=0A=09|Date:=20Mon,=2014=20Dec=202009=2009:56:37 =20-0800|Subject:=20RE:=20[multipathtcp]=20Multipath=20de ployment=20and=20fate=20sharing|Thread-Topic:=20[multipat htcp]=20Multipath=20deployment=20and=20fate=20sharing |Thread-Index:=20Acp85XXiYTTTljvpS4WPDH9PkJYztgAABkqg |Message-ID:=20|References:=20=0D=0A=20=0D=0A=20=0D=0A=20<4B0C607A.6060503@isi.edu>=0D=0A=20=0D=0A=20<4B0C6590.9010000@isi.edu>=0D=0A=20=0D=0A=20<4B0C6C13.2060103@isi.edu>=0D=0A=20< BF345F63074F8040B58C00A186FCA57F1C65FB29CB@NALASEXMB04.na .qualcomm.com>=0D=0A=20<4B0C6FBE.40003@isi.edu>=0D=0A=20< alpine.DEB.2.00.0911250211520.23603@ayourtch-lnx.stdio.be >=0D=0A=20=0D=0A=20=0D=0A=20<4B0D52D5.9090403@isi.edu>=20<58B 2A4B2-F!=0D=0A=20276-4E96-87FB-F8273FD78ED0@muada.com>=0D =0A=20=0D=0A=20=0D=0A=20=0D=0A=20<4B 2679D0.8040207@isi.edu>|In-Reply-To:=20<4B2679D0.8040207@ isi.edu>|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=Uom5+n34aR5dMDcb0GMMEyXiBFBfqhyzvouK2fF6I9g=; b=TZWlvs5ffS7VZB+ypQA2fmBGUGZbf3ZfHrT3V9V3bQR0FKLso5f1Q/IM fNSWprvBO5SffWH9TZ54K9fsWgbpkuIHn+z2wOecL9nJztC/+k5R9jUIZ WWg963qCA/IIsoexqlQnOetARkli6XkqZxfoUS5/jIjZ1KveVHzzxPmeY k=; X-IronPort-AV: E=McAfee;i="5400,1158,5832"; a="29879248" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 14 Dec 2009 09:56:46 -0800 Received: from ironstorm.qualcomm.com (ironstorm.qualcomm.com [172.30.39.153]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nBEHuk2g008537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 14 Dec 2009 09:56:46 -0800 X-IronPort-AV: E=Sophos;i="4.47,396,1257148800"; d="scan'208";a="23163465" Received: from nasanexhub06.na.qualcomm.com ([129.46.134.254]) by ironstorm.qualcomm.com with ESMTP/TLS/RC4-MD5; 14 Dec 2009 09:56:39 -0800 Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 14 Dec 2009 09:56:39 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Mon, 14 Dec 2009 09:56:39 -0800 From: "Laganier, Julien" To: Joe Touch Date: Mon, 14 Dec 2009 09:56:37 -0800 Thread-Topic: [multipathtcp] Multipath deployment and fate sharing Thread-Index: Acp85XXiYTTTljvpS4WPDH9PkJYztgAABkqg Message-ID: References: <4B0C607A.6060503@isi.edu> <4B0C6590.9010000@isi.edu> <4B0C6C13.2060103@isi.edu> <4B0C6FBE.40003@isi.edu> <4B0D52D5.9090403@isi.edu> <58B2A4B2-F! 276-4E96-87FB-F8273FD78ED0@muada.com> <4B2679D0.8040207@isi.edu> In-Reply-To: <4B2679D0.8040207@isi.edu> 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 17:57:00 -0000 Joe Touch wrote: >=20 > Laganier, Julien wrote: > > 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=20 > >>> allocation with[Laganier, Julien] short term leases. So in IPv4 > >>> we can't rule out situation #2, and thus we want to make fate=20 > >>> 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,=20 > > 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. >=20 > Apps have those expectations - local or remote. That's why some apps > break when they go through NATs. Let's not compound that situation with > by assuming fate sharing can be ignored. Not what I intended to say, should have been more precise. Fate sharing does not solve (neither its absence make worse) the issue of a= remote address X not being uniquely associated with a peer. For example, w= ith fate sharing and normal TCP there's the issue of an application connect= ed to a peer application on remote address X not being able to connect to t= he same peer when issuing another connect().=20 This is different from the issue of an application expecting a connection t= o be up if and only if the remote address X is still in use by its peer. Th= at one is influenced by our decision regarding fate-sharing. --julien From touch@ISI.EDU Mon Dec 14 10:38:19 2009 Return-Path: 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 4E8463A6909 for ; Mon, 14 Dec 2009 10:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[AWL=-0.920, BAYES_00=-2.599, J_CHICKENPOX_48=0.6, SARE_LWSHORTT=1.24] 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 quf8r4JIwXzA for ; Mon, 14 Dec 2009 10:38:18 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 740D03A6905 for ; Mon, 14 Dec 2009 10:38:18 -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 nBEIaRqk024000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Dec 2009 10:36:30 -0800 (PST) Message-ID: <4B2685A8.5070201@isi.edu> Date: Mon, 14 Dec 2009 10:36:24 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Laganier, Julien" References: <4B0C607A.6060503@isi.edu> <4B0C6590.9010000@isi.edu> <4B0C6C13.2060103@isi.edu> <4B0C6FBE.40003@isi.edu> <4B0D52D5.9090403@isi.edu> <58B2A4B2-F! 276-4E96-87FB-F8273FD78ED0@muada.com> <4B2679D0.8040207@isi.edu> In-Reply-To: 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 18:38:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Laganier, Julien wrote: > Joe Touch wrote: >> Laganier, Julien wrote: >>> 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[Laganier, Julien] 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. >> >> Apps have those expectations - local or remote. That's why some apps >> break when they go through NATs. Let's not compound that situation with >> by assuming fate sharing can be ignored. > > Not what I intended to say, should have been more precise. > > Fate sharing does not solve (neither its absence make worse) the > issue of a remote address X not being uniquely associated with a > peer. For example, with fate sharing and normal TCP there's the issue > of an application connected to a peer application on remote address X > not being able to connect to the same peer when issuing another > connect(). > > This is different from the issue of an application expecting a > connection to be up if and only if the remote address X is still in use > by its peer. That one is influenced by our decision regarding fate-sharing. 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". 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. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksmhagACgkQE5f5cImnZrsV2gCfXtlziKZ6kYgGjjXxJTOgfSTs BpsAn3jwTXcQ0g5qY+KTQASds2IebpFL =484d -----END PGP SIGNATURE----- From julienl@qualcomm.com Mon Dec 14 10:46:19 2009 Return-Path: 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 ED3593A6911 for ; Mon, 14 Dec 2009 10:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.609 X-Spam-Level: X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-1.850, BAYES_00=-2.599, J_CHICKENPOX_48=0.6, 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 b4mTuGctcvU1 for ; Mon, 14 Dec 2009 10:46:18 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 5E3523A6857 for ; Mon, 14 Dec 2009 10:46:06 -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=1260816353; x=1292352353; 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 |To:=20Joe=20Touch=20|CC:=20Iljitsch=20van =20Beijnum=20,=0D=0A=20=20=20=20=20 =20=20=20"multipathtcp@ietf.org=20List"=0D=0A=09|Date:=20Mon,=2014=20Dec=202009=2010:45:50 =20-0800|Subject:=20RE:=20[multipathtcp]=20Multipath=20de ployment=20and=20fate=20sharing|Thread-Topic:=20[multipat htcp]=20Multipath=20deployment=20and=20fate=20sharing |Thread-Index:=20Acp87Jel2Uf7CGZdTJqFsbrdttgsNAAAB14A |Message-ID:=20|References:=20=0D=0A=20<4B0C607A.60605 03@isi.edu>=0D=0A=20=0D=0A=20<4B0C6590.901 0000@isi.edu>=0D=0A=20=0D=0A=20<4B0C6C13.2 060103@isi.edu>=0D=0A=20=0D=0A=20<4B0C6FBE .40003@isi.edu>=0D=0A=20=0D=0A=20=0D=0A=20=0D=0A=20<4B0D52D 5.9090403@isi.edu>=20<58B2A4B2-F!=0D=0A=20276-4E96-87FB-F 8273FD78ED0@muada.com>=0D=0A=20=0D=0A=20=0D=0A=20=0D=0A=20<4B2679D0.8040207@isi.edu>=0D=0A=20 =0D=0A=20<4B2685A8.5070201@isi.edu> |In-Reply-To:=20<4B2685A8.5070201@isi.edu> |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=krUEqjnq9LK/BqPY9DrmVnxnnsNFJfjvxsMhYvP0JxI=; b=BTPYShuF4Ui7ANEjkJUoNJHuIBvIItM3OcQt9W0YUCF6M+lqfOAONZba M1kuiGP0LYNCNEdrqvPN5hPyHFJ2grSihUxBT/OmXpDXEZtoGi1S/7j4i N6vboMVH+fmDnpQspzJqQVgZ7O6Af7YQrTlIkRX1HmT3sifw4ZciMr+LO w=; X-IronPort-AV: E=McAfee;i="5400,1158,5832"; a="29884737" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP; 14 Dec 2009 10:45:52 -0800 Received: from ironrogue.qualcomm.com (ironrogue.qualcomm.com [129.46.61.164]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nBEIjq8a023839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 14 Dec 2009 10:45:52 -0800 X-IronPort-AV: E=Sophos;i="4.47,396,1257148800"; d="scan'208";a="22997294" Received: from nasanexhub02.na.qualcomm.com ([10.46.143.120]) by ironrogue.qualcomm.com with ESMTP/TLS/RC4-MD5; 14 Dec 2009 10:45:52 -0800 Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 14 Dec 2009 10:45:52 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Mon, 14 Dec 2009 10:45:52 -0800 From: "Laganier, Julien" To: Joe Touch Date: Mon, 14 Dec 2009 10:45:50 -0800 Thread-Topic: [multipathtcp] Multipath deployment and fate sharing Thread-Index: Acp87Jel2Uf7CGZdTJqFsbrdttgsNAAAB14A Message-ID: References: <4B0C607A.6060503@isi.edu> <4B0C6590.9010000@isi.edu> <4B0C6C13.2060103@isi.edu> <4B0C6FBE.40003@isi.edu> <4B0D52D5.9090403@isi.edu> <58B2A4B2-F! 276-4E96-87FB-F8273FD78ED0@muada.com> <4B2679D0.8040207@isi.edu> <4B2685A8.5070201@isi.edu> In-Reply-To: <4B2685A8.5070201@isi.edu> 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 18:46:20 -0000 Joe Touch wrote:=20 > Laganier, Julien wrote: > > Joe Touch wrote: > >> Laganier, Julien wrote: > >>> 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[Laganier, Julien] 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. > >> > >> Apps have those expectations - local or remote. That's why some apps > >> break when they go through NATs. Let's not compound that situation > >> with by assuming fate sharing can be ignored. > > > > Not what I intended to say, should have been more precise. > > > > Fate sharing does not solve (neither its absence make worse) the > > issue of a remote address X not being uniquely associated with a > > peer. For example, with fate sharing and normal TCP there's the issue > > of an application connected to a peer application on remote address X > > not being able to connect to the same peer when issuing another > > connect(). > > > > This is different from the issue of an application expecting a > > connection to be up if and only if the remote address X is still in > > use by its peer. That one is influenced by our decision regarding > > fate-sharing. >=20 > I agree fate sharing doesn't solve the issue, but its absence > definitely does make it "worse", where "worse" is considered=20 > (by me) to be "not what existing TCP does". So the situation is already "worse" without MPTCP to the extent that "exist= ing TCP" on SHIM6 already modifies the range of event that are visible to a= pplications compared to the "existing TCP" on "existing IPv6". =20 > 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,=20 > 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. --julien From touch@ISI.EDU Mon Dec 14 10:54:07 2009 Return-Path: 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 ; 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 ; 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 ; 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 User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Laganier, Julien" References: <4B0C6590.9010000@isi.edu> <4B0C6C13.2060103@isi.edu> <4B0C6FBE.40003@isi.edu> <4B0D52D5.9090403@isi.edu> <58B2A4B2-F! 276-4E96-87FB-F8273FD78ED0@muada.com> <4B2679D0.8040207@isi.edu> <4B2685A8.5070201@isi.edu> In-Reply-To: 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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----- From iljitsch@muada.com Mon Dec 14 12:11:05 2009 Return-Path: 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 54E473A6919 for ; Mon, 14 Dec 2009 12:11:05 -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=[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 qk2nV1+dmyqc for ; Mon, 14 Dec 2009 12:11:02 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 3A6A43A68C4 for ; Mon, 14 Dec 2009 12:11:02 -0800 (PST) Received: from [192.168.2.11] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBEKAC6B041340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Dec 2009 21:10:13 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <4B26782D.9080907@isi.edu> Date: Mon, 14 Dec 2009 21:10:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <24F138C7-6176-479F-957A-D0CF13FAC15D@muada.com> References: <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> <4B0C607A.6060503@isi.edu> <4B0C6590.9010000@isi.edu> <4B0C6C13.2060103@isi.edu> <4B0C6FBE.40003@isi.edu> <4B0D52D5.9090403@isi.edu> <58B2A4B2-F276-4E96-87FB-F8273FD78ED0@muada.com> <4B26782D.9080907@isi.ed! u> To: Joe Touch X-Mailer: Apple Mail (2.1077) Cc: "multipathtcp@ietf.org List" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 20:11:05 -0000 On 14 dec 2009, at 18:38, Joe Touch wrote: > DHCP assignments shouldn't override explicit interface actions. If you (as a TCP session) want to go down when the interface the address = that you're bound to belongs to goes down, that is your choice. However, = that is not current reality. First of all, there is no unambiguous = up/down dichotomy for interfaces, and second, on many systems (FreeBSD, = MacOS) TCP sessions will happily stick around when an interface is = really, truly down, even to the degree that the address has been = removed. (This is really nice because then the session is still there = when the interface comes back up again.) The point is the authority to use an address. If a DHCP server gives me = a valid lifetime of 7200 seconds I get to use the address for two hours. = Interface state has nothing to do with that. (How would the DHCP server = know my interface is down? Or how would a router know the interface I = configured from its RA is down?) > IMO, you need to make the assumption that causes the least amount of > chnage to existing apps. I understand why you want to call this TCP = and > use TCP's protocol number, but that comes with this cost. I don't accept that requirement. In the IETF, we get to change things. Even to the degree that the new = instance does things that diverge significantly from the old instance. = We do need to be prudent and cause the least possible amount of harm, = but there is no requirement to stick to arbitrary old ways of doing = things just because. >> However, we can deduce that applications care if they bind to a >> specific address, or look up the address tied to the remote end of an >> incoming session. If neither happens subflows can continue without = trouble. > Not sure this is sufficient. You can bind to a set of addresses (or > ANY), and still care that the IP address doesn't change (e.g., in-band > info can be IP-address specific, such as access control, etc.). Yes, when you bind to an address you care. If you don't bind to an = address (but ANY instead) apparently you don't care. >> Another class of applications is those that care about the addresses, >> but are not bothered by change. For instance, I may log that I'm = talking >> to 192.0.2.1 but then when that address goes down and communication >> continues using 10.0.0.1, I simply log the address addition/change = and >> all is well. > This presumes that you know the purpose of a log. If the log is just > informational, the above may be true. But if the log is used to verify > access, or to coordinate future responses, just knowing it's logged to = a > file isn't sufficient. Well, these are applications that need to know about = multiaddressing/multipath anyway, so presumably these apps know whether = they just need logging or they need more. >> - mechanism to indicate that a session is bound to an address > I think you need the negative of this, i.e., to find out whether a > session is NOT bound to an address, that can respond, YES, NO, or = DON'T > KNOW (which should behave like YES). Ok, I can go along with that at this point. >> - mechanism to indicate that an address has been removed >> - mechanism to indicate "no address agility" (default =3D agility) > As above, default =3D no agility. Can we narrow down our differences to just this one? >> - mechanism to indicate "no MPTCP" (default =3D MPTCP) > Under what conditions would you want to set "no MPTCP"? Not sure if there is a large class of conditions that is incompatible = with MPTCP, the only thing I can think of is speed tests. But as long as = we're adding API calls we may as well err on the side of adding more = than on the side of adding fewer, as the marginal cost of the extra ones = is near-zero and the cost of producing and implementing an update are = huge. > See RFC1122 Sec 3.3.4.3, which explicitly ties the transport selection > of a source address to an address selected based on the state of the > interface. I.e., your assertion changes an existing standard. I can live with that. By the way, about the protocol number: is that relevant? If two ends, = including the applications on both sides, agree on different semantics, = why would it be necessary to use a different protocol number?= From touch@ISI.EDU Mon Dec 14 12:28:11 2009 Return-Path: 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 44C4228C157 for ; Mon, 14 Dec 2009 12:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=0.307, 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 WxOJASWThF4y for ; Mon, 14 Dec 2009 12:28:10 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 65E193A67D3 for ; Mon, 14 Dec 2009 12:28:10 -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 nBEKRWfa023695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Dec 2009 12:27:39 -0800 (PST) Message-ID: <4B269FB2.1000008@isi.edu> Date: Mon, 14 Dec 2009 12:27:30 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> <4B0C607A.6060503@isi.edu> <4B0C6590.9010000@isi.edu> <4B0C6C13.2060103@isi.edu> <4B0C6FBE.40003@isi.edu> <4B0D52D5.9090403@isi.edu> <58B2A4B2-F276-4E96-87FB-F8273FD78ED0@muada.com> <4B26782D.9080907@isi.ed! u> <24F138C7-6176-479F-957A-D0CF13FAC15D@mua! da.com> In-Reply-To: <24F138C7-6176-479F-957A-D0CF13FAC15D@muada.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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 20:28:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Iljitsch van Beijnum wrote: ... >>> However, we can deduce that applications care if they bind to a >>> specific address, or look up the address tied to the remote end of an >>> incoming session. If neither happens subflows can continue without trouble. > >> Not sure this is sufficient. You can bind to a set of addresses (or >> ANY), and still care that the IP address doesn't change (e.g., in-band >> info can be IP-address specific, such as access control, etc.). > > Yes, when you bind to an address you care. If you don't bind to an address (but ANY instead) apparently you don't care. You didn't care what it was when you started, but you may care during a connection (if you read it out). >>> Another class of applications is those that care about the addresses, >>> but are not bothered by change. For instance, I may log that I'm talking >>> to 192.0.2.1 but then when that address goes down and communication >>> continues using 10.0.0.1, I simply log the address addition/change and >>> all is well. > >> This presumes that you know the purpose of a log. If the log is just >> informational, the above may be true. But if the log is used to verify >> access, or to coordinate future responses, just knowing it's logged to a >> file isn't sufficient. > > Well, these are applications that need to know about > multiaddressing/multipath anyway, so presumably these apps know whether > they just need logging or they need more. They might know, but you might not. I.e., how do you know without looking at the source code? >>> - mechanism to indicate that a session is bound to an address > >> I think you need the negative of this, i.e., to find out whether a >> session is NOT bound to an address, that can respond, YES, NO, or DON'T >> KNOW (which should behave like YES). > > Ok, I can go along with that at this point. > >>> - mechanism to indicate that an address has been removed >>> - mechanism to indicate "no address agility" (default = agility) > >> As above, default = no agility. > > Can we narrow down our differences to just this one? I'm not sure - is that the only place we differ? >>> - mechanism to indicate "no MPTCP" (default = MPTCP) > >> Under what conditions would you want to set "no MPTCP"? > > Not sure if there is a large class of conditions that is incompatible > with MPTCP, the only thing I can think of is speed tests. But as long as > we're adding API calls we may as well err on the side of adding more > than on the side of adding fewer, as the marginal cost of the extra ones > is near-zero and the cost of producing and implementing an update are huge. > >> See RFC1122 Sec 3.3.4.3, which explicitly ties the transport selection >> of a source address to an address selected based on the state of the >> interface. I.e., your assertion changes an existing standard. > > I can live with that. > > By the way, about the protocol number: is that relevant? If two ends, > including the applications on both sides, agree on different > semantics, why would it be necessary to use a different protocol > number? Why is it necessary to use an old one? If you want an old one, why not use UDP? For any reason you want to stay with TCP, that's a reason to stick with TCP semantics or realize you're redefining semantics TCP for everyone. Given it's place as a core protocol, I don't think redefining semantics ought to be on the table. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksmn7IACgkQE5f5cImnZrvhhACg5VhFyAGu38trilbhYGjqbyAM hS8AoN6m/51zWqYjucNlr3qSA8+bPwia =DQNL -----END PGP SIGNATURE----- From iljitsch@muada.com Mon Dec 14 13:01:01 2009 Return-Path: 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 B3AEA3A6875 for ; Mon, 14 Dec 2009 13:01:01 -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=[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 EVFzNvMgUvF0 for ; Mon, 14 Dec 2009 13:01:00 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 8A4103A68C7 for ; Mon, 14 Dec 2009 13:01:00 -0800 (PST) Received: from [192.168.2.11] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBEL0AUj041677 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Dec 2009 22:00:11 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <4B269FB2.1000008@isi.edu> Date: Mon, 14 Dec 2009 22:00:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> <4B0C607A.6060503@isi.edu> <4B0C6590.9010000@isi.edu> <4B0C6C13.2060103@isi.edu> <4B0C6FBE.40003@isi.edu> <4B0D52D5.9090403@isi.edu> <58B2A4B2-F276-4E96-87FB-F8273FD78ED0@muada.com> <4B26782D.9080907@isi.ed! u> <24F138C7-6176-479F-957A-D0CF13FAC15D@mua! ! da.com> <4B269FB2.1000008@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1077) Cc: "multipathtcp@ietf.org List" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 21:01:01 -0000 On 14 dec 2009, at 21:27, Joe Touch wrote: >> Yes, when you bind to an address you care. If you don't bind to an = address (but ANY instead) apparently you don't care. > You didn't care what it was when you started, but you may care during = a > connection (if you read it out). Absolutely. That's why either the ends must communicate to the other = side the fact that they lost an address so the other side can take = action if it cares, or they must indicate that they care at any time = that they start caring about the specific addresses used for the = session. >> Well, these are applications that need to know about >> multiaddressing/multipath anyway, so presumably these apps know = whether >> they just need logging or they need more. > They might know, but you might not. I.e., how do you know without > looking at the source code? Is there any reason for the user to know? If the application uses a = socket option to tell the system, the right thing will happen without = user intervention. >>> As above, default =3D no agility. >> Can we narrow down our differences to just this one? > I'm not sure - is that the only place we differ? The wg needs to come to rough consensus, if we can have that on = everything but this point that provides a way forward. >> By the way, about the protocol number: is that relevant? If two ends, >> including the applications on both sides, agree on different >> semantics, why would it be necessary to use a different protocol >> number? > Why is it necessary to use an old one? If you want an old one, why not > use UDP? Because of backward compatibility. If we start with TCP and only go to = the new semantics when both ends agree this is readily deployable, but = using a new protocol number or implementing TCPng on top of UDP means we = need something to discover whether the other side supports the new = protocol or not and of course middlebox issues. > For any reason you want to stay with TCP, that's a reason to stick = with > TCP semantics or realize you're redefining semantics TCP for everyone. How am I redefining it for everyone? I only execute the new semantics = when both ends support them. (Remember that for the purposes of this = sub-discussion I'm assuming that the applications at both ends have = opted in to address agility etc.) This is no different from the TCP = window scale option, in my opinion. > Given it's place as a core protocol, I don't think redefining = semantics > ought to be on the table. If we can redifine bits in the IP header with not even an opt in from = the original sender of the packet (diffserv) why not TCP semantics...= From touch@ISI.EDU Mon Dec 14 16:52:14 2009 Return-Path: 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 576DE3A6897 for ; Mon, 14 Dec 2009 16:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, SARE_RMML_Stock10=0.13] 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 TfbY7HPVAbAa for ; Mon, 14 Dec 2009 16:52:13 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 72DE53A685B for ; Mon, 14 Dec 2009 16:52:13 -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 nBF0pI16026041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Dec 2009 16:51:21 -0800 (PST) Message-ID: <4B26DD86.9060605@isi.edu> Date: Mon, 14 Dec 2009 16:51:18 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> <4B0C607A.6060503@isi.edu> <4B0C6590.9010000@isi.edu> <4B0C6C13.2060103@isi.edu> <4B0C6FBE.40003@isi.edu> <4B0D52D5.9090403@isi.edu> <58B2A4B2-F276-4E96-87FB-F8273FD78ED0@muada.com> <4B26782D.9080907@isi.ed! u> <24F138C7-6176-479F-957A-D0CF13FAC15D@mua! ! da.com> <4B269FB2.1000008@isi.edu> In-Reply-To: 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 00:52:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Iljitsch van Beijnum wrote: > On 14 dec 2009, at 21:27, Joe Touch wrote: > >>> Yes, when you bind to an address you care. If you don't bind to an address (but ANY instead) apparently you don't care. > >> You didn't care what it was when you started, but you may care during a >> connection (if you read it out). > > Absolutely. That's why either the ends must communicate to the other side the fact that they lost an address so the other side can take action if it cares, or they must indicate that they care at any time that they start caring about the specific addresses used for the session. > >>> Well, these are applications that need to know about >>> multiaddressing/multipath anyway, so presumably these apps know whether >>> they just need logging or they need more. > >> They might know, but you might not. I.e., how do you know without >> looking at the source code? > > Is there any reason for the user to know? If the application uses a > socket option to tell the system, the right thing will happen without > user intervention. The user can use the socket option to get information, and then use it to log or use it to open a new connection. You can't know the difference just from the first option access. >>>> As above, default = no agility. > >>> Can we narrow down our differences to just this one? > >> I'm not sure - is that the only place we differ? > > The wg needs to come to rough consensus, if we can have that on everything but this point that provides a way forward. I agree; I just was checking. >>> By the way, about the protocol number: is that relevant? If two ends, >>> including the applications on both sides, agree on different >>> semantics, why would it be necessary to use a different protocol >>> number? > >> Why is it necessary to use an old one? If you want an old one, why not >> use UDP? > > Because of backward compatibility. If we start with TCP and only go > to the new semantics when both ends agree this is readily deployable, > but using a new protocol number or implementing TCPng on top of UDP > means we need something to discover whether the other side supports > the new protocol or not and of course middlebox issues. You need to know whether the other side supports the new protocol either way. You save only the extra legacy TCP exchange for legacy backup. As to middleboxes, good luck - I can't see any option-based system that a middlebox won't mess up. >> For any reason you want to stay with TCP, that's a reason to stick with >> TCP semantics or realize you're redefining semantics TCP for everyone. > > How am I redefining it for everyone? I only execute the new semantics > when both ends support them. (Remember that for the purposes of this > sub-discussion I'm assuming that the applications at both ends have > opted in to address agility etc.) This is no different from the TCP > window scale option, in my opinion. I think you're assuming that if the transport protocols agree, the applications are OK with using the new semantics. I'm not. You'd get application buy-in by making this default-off, with an option to turn it on. I suspect many on this list won't accept that solution, because: a) it means no benefit for legacy apps that aren't revised to support the new protocol b) if you have to revise the app, you might as well have it use a new protocol altogether. >> Given it's place as a core protocol, I don't think redefining semantics >> ought to be on the table. > > If we can redifine bits in the IP header with not even an opt in from > the original sender of the packet (diffserv) why not TCP semantics... Because IP is best effort, and diffserv doesn't break "best effort" semantics. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksm3YYACgkQE5f5cImnZrspNQCfVP8pb19pa1GjsoFVJ+g23YaU UzkAmgLkUSMFdUdLbOpvL6RdPCbO4Txr =oyKw -----END PGP SIGNATURE----- From iljitsch@muada.com Tue Dec 15 03:46:49 2009 Return-Path: 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 685E03A69EA for ; Tue, 15 Dec 2009 03:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6] 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 B3TXtrplmVmq for ; Tue, 15 Dec 2009 03:46:48 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 634B03A69F1 for ; Tue, 15 Dec 2009 03:46:48 -0800 (PST) Received: from [172.16.0.236] ([193.145.14.94]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id nBFBjtFP048117 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 Dec 2009 12:45:55 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <4B26DD86.9060605@isi.edu> Date: Tue, 15 Dec 2009 12:46:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <985FD30E-3103-46F9-8B65-2E88868FB9B2@muada.com> References: <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com> <4B0C607A.6060503@isi.edu> <4B0C6590.9010000@isi.edu> <4B0C6C13.2060103@isi.edu> <4B0C6FBE.40003@isi.edu> <4B0D52D5.9090403@isi.edu> <58B2A4B2-F276-4E96-87FB-F8273FD78ED0@muada.com> <4B26782D.9080907@isi.ed! u> <24F138C7-6176-479F-957A-D0CF13FAC15D@mua! ! da.com> <4B269FB2.1000008@isi.edu> <4B26DD86! .9060605@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1077) Cc: "multipathtcp@ietf.org List" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 11:46:49 -0000 On 15 dec 2009, at 1:51, Joe Touch wrote: >> Is there any reason for the user to know? If the application uses a >> socket option to tell the system, the right thing will happen without >> user intervention. > The user can use the socket option to get information, and then use it > to log or use it to open a new connection. You can't know the = difference > just from the first option access. Not sure what the issue is... Obviously we don't want the user to = micro-manage. The way I see it, all of this is pretty similar to the = V6ONLY socket option which obviated the need to manually mess with the = availability of IPv4-mapped addresses with the IPv6 socket API. > You need to know whether the other side supports the new protocol = either > way. You save only the extra legacy TCP exchange for legacy backup. This is easier to do with TCP options than with knocking at a door that = may or may not be there, in that case you need a timeout, adding delay, = or try to set up an old style and a new style session at the same time, = adding overhead. > As to middleboxes, good luck - I can't see any option-based system = that > a middlebox won't mess up. Actually middleboxes don't seem to be too hard on TCP options. > I think you're assuming that if the transport protocols agree, the > applications are OK with using the new semantics. I'm not. I was specifically addressing the situation where the applications are = ok with the new semantics. If you feel that even under those = circumstances changes to TCP semantics can't be made, my conclusion = would have to be that you won't be able to support ANY type of multipath = TCP.= From nishida@sfc.wide.ad.jp Fri Dec 18 12:03:47 2009 Return-Path: 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 159183A6833 for ; Fri, 18 Dec 2009 12:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.389 X-Spam-Level: * X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] 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 bv-1602bOhQd for ; Fri, 18 Dec 2009 12:03:46 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 4F0943A69A1 for ; Fri, 18 Dec 2009 12:03:46 -0800 (PST) Received: from localhost (cpu.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 6AE464D857; Sat, 19 Dec 2009 05:03:26 +0900 (JST) Date: Sat, 19 Dec 2009 05:03:26 +0900 (JST) Message-Id: <20091219.050326.189669865.nishida@sfc.wide.ad.jp> To: touch@ISI.EDU From: Yoshifumi Nishida In-Reply-To: <4B2685A8.5070201@isi.edu> References: <4B2679D0.8040207@isi.edu> <4B2685A8.5070201@isi.edu> X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 20:03:47 -0000 Hello, From: Joe Touch Subject: Re: [multipathtcp] Multipath deployment and fate sharing Date: Mon, 14 Dec 2009 10:36:24 -0800 Message-ID: <4B2685A8.5070201@isi.edu> > > Fate sharing does not solve (neither its absence make worse) the > > issue of a remote address X not being uniquely associated with a > > peer. For example, with fate sharing and normal TCP there's the issue > > of an application connected to a peer application on remote address X > > not being able to connect to the same peer when issuing another > > connect(). > > > > This is different from the issue of an application expecting a > > connection to be up if and only if the remote address X is still in use > > by its peer. That one is influenced by our decision regarding fate-sharing. > > 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". In my understanding, when mptcp starts a subflow, it uses a token which was used in the initial negotiation for the first connection. If we check this token properly, we can at least distinguish whether the peer for the subflow is the right one or not. So, in my feeling, mptcp does not make the situation worse much. -- Yoshifumi Nishida nishida@sfc.wide.ad.jp