Subject: Re: On efficiency, ambiguity, and simplicty of BLK Selector WAS(Re: Ambiguity in BLOCK semantics-some qs?

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Wed, 16 Feb 2005 12:22:13 -0800

Jamal,

Another contentious issue that you pointed me to was using KEY and BLK
selector in the same Op TLV. Is this still contentious ? I agree with
Joel's view that these cannot be combined.

Do we have agreement on this ?

Thanks
Hormuzd 

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
Sent: Wednesday, February 16, 2005 8:31 AM
To: [email-masked]
Subject: [FORCES] On efficiency, ambiguity, and simplicty of BLK
Selector WAS(Re: Ambiguity in BLOCK semantics-some qs?

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 16 Feb 2005 15:33:39 -0500

I dont think theres any contention on this issue.
Maybe Weiming didnt like it? I dont remember. The short answer is 
yes, this is the way it is and the update to the draft will only
mention BLK once and say this as well.

cheers,
jamal