Re: [Roll] RPL Metric ID
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Roll] RPL Metric ID
Hi,
On Oct 13, 2009, at 11:12 AM, Anders Brandt wrote:
Mukul Goyal wrote:
I think both latency and reliability are important metrics.
Same for me.
One word of warning on the energy discussion:
It seems like the assumption is that the routing protocol should
manage
the number of transmitted packets in order to ensure that the energy
consumption is distributed among more nodes.
that would be the objective by using node energy level, which may be
useful
for SOME networks (not all for sure).
There is however a caveat here:
From our experience, a radio uses energy. Period.
Receiving uses the same as transmitting - the difference is just which
amplifiers use the energy.
Thus, the way to use less energy is to use the radio less - i.e. sleep
some of the time. Which again translates into higher latency to reach
such nodes. Obviously, there is something to save, since a radio may
quickly determine if it is the intended recipient of a packet and
return
to sleep again OR receive the entire packet and stay awake to forward
the packet on to another node in the network.
Thus, what I am trying to say is:
Unless the lower layers have a smart way of quickly returning to sleep
(which some technologies have) the routing protocol will keep all
nodes
awake within direct range - and they will all use power for
listening =>
nothing gained from distributing the traffic.
Can battery-powered 802.15.4. nodes quickly return to sleep if they
are
not the intended recipient?
If not, the energy metric may be rather useless (?)
I saw Adam answered already.
JP.
Cheers,
Anders
-----Original Message-----
From: roll-bounces at ietf.org [mailto:roll-bounces at ietf.org] On Behalf
Of
JP Vasseur
Sent: 12. oktober 2009 13:46
To: Tim Winter
Cc: roll at ietf.org
Subject: Re: [Roll] RPL Metric ID
On Oct 9, 2009, at 4:08 PM, Tim Winter wrote:
Mukul Goyal wrote:
I think both latency and reliability are important metrics.
+1
We have a good consensus to have both latency and reliability. We now
need to agree on the units.
Unit for latency ?
Unit for ETX (I propose to use the ETX): thoughts ?
I am sort of negative on using memory/CPU availability as metric or
constraint. They seem like local factors to me. If a node is running
low on memory/CPU, it can simply not participate in routing.
Exposing an exaggerated rank might also be an option.
Indeed, although we have planned to use an Overload bit since we may
not
want all nodes to trigger a DAG recomputation but only to not send
traffic until the bit is cleared.
Cheers.
JP.
-Tim
Thanks
Mukul
----- Original Message -----
From: "JP Vasseur" <jvasseur at cisco.com>
To: "IETF ROLL" <roll at ietf.org>
Cc: "Kris Pister" <kpister at dustnetworks.com>
Sent: Wednesday, October 7, 2009 1:07:52 PM GMT -06:00 US/Canada
Central
Subject: [Roll] RPL Metric ID
Dear all,
We would appreciate your feed-back on RPL routing metrics.
Now that RPL is stabilizing it is time to move forward with the
METRIC I-D. The next revision will be a major one, with packet
encoding, processing rules, etc.
We discussed and agreed some time ago on several links and nodes
metrics (also required according to our requirement IDs).
Still, there are a few metrics for which we would like to know
whether you think that they should be specified.
4.2. Latency
As with throughput, the latency of many LLN MAC sub-layers can
be varied over many orders of magnitude, again with a
corresponding change in current consumption. Some LLN MACs will
allow the latency to be adjusted globally on the subnet, or on a
link-by-link basis, or not at all. Some will insist that it be
fixed for a given link, but allow it to be variable from link to
link. For efficient operation, nodes must be able to report the
range of latency that their links can handle, and the currently
available latency.
4.3. Link reliability
In LLNs, link reliability is degraded by external interference
and multi-path interference. Multipath typically affects both
directions on the link equally, whereas external interference is
sometimes uni- directional. Time scales vary from milliseconds
to days, and are often periodic and linked to human activity.
Packet error rate can generally be measured directly, and other
metrics (e.g. bit error rate, mean time between failures) are
typically derived from that.
In addition:
Node Memory resources:
Memory is a critical node resources in presence of constrained
nodes.
Is there a need to report node memory resources as a routing
metric/constraint ?
Node CPU resources: CPU duty cycle for virtually all LLN
applications
to date is well below 10%, and the trend in low power embedded
systems is to more capable processors rather than less.
Computational speed is not expected to be a limiting factor in
routing in LLNs. Is there a need to report node CPU resources as a
routing metric/constraint ?
Link Security metrics
Thanks for your feed-back.
JP, Mijeon, Kris. _______________________________________________
Roll mailing list
Roll at ietf.org
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll at ietf.org
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll at ietf.org
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll at ietf.org
https://www.ietf.org/mailman/listinfo/roll
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
