Re: [Fwd: [Forces-protocol] Presentation of the options forLFB-level multicast]

"Joel M. Halpern" <joel@stevecrocker.com> Fri, 12 November 2004 16:20 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16543 for <forces-protocol-web-archive@ietf.org>; Fri, 12 Nov 2004 11:20:08 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSeB7-0003s5-IB for forces-protocol-web-archive@ietf.org; Fri, 12 Nov 2004 11:21:38 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSdxH-0002yG-Oy; Fri, 12 Nov 2004 11:07:19 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSdmU-0007fq-VL for forces-protocol@megatron.ietf.org; Fri, 12 Nov 2004 10:56:12 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14484 for <forces-protocol@ietf.org>; Fri, 12 Nov 2004 10:56:08 -0500 (EST)
Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSdnt-0003DH-Jj for forces-protocol@ietf.org; Fri, 12 Nov 2004 10:57:37 -0500
Received: from [130.129.133.92] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7934179; Fri, 12 Nov 2004 10:56:05 -0500
Message-Id: <6.1.2.0.0.20041112105438.03a67ec0@localhost>
X-Sender: joel@stevecrocker.com@localhost
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Fri, 12 Nov 2004 10:55:53 -0500
To: "Wang,Weiming" <wmwang@mail.hzic.edu.cn>, hadi@znyx.com
From: "Joel M. Halpern" <joel@stevecrocker.com>
Subject: Re: [Fwd: [Forces-protocol] Presentation of the options forLFB-level multicast]
In-Reply-To: <155001c4c8c0$5eb73ec0$845c21d2@Necom.hzic.edu.cn>
References: <4189F776.4080306@zurich.ibm.com> <1099700691.1038.2.camel@jzny.localdomain> <005101c4c408$dc341600$020aa8c0@wwm1> <1099752095.1037.11.camel@jzny.localdomain> <003201c4c46d$1bbce4a0$020aa8c0@wwm1> <004201c4c4ec$61d34c20$020aa8c0@wwm1> <1099829057.2165.18.camel@jzny.localdomain> <00bd01c4c536$fb418ee0$020aa8c0@wwm1> <1099885892.2167.13.camel@jzny.localdomain> <132001c4c551$86023150$845c21d2@Necom.hzic.edu.cn> <1099911200.2169.29.camel@jzny.localdomain> <134f01c4c585$216584c0$845c21d2@Necom.hzic.edu.cn> <4191299F.4020809@zurich.ibm.com> <142a01c4c6d6$13569980$845c21d2@Necom.hzic.edu.cn> <1100100893.2210.24.camel@jzny.localdomain> <14fc01c4c79f$75231f20$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20041111091015.03bafec0@localhost> <155001c4c8c0$5eb73ec0$845c21d2@Necom.hzic.edu.cn>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>, "(Ram Gopal )" <ram.gopal@nokia.com>, Avri Doria <avri@acm.org>, forces-protocol@ietf.org, Patrick Droz <dro@zurich.ibm.com>, David.Putzolu@intel.com, Dong Ligang <donglg@mail.hzic.edu.cn>, Robert Haas <rha@zurich.ibm.com>
X-BeenThere: forces-protocol@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: forces-protocol <forces-protocol.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/forces-protocol>, <mailto:forces-protocol-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/forces-protocol>
List-Post: <mailto:forces-protocol@ietf.org>
List-Help: <mailto:forces-protocol-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/forces-protocol>, <mailto:forces-protocol-request@ietf.org?subject=subscribe>
Sender: forces-protocol-bounces@ietf.org
Errors-To: forces-protocol-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034

This is an important question.
I agree that tables will develop holes.  However, because the index has no 
operational significance, it will be very easy and natural to reuse those 
holes.  Hence, the tables will not become progressively more sparse.  The 
mechanisms must cope with hole.  But we do not have to expect tables where 
only 1 in every three indices are used or some such.

Yours,
Joel

At 09:03 AM 11/12/2004, Wang,Weiming wrote:
>Joel,
>
>One more thing is, for index based searching, after some operation such as 
>add,
>delete and modify, the table actually will also become a random table rather
>than a linear one regarding the index. In this case, I see that the index
>actually plays no more efficient role other than a general content searching,
>i.e., it has actually become content(the content is the index) based 
>searching.
>Therefore, in this case, I cannot see any advantage to explicitly define Index
>in the protocol over to just define the 'index' as a field in the table
>structure. For latter, the path will not include any explicit index 
>anymore, to
>do index based operation is to assign an  'index'  field value.
>
>Cheers,
>Weiming


_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol