Re: [Forces-protocol] RE: GET/SET in one msg ?

"Joel M. Halpern" <jhalpern@MEGISTO.com> Wed, 20 October 2004 01:49 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 VAA14376 for <forces-protocol-web-archive@ietf.org>; Tue, 19 Oct 2004 21:49:46 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK5ns-0002na-81 for forces-protocol-web-archive@ietf.org; Tue, 19 Oct 2004 22:02:32 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK3yY-0005xx-Lc; Tue, 19 Oct 2004 20:05:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJuCb-000682-J8 for forces-protocol@megatron.ietf.org; Tue, 19 Oct 2004 09:39:01 -0400
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 JAA25003 for <forces-protocol@ietf.org>; Tue, 19 Oct 2004 09:38:54 -0400 (EDT)
Received: from [64.254.114.114] (helo=megisto-e2k.megisto.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJuOT-0005Tt-MI for forces-protocol@ietf.org; Tue, 19 Oct 2004 09:51:33 -0400
Received: from JLaptop.megisto.com ([192.168.20.163]) by megisto-e2k.megisto.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 19 Oct 2004 09:38:39 -0400
Message-Id: <5.1.0.14.0.20041019093826.0232d418@mail.megisto.com>
X-Sender: jhalpern@mail.megisto.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 19 Oct 2004 09:38:34 -0400
To: "Wang,Weiming" <wmwang@mail.hzic.edu.cn>, hadi@znyx.com
From: "Joel M. Halpern" <jhalpern@MEGISTO.com>
Subject: Re: [Forces-protocol] RE: GET/SET in one msg ?
In-Reply-To: <03a101c4b590$21dcc0d0$845c21d2@Necom.hzic.edu.cn>
References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <013101c4b51d$a50761e0$020aa8c0@wwm1> <1098134060.1077.446.camel@jzny.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-OriginalArrivalTime: 19 Oct 2004 13:38:39.0489 (UTC) FILETIME=[F1103710:01C4B5E0]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>, ram.gopal@nokia.com, forces-protocol@ietf.org, "Steven Blake (petri-meat)" <slblake@petri-meat.com>, zsolt@nc.rr.com, Alan DeKok <alan.dekok@idt.com>, Ellen M Deleganes <ellen.m.deleganes@intel.com>, "Yang, Lily L" <lily.l.yang@intel.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: c0bedb65cce30976f0bf60a0a39edea4

I do think that there may be thousands of instances.
I do not think that this requires multiple addressing.

I think that there are some interesting cases prompted by the possibility 
of very large numbers of LFBs, but they do not drive multiple addressing.

My reasoning is based on the following premise.
Firstly, if there are many LFBinstances s of a class, then it is likely 
that many fields of the LFB instances will be the same, but it is extremely 
unlikely that all fields of the LFB instances will be the same.
The simplest case to understand when one would need to setup all those LFBs 
at once is in a power recovery situation  (the FE lost power, then 
recovered to an empty state.)  The CE needs to send the configuration 
information to the FE.
Secondly, I believe that transaction count is much more important than data 
volume.  The FE is going to have to set every field in every LFB.  Encoding 
is not going to change that.
Given that there are distinct values in each LFB instance, there must be an 
operation against each LFB instance.

The marginal gain from having a single transaction to update the identical 
fields, and then individual transactions for the distinct fields is very 
small.  It does not reduce the number of IOs or the core transaction rate.

If it is desired to optimize for this case, we may want to introduce (in a 
future version of the protocol) some kind of block checkpoint / restart 
mechanism.  The CE would record its full state about the FE, and then ask 
the FE for a dump suitable for restoral of the FE state.  Upon restart, the 
CE would rebuild its state from its stored representation, and would ship 
the dump back to the FE to enable efficient rebuilding there.  I can see 
significant value in such a mechanism.  I do not however see a need to 
include this in the first deliverable of the protocol.

Yours,
Joel M. Halpern

At 12:00 PM 10/19/2004 +0800, Wang,Weiming wrote:
>Jamal,Hormuzd, and Joel,
>
>I think we have already have the issue as an editorial note as below:
>
>        Editorial Note:
>                         1.  Under discussion is, when an 'FE Protocol ...
>
>                         2.  Under discussion is, do we need to support
>                             multiple objects addressing at the LFB Type
>                             and LFB Instance layer? One simple way to
>                             support multiple LFB types or instances is
>                             to use TLVs to identify the group of Type
>                             IDs and Instance IDs, rather than only one
>                             Type and Instance ID.  A range of Instance
>                             IDs may also be supported in this way.
>
>Hormuzd and Joel, do you really think it is not the case? I remember Joel
>supposed there might be thousands of instances with same LFB calss.  In this
>case, if we do not support a range of intance addressing, it actually 
>makes our
>protocol unpractical.
>
>regards,
>Weiming


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