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

[Philip Levis <[e-mail]>]

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.

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.

Phil



Phil