Re: [Roll] OF0 draft v9: preferred metric, Stretch-of-Rank, configuring parameters, and editorial comments

[Phoebus Chen <[e-mail]>]

Pascal,

	You covered most of the points.

I.
Regarding the point I made below (reformatted for easy reading):

...
PC> Maybe the overview in Section 3 should also state explicitly that 
PC> the processing rules of a DIO must do 3.1, then 3.2, then 3.3, in
PC> that order.

PT> Yes, and this is what we mean by
PT> " As it scans all the candidate neighbors, OF0 keeps the parent
PT> that is the best for the following criteria (in order):"
PT> the language may not be perfect but I hardly think the reader can be
PT> getting the text wrong.
PT> I'm open to an editorial change if the sense is conserved.

 > PC> I think the text you quoted above is very clear, but given its
 > PC> location in the text (Section 4 of draft-ietf-roll-of0-10, or
 > PC> Section 3.2.1 of the suggested new order), it applies to
 > PC> parent selection. I'm saying there should be a sentence in the new
 > PC> Section 3 (overview) saying that we first compute
 > PC> Rank-Increase (Sec. 3.1), then select the preferred parent
 > PC> (Sec. 3.2.1), then select the backup successor (Sec. 3.2.2), then
 > PC> advertise Rank-Increase (Sec. 3.3).
...

I think you made edits with regard to your initial interpretation of my 
comment.  I did NOT want you change the sentence in Section 4.2.1, and 
actually, I liked the original wording of "As it scans ..." in 
draft-ietf-roll-of0-10 better.  I was suggesting a sentence in what is 
now Section 4, before Section 4.1, stating the steps in the subsections 
MUST be executed in that order.

It looks like there is nothing written about advertising the rank (a 
Section 4.3).  I guess that's OK if you feel there is nothing to say.  I 
would have preferred a short paragraph there for completeness.  It might 
just restate the obvious, that advertisements are triggered by the 
Trickle timer or changes in the rank after it is recomputed.



II.
Regarding this point I made below:
 >> PC>  On a related note, there's a recent discussion of using the ETX
 >> PC>  directly (identity) as the rank, which doesn't match this
 >> PC>  requirement that step_of_rank be a multiple of 0x100 in OF0.  In
 >> PC>  (Section 4.3.1, draft-ietf-roll-routing-metrics-19) ETX is a
 >> PC>  multiple of 128, not 256 (0x100).
 >> PC>
 >> PC>  Is it actually necessary to mention "rank-increase" in the
 >> PC>  introduction, before the terminology section?  Can we remove
 >>      "The Rank
 >>      of a node is obtained by adding a normalized scalar Rank-increase
 > to
 >>      the Rank of a selected preferred parent.  OF0 uses a unit of Rank-
 >>      increase of 0x100 so that Rank value can be stored in one octet.
 >>      This allows up to at least 28 hops even when default settings are
 >>      used and each hop has the worst Rank-increase of 9."
 >> PC>  Or move it some point later?  It may be a bit confusing to bring
 > up
 >> PC>  so much detail at this point in the text.

I think JP's comments about pointing out where many of the variables are 
defined can be handled by not going into so much detail in the 
introduction, and stating the details later.



III.
I presume you will still add Configuration Options for the configurable 
parameters in 6.2?



IV.
As for any remaining comments I have after rereading the document, they 
are about how to present and explain OF0.  Since I get the sense that 
there is some urgency to publish OF0, you can incorporate them if you 
have time - these comments shouldn't "hold the document hostage."  A few 
points in addition to JP's comments:

0) I've had trouble understanding the consensus of the discussion on the 
mailing list on OF0 not being the default objective function.  The last 
paragraph of Section 1 still doesn't make it clear to me.  As far as I 
understand, OF0 is the default objective function when no objective 
function is specified - if an implementation does not  support another 
objective function, it must support OF0.  This is the definition of 
"default," right?  If not, someone please define "default" to me... I 
must be missing something.  I would be glad to propose shorter text if I 
understood the consensus.

"  Since there is no default OF or metric container in the RPL main
    specification, it might happen that, unless two given implementations
    follow the same guidance for a specific problem or environment, those
    implementations will not support a common OF with which they could
    interoperate.  OF0 is designed to be common to all implementations
    that are not specifically designed to apply to a given case for which
    further guidance is provided.  This is why it is very abstract as to
    how the link properties are transformed into a rank_increase and
    leaves that responsibility to implementation; rather, OF0 enforces
    normalized values for the rank_increase of a normal link and its
    acceptable range, as opposed to formulating the details of its
    computation.  This is also why OF0 ignores metric containers.
"


