Subject: Re: [Roll] Some clarifications on RPL

From: Tim Winter <[email-masked]>
Date: Mon, 06 Jul 2009 18:46:02 -0400

Hi Richard,

Richard Kelsey wrote:
>    Date: Sun, 05 Jul 2009 18:52:07 -0400
>    From: Tim Winter <[email-masked]>
> 
>    2) What about other flows?
>            [...] Nodes who are unable to learn
>    routing state pass the Destination Advertisements inward, building up
>    source routing information along the way so that they may be traversed
>    again on the outward flow.  The exact implementation of source routing in
>    support of this mechanism is not something that has been addressed by RPL
>    as yet.
> 
> In general, is adding an IP source route to a forwarded
> packet allowed?  Could a root add a source route to an
> incoming packet before forwarding it down the DAG?

It seems that such action on the part of the DAG root would make this
mechanism work much better, e.g. adding the proper source routing
information to the packet as it traverses the root and not requiring the
source of the packet to know of LLN routing internals.  But the details, and
the proper mechanisms in light of IPv6 architecture, would have to be worked
out.  There would certainly be some security considerations, etc. as well.

> 
>    3) Metrics
>            A key design point, one that may need to be further constrained, is
>    that under RPL each node does not assume that other nodes are acting
>    cooperatively, or even that they are using or understand the same set of
>    metrics.  One node could be optimizing for latency, another node could be
>    optimizing for ETX, and a third could be optimizing for
>    minimum energy.
> 
> This doesn't seem very useful to me.  To the extent that
> these three are independent, you could easily end up with
> routes that were bad at all of them.  Why is this a key
> design point?
> 
Agreed that this situation would not be very useful in practice- why would
anyone deploy such a network?  Certainly such a network is not likely to be
optimized.  BUT RPL does not currently specify any particular metrics or how
the implementation may constrain or optimize them.  And this then leads to
the possibilities that, e.g. different vendors/software
version/configurations may be deployed into the LLN, intentionally or
accidentally or over the course of years of maintenance and upgrades, which
do not work well together- they may not understand each others metrics, they
may not propagate each others metrics in expected ways, or their constraints
may work against each other.
RPL has been specified in such a way that even such a case where nodes are
not working cooperatively, they can still interoperate to the point that a
LLN can be formed with some loop avoidance and even ought to be stable (but
not necessarily optimal).
And, as you have demonstrated, in some cases RPL can be too conservative in
getting to this solution.  I am hopeful that we can come up with a way to
let this aspect of RPL work more closely with the metrics in cases where it
is safe from the loop avoidance perspective.
As this effort proceeds maybe some more work in the metrics draft can help
to clarify what a routing solution ought to be prepared to handle.  With
regard to RPL, I think that so far some of the other threads regarding the
loop avoidance metrics, etc. are making some good progress...

> Also, it seems to me that this interacts poorly with having
> a DAG.  With a tree a node receives a single value for each
> metric from its parent.  With a DAG, one parent may have a a
> low latency but high energy cost while another parent has
> high latency and low energy cost.  What metric values should
> the child advertise?

