Subject: Re: Ambiguity in BLOCK semantics-some qs?

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Tue, 15 Feb 2005 17:12:46 -0800

Joel,

Thanks for your reply...Pls see my comments inline.. 

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Joel M. Halpern

One the nested PATH-DATA, this was an efficiency mechanism.  As you say,

everything it can do can be done without it.
However, there are two important factors:
1) It is simple, well defined, easy to describe, and I think reasonably 
easy to implement.
2) It covers a case that is clearly likely, namely setting multiple
things 
in the same portion of the LFB.
I think it is a good efficiency tradeoff.

[HK] I actually don't think I see any additional efficiency because of
this. The example in the text that Jamal sent out...#17a&b doesn't give
me the impression of one being more efficient. Let me know what I am
missing. But if the efficiency is not significant, this is definitely
something that strikes me as a good candidate for simplification.

My view on the DATARAW with indices is that it is for use when we are 
representing the whole table.  It seems to me that one important use
case 
for setting into a table is where we are resetting the table, creating
the 
new entries and throwing away whatever was in the table before (just as 
setting a variable discards the old value.)  If we used indices in a 
DATARAW for a table to enable selective block operations, then we would 
need some other way to handle setting the "whole" table.

[HK] Why is this the case? We can just use different Operation names,
e.g. Add or Update to distinguish between the different scenarios. I
don't think there is a need to distinguish the DATARAW semantics for
block operations or setting the entire table. May be you can give me an
example for why this wont work ?

And it should be pointed out that this would still leave many of
reasonable 
the uses of BLK unsupported.
[HK] Could you provide me with some example here?

Thanks
Hormuzd

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 15 Feb 2005 21:50:33 -0500

How much efficiency one gets from the nested path-datas depends upon how 
deepd you think the table a structure constructs will get.
If they are relatively shallow, the gains are marginal.
If they are deep, then it is noticeable.  Example 18 (I think) shows what 
happens when things get deep.

In fact, the payoff likely comes when one is trying to set multiple (5+?) 
things within a nested context.  Then it does start to matter.

Whether this is worth it or not is something on which reasonable folks can 
differ.  I am trying not to take the "kill all the lawyers" view of ideas, 
so since this one seems easy, it makes sense to me.

Since the DATARAW is actually a nested construct of related TLVs (variable 
size structure, string, octetstring, and array) I suppose we could have one 
for "selected rows of an array".  For me, DATARAW TLVs represent structures 
that are mapped in the definition.   I may be being too picky.
On the question of what this would not cover, the simplest example is for 
an array whose contents are a structure with more than 1 element (say x1, 
x2, ...).
With block, one can indicate one wants to set just the x2 part of several 
array elements.  If one starts extending DATARAW to say that, then the 
DATARAW becomes the path-data.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 16 Feb 2005 11:30:52 -0500

Folks,

First off let me say that the next release of the draft(which i am
editing as we speak) will leave out using BLK selector. That does not
mean it is dead; it just means its defered so we can make progress. 

Despite leaving out BLK, I have to say Iam pleased at the progress we
made - thanks to everyone who chipped in. We do have finally something i
would almost call usable and semi-agreeable to all. 
I am hoping any changes going forward (including BLK if we find it
usable) will not deviate us from the main BNF and layout and will be
mostly cosmetic in nature.
 
Its always great to make progress in the presence of many good ideas. 
So thanks again.

So this email is not about what goes into upcoming draft.
However, since the discussion continues on the BLK avenue, I am going to
contribute since i am a fan of BLK.

1) Efficiency factor.
Is there anyone _doubting_  that BLK is more efficient for row table
operations than without it? If there is i will provide the proof
numbers.
An average BLK operation will be cheaper on the wire
than non-BLK and will have at least one less nest level.
So BLK wins down both in b/width and parsing/compute.

Again, if anyone wishes to contend this let me know so i can provide the
numbers. If noone contends this, lkets cut the discussions and never
bring it up but assume it for any future discussion.

2) Ambiguity:
Theres none really as far as i am concerned. Its a difference of opinion 
more than anything else between Joel and myself.
Joel has a certain view of what it means to follow a selector.
which is different from mine. 
Maybe this is the most important thing that we need to be discussing.

3) simplicty.
I fail to see this being used as an arguement for non-BLK. 
Lets take an average example (any other examples of the same nature would look
similar - some would make BLK look better but they are corner cases as
far as i am concerned):

"create entry 0-5 of table2"
I) Using BLK selector

        Path-data TLV: 
                flags = F_CREATE | F_SELBLK , IDCount = 1, IDs=4
                BLK_RANGE_INDEX TLV
                        start = 0
                        end = 5
                DATARAW TLV: L = XXX, V=
                       j1value,j2value  entries (6 in total)

II) not using BLK selector

        Path-data-TLV: 
                flags = 0 , IDCount = 1, IDs=4
                PATH-DATA-TLV
                    flags = 0, IDCount = 1, IDs = 0
                    DATARAW-TLV containing j1, j2 value for 0
                PATH-DATA-TLV
                    flags = 0, IDCount = 1, IDs = 1
                    DATARAW-TLV containing j1, j2 value for 1   
                PATH-DATA-TLV
                    flags = 0, IDCount = 1, IDs = 2
                    DATARAW-TLV containing j1, j2 value for 2
                PATH-DATA-TLV
                    flags = 0, IDCount = 1, IDs = 3
                    DATARAW-TLV containing j1, j2 value for 3
                PATH-DATA-TLV
                    flags = 0, IDCount = 1, IDs = 4
                    DATARAW-TLV containing j1, j2 value for 4 
                PATH-DATA-TLV
                    flags = 0, IDCount = 1, IDs = 5
                    DATARAW-TLV containing j1, j2 value for  5

So which one is simpler?
To be honest i dont see them being that different to the machine parsing
them - to the human eye the BLK one is good candy, but i wouldnt use this
as a strength for BLK; 
so we probably shouldnt be discussing this "simplicty" angle either.

This leaves us with #2 and #1 being a trump in favor of BLK.

cheers,
jamal