1) You might consider adding a clarification to Section 4 is how the 
objective function is "triggered," when it enters the process of 
computing the rank, checking whether to change parents and successors, 
and readvertising the rank.  I believe there are at least 2 entry points:
	1) DIO processing
	2) change in "step_of_rank", which is implementation dependent and may 
come from layer 2.

The latter should be mentioned explicitly... it's only mentioned at the 
end of Section 3 in the last sentence.

I'm not sure if the objective function code is triggered by other timer 
expirations, like when information becomes stale.  Anyhow, it's your 
call if this is too much detail and should be left to the implementers 
to figure out on their own.


2)  I think that the paragraph at the end of Section 3:
"  OF0 assigns a step_of_rank to each link to another node that it
    monitors.  The exact method for computing the step_of_rank is
    implementation-dependent.  "
belongs somewhere in Section 4.1, maybe after the sentence:
"An implementation MUST maintain the stretched step_of_rank between
MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK, which allows to
reflect a large variation of link quality."


3) Search and replace all "rank-increase" with "rank_increase" for 
consistency.  Search and replace "Rank-factor" with "rank_factor."

Is there a convention of writing names for distinguishing variables from 
configurable parameters?  I'm assuming that "lowercase with underscores" 
(e.g., rank_factor) can be used interchangeably with "a mix of capital 
letters and lowercase letters with no underscores" (e.g., 
MinHopRankIncrease).  Do we care to distinguish the two, say using "a 
mix of capital letters and lowercase letters with no underscores" for 
parameters and "lowercase with underscores" for variables?


4) Typo, extra word "as":
    "One trivial OF0 implementation might compute the step_of_rank from 
as a classical administrative..."


5) Rewrite the equation:
R(N) = R(P) + Ri where Ri = (Rf*Sp + Sr) * MinHopRankIncrease
as

R(N) = R(P) + rank_increase
where
rank_increase = (rank_factor * step_of_rank + stretch_of_rank) *
                 MinHopRankIncrease

So we have less new variables (Ri, Rf, Sp, Sr).


6) Defining the terms "higher order interface" and "RPL Core" in the 
ROLL terminology document.



-- 
Phoebus Chen
Postdoctoral Researcher
Automatic Control Lab, KTH (Royal Institute of Technology)
http://www.ee.kth.se/~phoebus



On 5/5/11 6:07 PM, Pascal Thubert (pthubert) wrote:
> Hi Phoebus:
>
> I made editorial changes to follow your late but welcome advice, and
> published a OF0-11.
>
> Please let me know if I covered your points as expected.
>
> Cheers,
>
> Pascal
> http://www.xtranormal.com/watch/7011357/
>
>> -----Original Message-----
>> From: Phoebus Chen [mailto:[e-mail]]
>> Sent: Thursday, April 21, 2011 4:56 PM
>> To: Pascal Thubert (pthubert)
>> Cc: [e-mail]
>> Subject: Re: OF0 draft v9: preferred metric, Stretch-of-Rank,
> configuring
>> parameters, and editorial comments
>>
>> Pascal,
>>
>> 	Thanks for your responses.  I've replied inline below, preceded
> by
>> PC>.
>>
>> --
>> Phoebus Chen
>> Postdoctoral Researcher
>> Automatic Control Lab, KTH (Royal Institute of Technology)
>> http://www.ee.kth.se/~phoebus
>>
>>
>> On 4/21/11 10:41 AM, Pascal Thubert (pthubert) wrote:
>>> Hello Phoebus : )
>>>
>>> Where have you been? We've been missing your excellent comments.
>>>
>>>> 	Sorry these comments are coming so late, after last call.  I
>>> hope you
>>>> can at least incorporate some of them.
>>>
>>> [Pascal] That's beyond me. I suppose that the shepherd has to
> decide.
>>> Let's see:
>>>
>>>
>>>>
>>>> 	My comments below are based on my current understanding that
>>>> Phil and you are no longer using hop-count as the rank increment.
>>> Instead,
>>>> each node will have an implementation specific way of converting a
>>> node or
>>>> link cost to a rank.  I'm still unclear if there is a preference
> rule
>>> to try to stick
>>>> with using the same metrics as the metrics advertised in a received
>>> DIO, if
>>>> the current node has access to multiple types of metrics (energy,
> LQI,
>>> ETX,
>>>> etc.).  That would allow the root node to specify a preferred type
> of
>>> metric to
>>>> use in the instance.
>>>>
>>>>
>>>> Major Points:
>>>> *************
>>>> 1) I'm still hoping that the format for writing Objective Function
>>> specifications
>>>> can be more uniform, as I mentioned in an earlier comment (point
>>> number 7
>>>> in
> http://www.ietf.org/mail-archive/web/roll/current/msg03240.html).
>>>> Comparing MRHOF and OF0, I think that the discussion on
> Step-of-Rank /
>>>> Stretch-of-Rank etc. can be moved to it's own subsection.
>>>>
>>>> I suggest the following reorganization of sections:
>>>>
>>>>       3.  Objective Function 0
>>>>       3.1. Computing Rank-increase
>>>>       3.2. Parent / Backup Successor Selection
>>>>         3.2.1. Selection of the Preferred Parent
>>>>         3.2.2. Selection of the backup feasible successor
>>>>       3.3. Advertising Rank-increase
>>>>       4.  Interface with RPL core
>>>>
>>> [Pascal] Looks good. That much is doc organization and I suppose I
> can
>>> accommodate it at this stage.
>>> It would certainly be beneficial if both OF drafts have a common
>>> structure.
>>>
>>>> If you are allowing the root to specified a preferred metric type,
>>> then Section
>>>> 3.3. should state how to propagate this preference.  I would have
>>> assumed
>>>> it's by propagating an empty DAG/Metric Container, but in (Section
>>> 2.1, draft-
>>>> ietf-roll-routing-metrics-19) it says "The object body carries one
> or
>>> more sub-
>>>> objects defined later in this document"
>>>> which means you cannot have empty containers.
>>>
>>> [Pascal] OF0 does not have metric containers at all, so they do not
> need
>>> to be empty. That's because OF0 is generic, for the better or the
> worse.
>>> Because we want all implementations to interop with OF0, regardless
> of
>>> the medium etc...
>>>
>>> So the idea is to have no constraint on what the implementation uses
> to
>>> derive the Rank, no container, no configuration option, just the
> base
>>> RPL spec.
>>>
>>> Rather, we normalize the resulting values so they can compare
> between
>>> implementations.
>>
>> PC>  OK.  I thought allowing the root to specify a preferred metric
> would
>> PC>   be nice, but I see that it's not necessary for basic operations.
>>
>>>
>>> Now, I understand that a configuration container could help make the
> OF
>>> more self-contained/autonomic.
>>>
>>>> Maybe the overview in Section 3 should also state explicitly that
> the
>>>> processing rules of a DIO must do 3.1, then 3.2, then 3.3, in that
>>> order.
>>>
>>> [Pascal] Yes, and this is what we mean by
>>>     " As it scans all the candidate neighbors, OF0 keeps the parent
> that
>>> is
>>>      the best for the following criteria (in order):"
>>> the language may not be perfect but I hardly think the reader can be
>>> getting the text wrong.
>>> I'm open to an editorial change if the sense is conserved.
>>>
>>
>> PC>  I think the text you quoted above is very clear, but given its
>> PC>  location in the text (Section 4 of draft-ietf-roll-of0-10, or
>> PC>  Section 3.2.1 of the suggested new order), it applies to
>> PC>  parent selection. I'm saying there should be a sentence in the new
>> PC>  Section 3 (overview) saying that we first compute
>> PC>  Rank-Increase (Sec. 3.1), then select the preferred parent
>> PC>  (Sec. 3.2.1), then select the backup successor (Sec. 3.2.2), then
>> PC>  advertise Rank-Increase (Sec. 3.3).
>> PC>
>> PC>  Maybe this is obvious, but I think it helps to state it
> explicitly.
>> PC>  Especially since the guidelines given in
>> PC>  (Section 14.1, draft-ietf-roll-rpl-19) are suggestions,
>> PC>  rather than MUSTs:
>> PC>  "Most Objective Functions are expected to follow..."
>> PC>  And these suggestions don't say the steps must be followed in
>> PC>  order either.
>>
>>>>
>>>>
>>>> 2) There have been two variables and one parameter defined in the
>>>> overview section, but they are not mentioned in Section 7, OF0
>>> Constants
>>>> and Variables.
>>>> Variables: Step-of-Rank, Stretch-of-Rank
>>>> Parameters: Rank-factor
>>>> (I noticed that there is no MINIMUM_RANK_STRETCH and
>>>> DEFAULT_RANK_STRETCH and presume this is intentional.)
>>>>
>>> [Pascal] You're right. A stretch of 0 is acceptable so there is no
>>> MINIMUM.
>>>    If there was a DEFAULT I expect it should be zero as well. By
>>> compliance with the main spec.
>>> I'm fine adding it. What do you think?
>>>
>>
>> PC>  That would be nice for clarity. I think most implementors will
>> PC>  use default values in a spec without a second thought unless they
>> PC>  have a strong reason to do otherwise.
>>
>>>> Also, it would be nice to use underscore instead of hyphen for
>>>> variables, like in MRHOF (and use capital letters for parameters).
>>>>
>>> [Pascal] OK. I did not really mean those as variables, but why not.
>>>
>>>> Finally, how is Stretch-of-Rank computed?  Implementation
> dependent?
>>>
>>> [Pascal] It is not computed. It is configured and can be left to 0.
> Does
>>> not have to be there at all in an implementation.
>>> I can clarify that.
>>>
>>
>> PC>  OK.
>>
>>>> 3) How does one configure the parameter(s) (Rank-Factor) from the
>>> root?
>>>>     (I just realized that this same comment applies to the
> parameters in
>>>> MRHOF as well).   Or is that not configurable from the root, but
> must
>>> be
>>>> configured before deployment of the nodes?
>>>
>>> [Pascal] The Rank factor has to be a per node policy, like the
>>> Stretch-of-Rank. Right now, we do not have config containers to
>>> distribute it.
>>>
>>>
>>>>
>>>> 4) I think it would be nice to adopt the format of
>>>> draft-ietf-roll-rpl-19 and draft-ietf-roll-minrank-hysteresis-of
> for
>>> the
>>>> Terminology section.  That is, write the word, then the definition
>>> (this
>>>> is not done for "feasible successor" in this section).  Some other
>>> words
>>>> to define in this section are "Rank-increase," "RPL core," and
> "higher
>>>> order interface."  Unless the last one is common IPv6 terminology
> that
>>> I
>>>> am unaware of... I was unable to tell if that meant the higher
> order
>>>> bits of the interface are higher, or if the interface is somehow
>>> preferred.
>>>
>>> I think that the RPL terminology is the place for having those in
>>> common.
>>
>> PC>  Do you mean you or JP will add those terms and definitions to
>> PC>  (draft-ietf-roll-terminology-05) or
>> PC>  (Section 2, draft-ietf-roll-rpl-19)? I think the definition of
>> PC>  "Rank-increase" belongs in OF0.
>>
>>>
>>>>
>>>> 5) Just a reminder that the discussion on Rank-increase in the
>>>> introduction section
>>>> "OF0 uses a unit of Rank-increase of 0x100 so that Rank value can
> be
>>>> stored in one octet."
>>>> needs to be aligned with text in Section 3,
>>>> "Ri = Rf*Sp + Sr"
>>>> so that they are consistent.  I see you are discussing this with
>>> Omprakash.
>>>
>>> Sp and Sr are expressed as units of 0x100 and Rf is integer, so they
> are
>>> consistent. Do I miss something?
>>>
>>
>> PC>  I see.  I didn't realize that step_of_rank had to be a multiple of
>> PC>  0x100.  You only mention at the bottom of page 3 that "The exact
>> PC>  method for computing the Step-of-Rank is implementation-dependent"
>> PC>  and give bounds MINIMUM_STEP_OF_RANK and
>> MAXIMUM_STEP_OF_RANK
>> PC>  that are multiples of MinHopRankIncrease.
>> PC>
>> PC>  On a related note, there's a recent discussion of using the ETX
>> PC>  directly (identity) as the rank, which doesn't match this
>> PC>  requirement that step_of_rank be a multiple of 0x100 in OF0.  In
>> PC>  (Section 4.3.1, draft-ietf-roll-routing-metrics-19) ETX is a
>> PC>  multiple of 128, not 256 (0x100).
>> PC>
>> PC>  Is it actually necessary to mention "rank-increase" in the
>> PC>  introduction, before the terminology section?  Can we remove
>>      "The Rank
>>      of a node is obtained by adding a normalized scalar Rank-increase
> to
>>      the Rank of a selected preferred parent.  OF0 uses a unit of Rank-
>>      increase of 0x100 so that Rank value can be stored in one octet.
>>      This allows up to at least 28 hops even when default settings are
>>      used and each hop has the worst Rank-increase of 9."
>> PC>  Or move it some point later?  It may be a bit confusing to bring
> up
>> PC>  so much detail at this point in the text.
>>
>>>>
>>>> 6) I like the "Abstract Interface with RPL core" section, but would
> it
>>>> be better to separate them into "Input" and "Output"?  That would
> end
>>> up
>>>> splitting up "Providing DAG information" and "Providing a Parent
> List"
>>>> into two pieces though.
>>>>
>>>>
>>>> More minor editorial comments to follow below, preceded by PC>.
>>>
>>> Thanks for those. I'll include them in a rev.
>>>
>>>>
>>>> --
>>>> Phoebus Chen
>>>> Postdoctoral Researcher
>>>> Automatic Control Lab, KTH (Royal Institute of Technology)
>>>> http://www.ee.kth.se/~phoebus
>>>>
>>>>