Generally, if the loop avoidance mechanism is in place to cover the `worst
case', then a child could be safe to advertise the values from the DIO
propagating from its typical case (or best case if you want to be
optimistic) parent.  If the loop avoidance mechanism comes to rely directly
on a metric, then it seems that a node should tend to propagate the
worst-case metric, for the same reason that a node gives its depth today as
deeper than its deepest feasible parent.

> 
> Given the dubious benefits of having different nodes
> optimize different metrics, and the bad interaction with
> having multiple parents, I really don't understand the
> emphasis on this feature.
> 
>                                     -Richard Kelsey
> 
It is perhaps mostly a question of interoperability.  Should such a scenario
come to pass, what should the LLN do?  Can we expect that all nodes in the
LLN will be having the same software, the same understanding of metrics and
constraints and optimization goals, etc.  When we look at a typical LLN
deployment today, maybe this is true more often than not.  But as we open up
the possibility for LLN nodes to truly interoperate with standards-based
IPv6, what then?  RPL in its present form is trying to establish some base
guidelines as to how such a heterogeneous LLN might organize itself, while
leaving some freedoms for the implementors...

-Tim

---

From: Richard Kelsey <[email-masked]>
Date: Tue, 07 Jul 2009 10:18:41 -0400

Hi Tim,

> Date: Mon, 06 Jul 2009 18:46:02 -0400
> It is perhaps mostly a question of interoperability.  Should such a
> scenario come to pass, what should the LLN do?  Can we expect that
> all nodes in the LLN will be having the same software, the same
> understanding of metrics and constraints and optimization goals,
> etc.  When we look at a typical LLN deployment today, maybe this is
> true more often than not.  But as we open up the possibility for LLN
> nodes to truly interoperate with standards-based IPv6, what then?
> RPL in its present form is trying to establish some base guidelines
> as to how such a heterogeneous LLN might organize itself, while

In the interests of promoting interoperability, I think that
we could give implemetors and anyone designing a metric a
bit more help in interoperating with other, possibly
unknown, metrics.  Having a DAGcost metric that is additive
with a minimum link cost greater than one gives
interoperation a big step up.  Different devices in a mixed
network will still be optimizing different metrics, but at
least paths will be chosen with some attempt at overall
optimization.  This is epecially useful with metrics that
are interdependent.  The same links are likely to have a low
ETX, low latency, and high reliabilty, for example.  As it
stands now, a device which has several potential parents at
the same depth but who do not advertise a known metric has
only the last hop metric for making a choice.

                                    -Richard Kelsey

---

From: JP Vasseur <[email-masked]>
Date: Tue, 7 Jul 2009 15:30:24 +0200

Hi Tim,

>> incoming packet before forwarding it down the DAG?

There is nothing that prevents you from doing this (RH0 has been  
deprecated though but this is not a major issue). Still and I have  
been trying to resist from discussing this issue until we had the  
basics sorted out and agreed upon, there are several options to do this:
1) Classic source routing: although not used for IP, it has been in  
use for years by MPLS with strict and loose source routing with RSVP- 
TE. Still we may have a serious issue with deep networks if using  
uncompressed addresses ... defining statefull address compression  
brings its own challenge.
2) Label switching: not just because I spent many years working on  
MPLS but this may solve several issues although we would need to add  
label management with in band or out of band label allocation.

If OK with you I would suggest to leave it as an open action item for  
the time being.

> loop avoidance metrics, etc. are making some good progress...

Yes, see my comments on the use of consistent metrics though.
Richard, don't you see the need for using several metrics? In this  
case, you may end up with nodes trying to optimize for different  
metrics ...

>> emphasis on this feature.

It is not just a feature ... you may indeed mix nodes interesting in  
optimizing different metrics. My suggestion is to make sure that we do  
not end up with path mixing up metrics of different types.

> scenario

Right.

JP.

>
> -Tim
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Richard Kelsey <[email-masked]>
Date: Wed, 08 Jul 2009 10:09:30 -0400

JP,

   From: JP Vasseur <[email-masked]>
   Date: Tue, 7 Jul 2009 15:30:24 +0200

Yes, I think we have to allow the use of different metrics.
For networks that agree on a metric or set of metrics we
should keep the loop avoidance from getting in the way more
than necessary.  For networks where different nodes are
using different metrics we can supply a generic cost scaling
that at allows related metrics to take advantage of their
commonality.

I think that using a DAGCost with three or four bits of
fraction and with a minimal link cost of one works well
in both cases.
                                  -Richard Kelsey

---

From: JP Vasseur <[email-masked]>
Date: Thu, 9 Jul 2009 08:43:57 +0200

Hi Richard,

On Jul 7, 2009, at 4:18 PM, Richard Kelsey wrote:

> unknown, metrics.

This is the aim of the METRIC ID: metrics will be standardize as well  
as probably the
objective function. Agree.

> Having a DAGcost metric that is additive

We discussed adding the set of metrics in use in the RA, fully agree.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 9 Jul 2009 16:34:03 +0200

Hi Richard,

JP.