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

  • From: Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>
  • To: aodvv2-discuss@xxxxxxxxxxxxx
  • Date: Thu, 1 Oct 2015 13:10:06 -0700

Hello folks,

I think it is premature to call a vote. Stan did not see where I addressed his issue, and so I need to be explicit about that. I think that if he did not see it, then perhaps others did not see it. It is important for understanding the resolution.

I *think* this is the issue that Stan meant:

On 9/30/2015 6:23 AM, Ratliff, Stanley wrote:

All,

I think Lotte is spot-on here. One of the deployment cases I keep talking about
for these networks is the fire brigades that unfortunately have to form every
stinking year in California. They're made up of several entities - local,
county, state-wide, and national units. Let's assume that I'm part of a county
fire department, and so is Lotte. My fire department has AODVv2 routers, and
the IT department have worked tirelessly to set them up, complete with a
DEFAULT_METRIC_TYPE. Lotte's fire department also has AODVv2 routers, and her
IT department have done the same basic work - but for reasons that make perfect
sense, they've picked a *different* metric for their DEFAULT_METRIC_TYPE.

Yes, this is possible. I think it is typically unlikely, because choice of metric is pretty fundamental to the set of supportable applications and that would get peoples' attention.

If the total number of misconfigured (but, see below, not fatally) devices was 0.0002%, would that justify a penalty on every user?



So now, both fire departments race to the scene of one of these massive wildfires. We both switch
on the gear, and... pandemonium breaks out. The ad-hoc (well, pseudo ad-hoc) network we were
supposed to perform is acting in strange ways. Since it's "strange", and not
"broken", it's difficult to figure out what the problem really is. It's sure to take
hours, if not a day or two, to figure out the source of the problem - we're using different metrics
as DEFAULT_METRIC_TYPE, and the assumption of different defaults is at the heart of the strangeness.

As mentioned before, the result will be *inaccurate* metrics, not a major routing failure. From my mail of September 29:

- The difficulty about mismatched metric types is unfortunate, but not fatal. As proof, one can refer to the mishmash metric supported by OLSR.

Continuing:


I understand, and appreciate, the position that each and every byte transferred
via RF consumes battery power, and should be avoided if at all possible.

I appreciate this statement. Obviously, I have put a lot of effort into making it come true.


For reasons of interoperability, I believe that in this case, the additional
transmission load is required. Otherwise, I don't see the deployment scenario
I've outlined above working.


Well, it won't be perfect, but at least you'll get routes.


I will soon send another follow-up email, but this is enough for the moment.

Regards,
Charlie P.



Other related posts:

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