[aodvv2-discuss] Re: Metrics (removing references to alternate metric types)

  • From: Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>
  • To: aodvv2-discuss@xxxxxxxxxxxxx
  • Date: Thu, 24 Sep 2015 13:48:56 -0700

Hello John,

Follow-up below...

On 9/24/2015 1:14 PM, John Dowdell wrote:


Metrics measure a cost or quality associated with a route or a
link, e.g., latency, delay, financial cost, energy, etc. AODVv2
enables the use of
multiple metric types. Each metric type that can be used in AODVv2
has a MetricType number. Numbers allocated are detailed in
[](#metric-type).
However, the mechanisms documented here may not be sufficient to
deal with asymmetric links.

A DEFAULT_METRIC_TYPE is configured on each AODVv2 router so that
any AODVv2 messages generated which are associated with that
metric type do not
need to explicitly include an indication of that metric type. This
means that when a metric type is not included in a message,
DEFAULT_METRIC_TYPE
is assumed. When sending information about routes with non-default
metric types, the MetricType data element MUST be included.

Ooh not sure about this. It's ok if all your routers use the same configuration, but if you want to include others organisations routers who could be using a different default, the unspoken metric type will be different, which will cause great problems. I believe that we should never assume a default type. However I'm open to some text that caveats the use of the implied default stating that Here Be Dragons.

For any configuration variable, it is possible to screw it up.

Nevertheless, people use configuration variables and this is a good example of the value of doing so.

I thought there was already warning language in the configuration variables section for all of the ones we've been using. If some such warning is missing, then it can be added.


AODVv2 defines a maximum value for each MetricType, denoted
MAX_METRIC[MetricType]. When the cost of a route is calculated,
and it exceeds
MAX_METRIC[MetricType], the route is ignored. AODVv2 cannot store
routes that cost more than MAX_METRIC[MetricType].


This only works for cumulative (additive?) metrics. For metrics which use other evaluation mechanisms, this doesn't work. Given we're only going to discuss hop count as a metric, then we can discuss the additive metric case and then state that other evaluation mechanisms need to be considered for some other metrics (eg a minima assessment for bandwidth).

I don't think it's correct to say that we are only discussing hop count as a metric.

It's more correct to say that we are only specifying LoopFree() and Cost() functions for hop count.

For metrics which are specified in such a way that the analogous computation could exceed MAX_METRIC, in my opinion the metric specification is simply wrong.

However, the text could be rewritten more abstractly in terms of "boundary" or "range" conditions and "assertions". So, for instance, it could say

"When the metric of a route is calculated, and the calculation does not fall within the range of values specified for the metric, the route is ignored."

....

Definitions of Cost and LoopFree functions for other metric types
are future development tasks.


I can't get my head around how you would calculate LoopFree for some metric types (eg bandwidth) or even if it is possible. I'd welcome some comment here.


For cost metrics, if cost(R1) < cost (R2), then R1 *cannot* contain R2 as a subroute, and so it's O.K. to use R1 instead of R2. For hop count, it turns out that we can *slightly* relax the strict inequality.

Bandwidth is not a cost metric. The calculation of LoopFree() might be more complicated. I don't like non-cost metrics for various reasons. One reason is that they contradict the entire mathematical formulation for metrics and metric spaces. On the other hand, some people in the IETF don't have much respect for mathematics, it seems, and I get tired of complaining about it.

Regards,
Charlie P.

Other related posts:

  1. Home
  2. aodvv2-discuss
  3. Archive
  4. 09-2015