[aodvv2-discuss] Re: Questions - Metrics

  • From: Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>
  • To: aodvv2-discuss@xxxxxxxxxxxxx
  • Date: Thu, 16 Apr 2015 14:32:17 -0700

Hello Vicky,

Follow-up below...

On 4/16/2015 7:00 AM, Victoria Mercieca wrote:



This email is about metrics (Section 7 in Version 9a or Section 5 in Version 9b):

* We refer to RFC6551. This defines more than just HopCount = 3.
e.g. node energy, link throughput, link latency, link reliability
and ETX reliability. Our IANA section doesn't list these under
MetricTypes, actually it says those numbers are unallocated.
Should we change this?


The problem is that some of the metrics in RFC 6551 are not monotonically increasing,
like the reliability metrics. In my opinion this is a problem that needs to be fixed, but
we can't do that right now.

* "monotonically increasing" means increasing or remaining constant
(i.e. anything but decreasing), so is it more correct to say
"strictly increasing"? For hopcount at least, Cost(L) is always 1
and route cost will always increase with number of links. We can
support any strictly increasing metric using Cost(R) = sum of
Cost(L), and our current LoopFree function, I think. Charlie
previously said link cost could be less than one for some metrics.
Since alternate metrics are out of scope anyway, I don't know if
that's relevant. They would need different Cost and LoopFree
functions. Is "strictly increasing" the same as "additive"? From
some Google searching, "additive" seems to refer to metrics
themselves, whereas "monotonically" or "strictly increasing" would
refer to the route cost function.


I think that strictly increasing is better actually.

The definitions of our abstract functions should not depend on whether the minimum positive metric is 1.
Latency is a good example of such an strictly increasing (and additive) metric. I reckon that as soon as we
get into Last Call, we (or I) should be looking at enlarging the number of metrics available.

Strictly increasing is not the same as additive.

* Should we have a configuration option for MetricTypes in use? Or
should we support all metric types we see in received messages? Or
is this what is meant by "check that the metric type is known"?


I am O.K. to describe this as a configuration option. However, it is new text about
something that no one was complaining about. But if the text is written, I am sure
no one would complain about that either :-)


* We havent decided on whether to make default metric type 0 for
simplification.


Well, RFC 6551 says that hopcount is type 3, so it would be bad to also have it be type 0.

Regards,
Charlie P.

Other related posts: