Re: [Roll] Ralph's DISCUSS on MRHOF spec

[Ralph Droms <[e-mail]>]

On Jun 8, 2012, at 1:28 PM 6/8/12, Philip Levis wrote:

> 
> On Jun 8, 2012, at 9:31 AM, Ralph Droms wrote:
> 
>> 
>> On Jun 8, 2012, at 10:11 AM 6/8/12, Michael Richardson wrote:
>> 
>>> 
>>>>>>>> "Philip" == Philip Levis <[e-mail]> writes:
>>>  Philip> I agree that this is a good question to ask. I disagree that
>>>  Philip> now is an appropriate time to answer it definitively; we
>>>  Philip> currently have only one OCP. We made a concrete and
>>>  Philip> deliberate design decision. I'd argue we should stick with
>>>  Philip> it to at least see it play out a bit more. E.g., once MRHOF
>>>  Philip> is actually a proposed standard and we have significant
>>>  Philip> experience using it. It's so critical in systems design to
>>> 
>>> I think what you are saying is that splitting MRHOF into multiple OCPs
>>> in the future would not be so difficult a thing to do.
>> 
>> Yeah, but once the code is deployed, nobody is going to make changes.
>> 
>>> There is a coding simplicity in what we have now, and we should be
>>> conscious of the constraints of our devices.
>> 
>> I'll push back a little - inferring the metric from the received DIO is certainly no simpler than learning the metric directly from the OCP...
> 
> 
> Ralph,
> 
> Let's separate two issues:
> 
> 1) OCPs should not have metric flexibility
> 2) There should be multiple MRHOFs, for different metric combinations
> 
> We decided against 1) in the design phase due to conversations JP had with some RPL users. The argument was that there are situations where you might want to dynamically shift the operation of the network. E.g., you have an OF that optimizes for two metrics, primary and secondary. You have a RPL network designed for monitoring physical security and reporting potential intrusions. In the monitoring phase, energy is the primary metric, with latency second. In the reporting/alert phase, latency is the primary metric and energy is the secondary metric. 
> 
> If we decide 1), then it's not possible to do the above approach unless you include two separate OFs. Furthermore, let's say you want to just use energy? Or just use latency? You lose flexibility. The point is that this is a one way street. If you allow metric flexibility, then you can define OFs that only support one metric. If you do not allow metric flexibility, then you cannot define OFs that are flexible with respect to metrics.

I have to say this is the first I've heard, based on the specs I've reviewed to date, of an OF that would dynamically change its behavior. 

Why wouldn't RPL Instances - one optimized for low latency and one optimized for low energy - be an acceptable and simpler solution?  How would the metric be changed atomically?  How would nodes be notified that the metric had changed?

Metric flexibility seems like a hypothetical that needs more thought and additional mechanism in RPL to become real.  In any event, I'll clarify that I wasn't thinking that every the OCP for every OF encode the metric for that OF.  It seemed, in the case of MRHOF, that a separate OCP for each metric might solve the problem of indicating the selected metric to a receiving node.

> With respect to 2), I'd love to hear from the folks implementing MRHOF whether they think this is a good idea. Are there cases where the flexibility is useful? ETX is stated as the least common denominator through a SHOULD. My worry right now is that we're pursuing a not-unreasonable-but-mostly-hypothetical concern. As I said before, asking the question is great, but we don't want to reverse years of agreed-upon-reasoning and tradeoff decisions without careful thought.

We may not be talking about the same issue, as I don't quite understand your question about flexibility.  Can you say more about it?

Do we agree that the selected metric for a RPL Instance using MRHOF needs to be indicated to the receiving node for the node to make a policy decision about whether to join the RPL Instance?

- Ralph
  

> Phil
> 
> 
> 
> Phil
>