Hi all,
Am 01.10.2015 um 22:10 schrieb Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>:
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.
