From: Philip Levis <pal at cs.stanford.edu>
Date: Wed, 14 Oct 2009 21:49:10 -0700
I think we should keep in mind that RPL must work across multiple link
layers. E.g.:
A -- 900MHz --> B -- 2.4GHz --> C
Or maybe a PLC link or two.
ETX is a commonly used metric, but typically under two simplifying
assumptions:
1) Routes are composed of a single link layer
2) The link layer has a static bitrate
If you break either assumption, it doesn't work well. ETT (expected
time of transmission) can address 2), but not 1).
I'm wary of encoding a metric as a hard quantity. For example,
quantifying the metric as uJ breaks when nodes have differential
energy capacities. What we really want is a more abstract notion of
cost, which a particular device can use to, in a very simple way,
express its own tradeoffs. It is critical that exactly how devices
calculate this value remain unspecified.
I would agree that this is true as far as ROLL and the IETF
is concerned. More concrete and layer-specific
specifications can, and probably will, be produced by
other organzations.
My first thought would be a quantification of how much of a node's
"lifetime" a packet would cost. Such a cost can consider both the
receiver and transmitter. E.g., given its particular low power
algorithms and expected lifetime, how much would sending to this
destination consume? (I try to avoid using the word "link.")
An 'available bandwidth' metric works for this. For a
battery powered device you know the desired lifetime, the
amount of energy in the battery, and how much of this will
be consumed by the device itself. The leftover energy,
divided by the desired lifetime and the cost of sending and
receiving, gives the bandwidth the device can donate to the
network. This works for energy scavenging devices as well,
assuming that the scavenging rate is predictable.
I don't think that a single metric will be sufficient; besides some
notion of cost (hopcount, ETX, ETT, etc.), the other metric that is
critical in many applications is latency. These two -- cost and
latency -- can cover a large portion of the application design space,
and provide a sound basis for the basic specification.
I think three metrics are needed:
- latency
- bandwidth (which subsumes energy limits, as above)
- reliability
