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

  • From: Victoria Mercieca <vmercieca0@xxxxxxxxx>
  • To: aodvv2-discuss@xxxxxxxxxxxxx
  • Date: Fri, 2 Oct 2015 22:13:28 +0100

Thanks, I'll take another look at it. Should we identify the requirements
for adding new metrics types, i.e. that other metrics require their own
MAX_METRIC, cost(L) cost(R) and LoopFree?

Vicky.
On 2 Oct 2015 21:34, "Ratliff, Stanley" <sratliff@xxxxxxxxxxx> wrote:

…“you can do whatever you thing..” I meant THINK. And on this box, I
can’t even blame autocorrect… J



Regards,
Stan





*From:* Ratliff, Stanley
*Sent:* Friday, October 02, 2015 4:33 PM
*To:* aodvv2-discuss@xxxxxxxxxxxxx
*Subject:* RE: [aodvv2-discuss] Re: Metrics (removing references to
alternate metric types)



Vicky,



Thanks for responding.



At this point, we have a documented 4-1 split concerning
DEFAULT_METRIC_TYPE. I believe that constitutes rough consensus, with
Charlie being in the rough. Let’s change the document and move on.



As to the documenting of other metric types – myself, I would prefer to
keep that text fairly generic. Along the lines of “Implementers MAY
consider other metric types, but the algorithms for incorporating such
types are undefined, and interoperability issues need to be considered.”
In other words, some fluff & cruft that says “you can do whatever you thing
you’re big enough to do, understanding you may break the thing.”



Does that make sense?


Regards,
Stan





*From:* aodvv2-discuss-bounce@xxxxxxxxxxxxx [
mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx
<aodvv2-discuss-bounce@xxxxxxxxxxxxx>] *On Behalf Of *Victoria Mercieca
*Sent:* Friday, October 02, 2015 4:26 PM
*To:* aodvv2-discuss@xxxxxxxxxxxxx
*Subject:* [aodvv2-discuss] Re: Metrics (removing references to alternate
metric types)



Hi all,

I'm going for option 1. The idea that "at least we have a route even if
the metric doesn't really mean what we think it does" doesn't feel right.
We can't correctly choose a better route in this case, plus we might run
into conflicts between MAX_METRICs. Interoperability is a common theme in
comments we have received on the draft, even if not about this specific bit.

To address one of Charlie's comments:
"Until someone publishes another metric, removing it is a penalty on every
implementation."
If we were to set hop count as metric type zero, we wouldn't be adding to
the message size since a value of zero means the extension type field is
not necessary to include in the RFC 5444 representation. I know hop count
is type 3 at the moment, and I dont know how people feel about changing
that...But thought I'd mention it. Or similar to currently, interpreting 0
as 3 instead of interpreting 0 as whatever is configured as default
(ensuring 0 is not assigned to any future metric type)

Would also like to draw attention back to the issue that this thread was
started for...how much info do we want to include about other metric types?
The changes I made to the metric section diverted into this discussion
about the default setting.

Regards,
Vicky.

On 1 Oct 2015 17:17, "Ratliff, Stanley" <sratliff@xxxxxxxxxxx> wrote:

Charlie/All,


-----Original Message-----
From: aodvv2-discuss-bounce@xxxxxxxxxxxxx [mailto:aodvv2-discuss-
bounce@xxxxxxxxxxxxx] On Behalf Of Charlie Perkins
Sent: Thursday, October 01, 2015 11:55 AM
To: aodvv2-discuss@xxxxxxxxxxxxx
Subject: [aodvv2-discuss] Re: Metrics (removing references to alternate
metric types)

Hello folks,

So, on the one hand, we have observations that global parameter settings
might be incompatible. That's almost a tautology -- who could disagree?

But I don't see any discussion about my several specific points on this
matter.

In particular, the points about how it's at most an inaccuracy, and no
worse
than the existing mishmash metric.

I believe I have addressed your points, with the deployment scenario.
I've also addressed your point of being as efficient as possible on the RF
for energy savings. I note that it is *you* that hasn't addressed *my*
point - specifically, my point that the described scenario is one that
produces unpredictable results, and will be difficult to troubleshoot. I
have no choice but to go with the assumption that you agree with my
analysis, since you have not produced a counter-argument.


And also I *really* fail to understand why we have to get into
disagreements
about points that no one has raised on the mailing list, when they are
delaying publication of the next draft.

We get into disagreements because we are engineers who see potential
problems. It is a complete red herring to infer that only items brought up
on the mailing list should be discussed here. This group of people
represent the individuals most interested in advancing AODVv2; the people
who have the most detailed knowledge of the protocol. I refuse to operate
under the notion that we will only discuss items flowing in from the
mailing list - and/or, I'm more than happy to raise my concern directly
with the MANET list. I'm absolutely positive that people will agree with
me, and I think that putting it on the MANET list will only delay
publication longer.

In the interest of forward progress, I now ask for a call for consensus
amongst the members of the editing team - the paths before us on the issue
of DEFAULT_METRIC_TYPE seem to be:
1. Remove DEFAULT_METRIC_TYPE, and require the explicit announcement of
metrics. This increases the size of AODVv2 messages.
2. Keep the existing schema of utilizing DEFAULT_METRIC_TYPE,
understanding that it may cause unpredictable results when differently
configured routers attempt to interoperate.

I believe the best path forward is option 1. I look forward to other
opinions being expressed, so that we may gauge the level of consensus,
change the draft (or not), limit the delay, and move on.

Regards,
Stan





Regards,
Charlie P.


On 10/1/2015 5:54 AM, Ratliff, Stanley wrote:
Lotte,

-----Original Message-----
From: aodvv2-discuss-bounce@xxxxxxxxxxxxx [mailto:aodvv2-discuss-
bounce@xxxxxxxxxxxxx] On Behalf Of Lotte Steenbrink
Sent: Thursday, October 01, 2015 6:15 AM
To: aodvv2-discuss@xxxxxxxxxxxxx
Subject: [aodvv2-discuss] Re: Metrics (removing references to
alternate metric types)

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)
Yes, that's what I'm advocating. DEFAULT_METRIC_TYPE goes away, and
the metric (or metrics) used are explicitly announced every time.

Regards,
Stan



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



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


_____________________________________________________
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: