Subject: [Roll] Kick metrics out of Objective Functions?

From: <[email-masked]>
Date: Fri, 21 May 2010 22:51:12 +0200

Dear all,
The current situation is that the metrics to be recorded/accumulated are
defined in a DIO, while the combination/comparison algorithm to select
the best route(s) based on these metrics is described in OF  documents.
I find this situation suboptimal, for several reasons:
* given the variety of LLNs applications out there and there need for
complex combined metrics fitted to their application, it seems every
system vendor will want to define its own Objective Function, thereby
multiplying RFCs and reducing interoperability between devices of
different vendors to one OF, namely OF0. 
* once a network is deployed, the nodes only know a few OFs, those that
have been programmed in. A firmware updgrade is required to change the
routing behavior beyond that. Given that nodes are going to be deployed
for years in the field, I would want RPL to be more flexible at run
time. 
Therefore, I suggest we remove  from the OF documents the description of
the way the metrics are combined and the best route(s) selected, and
provide a flexible model to encode this directly in the DIO, much like
we already describe in a DAG Metric container how metrics are
accumulated or recorded along a path. Some ideas will be proposed in a
later post.
Thoughts from the WG ?
Best regards
Dominique

---

From: JP Vasseur <[email-masked]>
Date: Sat, 22 May 2010 08:44:31 +0200

Hi Dominique,

On May 21, 2010, at 10:51 PM, <[email-masked]> <[email-masked] 
 > wrote:

> Dear all,
> The current situation is that the metrics to be recorded/accumulated  
> are defined in a DIO, while the combination/comparison algorithm to  
> select the best route(s) based on these metrics is described in OF   
> documents. I find this situation suboptimal, for several reasons:
>
> · given the variety of LLNs applications out there and there need  
> for complex combined metrics fitted to their application, it seems  
> every system vendor will want to define its own Objective Function,  
> thereby multiplying RFCs and reducing interoperability between  
> devices of different vendors to one OF, namely OF0.
>
> · once a network is deployed, the nodes only know a few OFs, those  
> that have been programmed in. A firmware updgrade is required to  
> change the routing behavior beyond that. Given that nodes are going  
> to be deployed for years in the field, I would want RPL to be more  
> flexible at run time.
>
> Therefore, I suggest we remove  from the OF documents the  
> description of the way the metrics are combined and the best  
> route(s) selected, and provide a flexible model to encode this  
> directly in the DIO, much like we already describe in a DAG Metric  
> container how metrics are accumulated or recorded along a path. Some  
> ideas will be proposed in a later post.
>
Thanks for your email. I fully agree (in line with the "decoupling  
metric and OF" email I sent out some time ago).
> Thoughts from the WG ?
> Best regards
> Dominique
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Omprakash Gnawali <[email-masked]>
Date: Sat, 22 May 2010 09:28:52 -0700

On Fri, May 21, 2010 at 1:51 PM,  <[email-masked]> wrote:
> defined in a DIO, while the combination/comparison algorithm to select the
> best route(s) based on these metrics is described in OF  documents. I find
> this situation suboptimal, for several reasons:
>
> · given the variety of LLNs applications out there and there need for
> complex combined metrics fitted to their application, it seems every system
> vendor will want to define its own Objective Function, thereby multiplying
> RFCs and reducing interoperability between devices of different vendors to
> one OF, namely OF0.

... based on the assumption that we will only have one OF defined.

This argument is similar to the one we heard a little while ago. We
are assuming that we need to cover every imaginable combination of
metrics in the OFs. I had asked what these likely combinations are. Do
they work? How have they been used? If we have a small number of
examples that people have found useful in practice, lets define the
OFs. If there are a large number of these, that would be a motivation
for working on some of these generalizations.

> · once a network is deployed, the nodes only know a few OFs, those that have
> been programmed in. A firmware updgrade is required to change the routing
> behavior beyond that. Given that nodes are going to be deployed for years in
> the field, I would want RPL to be more flexible at run time.
>
> Therefore, I suggest we remove  from the OF documents the description of the
> way the metrics are combined and the best route(s) selected, and provide a
> flexible model to encode this directly in the DIO, much like we already
> describe in a DAG Metric container how metrics are accumulated or recorded
> along a path. Some ideas will be proposed in a later post.

There are many aspects of a metric that are not represented in the
metric value. For example, the type of hysteresis and thresholding
that results in stable routing for ETX and latency might be completely
different although both are just numbers, accumulated over the hops,
and the smaller the better. Encoding everything about a metric and how
it is to be used in routing would require a much more complex
representation of them. But then again, I haven't been convinced by
the stated motivation for this generalization.

- om_p

---

From: Philip Levis <[email-masked]>
Date: Sat, 22 May 2010 10:39:20 -0700

On May 22, 2010, at 9:28 AM, Omprakash Gnawali wrote:

>> that have
>> description of the

I agree. Let's keep things simple.

Phil

---

From: JP Vasseur <[email-masked]>
Date: Mon, 24 May 2010 18:24:30 +0200

On May 22, 2010, at 6:28 PM, Omprakash Gnawali wrote:

> On Fri, May 21, 2010 at 1:51 PM,  <[email-masked] 
> > wrote:
>> Dear all,
> metrics in the OFs.

Not "every" but certainly a few of them and the combination of them  
can quickly become
non negligible. Note that several of the metrics and constraints  
defined in the metric ID
are derived from the requirements documents.

> I had asked what these likely combinations are. Do

When defining a new protocol, it is safer to make it as flexible as  
possible. Since the nature
of the metric or the constraint is specified in the metric itself (see  
metric ID), re-specifying the
metric / constraint in the OF reduces flexibility and adds complexity.  
Bu not encoding the
metric/constraint in the OF, and use the routing attributes as  
specified in the metric-ID, the
models increases flexibility, reduces complexity at no cost. Makes  
sense ?

> and the smaller the better.

Right. Some of these may be implementation specific (when they do not  
compromise
interoperability), others may be specified in the OF for that matter.

> Encoding everything about a metric and how
> representation of them.

The point is just to not encode the metric and constraint in the OF to  
provide more
flexibility. And again this is already there as metrics are specified  
in the metric-ID.

Would you agree ?

Thanks.

JP.

> But then again, I haven't been convinced by

---

From: Philip Levis <[email-masked]>
Date: Mon, 24 May 2010 09:35:08 -0700

On May 24, 2010, at 9:24 AM, JP Vasseur wrote:

> Not "every" but certainly a few of them and the combination of them can quickly become
> non negligible. Note that several of the metrics and constraints defined in the metric ID
> When defining a new protocol, it is safer to make it as flexible as possible. Since the nature
> of the metric or the constraint is specified in the metric itself (see metric ID), re-specifying the
> metric / constraint in the OF reduces flexibility and adds complexity. Bu not encoding the
> metric/constraint in the OF, and use the routing attributes as specified in the metric-ID, the
> models increases flexibility, reduces complexity at no cost. Makes sense ?

Yes -- but that methodology (which has served the IETF well in other domains) is problematic here. Flexibility and generality have a cost, in terms of code size, code complexity, and packet sizes. We have very well defined use cases; we should design for them and not try to boil the ocean. Unless you think that we should include a bytecode language for interpreting new Objective Functions?

Phil