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

  • From: "Lotte Steenbrink" <lsteen@xxxxxxxxxxxxxxxxxx>
  • To: aodvv2-discuss@xxxxxxxxxxxxx
  • Date: Thu, 1 Oct 2015 12:15:29 +0200

Hi all,

Completely and totally +1 here. You can see this coming from the write up
on the FEMA website about post-Katrina actions for Fire and Rescue
services nationwide. Sure, there is a Federal wish-list of how it all
should work seamlessly across all states and counties, but then you
discover you have to go round and sell to every single one of those
counties who are free to choose what they want inside those requirements.
So that’s 3000+ sales pitches to make for the same system, or potentially
3,000+ different ways of configuring what should be a common system.

Please, for the sake of a few bytes, no implied default metric!


If I understand it correctly, The problems described by you and Stan would
also occur if both parties explicitly set the Metric Type TLV to
DEFAULT_METRIC_TYPE (with their DEFAULT_METRIC_TYPE being configured
differently), so we'd have the same confusion at the extra cost of some
bytes. If I'm not mistaken, we may want to remove DEFAULT_METRIC_TYPE
altogether then... (which, for the record, is fine by me)

Cheers,
Lotte

John

On 30 Sep 2015, at 14:23, Ratliff, Stanley <sratliff@xxxxxxxxxxx> 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.

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.

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. 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.

Regards,
Stan


-----Original Message-----
From: aodvv2-discuss-bounce@xxxxxxxxxxxxx [mailto:aodvv2-discuss-
bounce@xxxxxxxxxxxxx] On Behalf Of Lotte Steenbrink
Sent: Wednesday, September 30, 2015 3:05 AM
To: aodvv2-discuss@xxxxxxxxxxxxx
Subject: [aodvv2-discuss] Re: Metrics (removing references to alternate
metric types)

Hello folks,

Here are some reasons to not remove DEFAULT_METRIC_TYPE.

- Until someone publishes another metric, removing it is a penalty on
every implementation.
- It would simply be a mistake to mangle the settings on different
network devices. We don't have to protect against all such mistakes.
- The difficulty about mismatched metric types is unfortunate, but not
fatal. As proof, one can refer to the mishmash metric supported by
OLSR.

Are you referring to the way OLSR represents Metrics, i.e. no matter
the
metric type, it has to be mapped to a certain range of values, with the
one
end of the spectrum meaning 'good' and the other end meaning 'bad'?
I'd be quite happy to adopt that, but I was under the impression that
you
weren't...

- Mismanaging the default metric type is a lot different than, and
much less likely than, say, mismanaging policy knobs.
- In the unlikely event that it becomes a problem, future metric
specifications could mandate that use of their metric REQUIRES the
metric-type TLV and cannot make use of the default mechanism.

Wouldn't that defy the propose of having a default mechanism in the
first
place?

- Removing the feature costs time and space over the air, increasing
interference etc.

Disregarding all of this simply to protect against a potential
mismanagement pitfall does not make sense to me.

It's especially mysterious, given that no one has complained about it
on the mailing list.

I have been told off many many times by Henning for omitting the Metric
Type TLV for DEFAULT_METRIC_TYPE. I can't imagine those complaints
haven't been raised on the MANET ML at some point, but even if they
weren't I did raise them on here (and in conference calls) on behalf of
Henning.

Regards,
Lotte


Regards,
Charlie P.


On 9/27/2015 2:03 AM, Victoria Mercieca wrote:
Hi all...

So I should remove the idea of the DEFAULT_METRIC_TYPE and AODVv2
should always include an indication of metric type?

Also, I'm now not sure how best to update this section. The text
before I tried to change it, and the text after (which I sent in the
email the other day), are attached. If anyone has any more pointers
on what to do with it, please help.

Regards,
Vicky.


On Fri, Sep 25, 2015 at 6:14 AM, Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx
<mailto:lotte.steenbrink@xxxxxxxxxxxx>>
wrote:

Am 25.09.2015 um 01:36 schrieb Ratliff, Stanley
<sratliff@xxxxxxxxxxx <mailto:sratliff@xxxxxxxxxxx>>:

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.


While I agree that "for any configuration variable, it is
possible to screw it up", I respectfully disagree with the
follow-on statement "...people use configuration variables, and
this is a good example of the value of doing so." Actually, IMHO,
it's a great example of why you would *not* use configuration
variables. As John states, routers in an AODVv2 network *might*
use different defaults, and therefore, problems will ensue. But
those problems would *only* ensue precisely because a default was
configured, and therefore, not announced. The fix is to *always*
explicitly include an indication of metric type. That way, there's
no possibility of being misinterpreted. I believe that is a much
better approach.

For the record, because I'm enthusiastically agreeing here: +1.


Regards,
Stan



_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the
individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to
the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding,
printing, or
copying of this email is strictly prohibited. If you received
this email
in error, please delete it and immediately notify the sender.
_____________________________________________________










_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________




Other related posts: