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

  • From: "Ratliff, Stanley" <sratliff@xxxxxxxxxxx>
  • To: "aodvv2-discuss@xxxxxxxxxxxxx" <aodvv2-discuss@xxxxxxxxxxxxx>
  • Date: Fri, 2 Oct 2015 20:32:33 +0000

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] 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<mailto:sratliff@xxxxxxxxxxx>> wrote:
Charlie/All,


-----Original Message-----
From:
aodvv2-discuss-bounce@xxxxxxxxxxxxx<mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx>
[mailto:aodvv2-discuss-<mailto:aodvv2-discuss->
bounce@xxxxxxxxxxxxx<mailto:bounce@xxxxxxxxxxxxx>] On Behalf Of Charlie
Perkins
Sent: Thursday, October 01, 2015 11:55 AM
To: aodvv2-discuss@xxxxxxxxxxxxx<mailto: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>
[mailto:aodvv2-discuss-<mailto:aodvv2-discuss->
bounce@xxxxxxxxxxxxx<mailto:bounce@xxxxxxxxxxxxx>] On Behalf Of Lotte
Steenbrink
Sent: Thursday, October 01, 2015 6:15 AM
To: aodvv2-discuss@xxxxxxxxxxxxx<mailto: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<mailto: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>
[mailto:aodvv2-discuss-<mailto:aodvv2-discuss->
bounce@xxxxxxxxxxxxx<mailto:bounce@xxxxxxxxxxxxx>] On Behalf Of Lotte
Steenbrink
Sent: Wednesday, September 30, 2015 3:05 AM
To: aodvv2-discuss@xxxxxxxxxxxxx<mailto: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>
<mailto:lotte.steenbrink@xxxxxxxxxxxx<mailto:lotte.steenbrink@xxxxxxxxxxxx>>>
wrote:

Am 25.09.2015 um 01:36 schrieb Ratliff, Stanley
<sratliff@xxxxxxxxxxx<mailto:sratliff@xxxxxxxxxxx>
<mailto: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:

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