On Thu, Oct 1, 2015 at 6:41 PM, Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx> wrote:
Hello John,
The size of AODVv2 protocol messages is definitely under the control of
AODVv2. Whether an implementation chooses to put more protocols on the box
is outside of the control of AODVv2.
Please do take a look at my discussion points which place relatively
"non-dangerous" bounds around the damage from misconfigured metrics.
Moreover, by eliminating the default, you are simply moving the
configuration parameters into application space. So, no gain.
There is no doubt that we care enough to make a good protocol. I don't
think that rushing through matters and overlooking discussion points is a
very good realization of that, however, when there isn't an external
impetus pushing us through it. Having a vote before understanding the
discussion points doesn't sound right to me, but obviously I am not in
charge.
I am quite certain that the IESG has dealt with configuration parameters
many times in the past. Sorry if you think my observations are annoying.
Regards,
Charlie P.
On 10/1/2015 2:43 PM, John Dowdell wrote:
Hi all
The TL;DR version: option 1.
The slightly longer version:
I see we’re back to the clarity of messages versus saving bytes discussion
that I think we’ve had at least twice now over a number of months. My vote
is clear, please can we have clarity of messaging, principally because that
is the bit under the control of the draft. Sending bytes to the wire (or
ether) is not under the control of AODVv2, which is a discussion we’ve also
been round a few times now, mainly because RFC5444 is in the way, and there
could be (in theory at least) other protocols also co-habiting RFC5444
packets between nodes.
Assuming a default metric is, for the reasons that have been discussed,
dangerous, and, I believe, unlikely to pass muster with the IESG as a
performance/security/lack of specification nit. I work hard to make my own
manet products “switch on and go” so having to fiddle with
DEFAULT_METRIC_TYPE will not impress me, let alone my user community.
Also, discussing things which are not on the manet mailing list means we
actually care enough about the protocol to make it stand up in court (so to
speak), not because we’re just out to annoy each other.
Sorry Charlie. I’m really really really keen to get this to actual last
call this time, and I’m sure there are bigger worry beads than this one.
John
On 1 Oct 2015, at 21:00, Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx>
wrote:
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.
I don't, and I'm voting for option 1.
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:
You know much more about all kinds of metrics than I do, but I'm sure
there are some metrics whose values wildly contradict each other... If one
party thinks a big value is good and the other thinks a small value is
good, I would suspect that the complications arising from this would lean
more on the “major failure” than on the “quirky behaviour” side of
things... If I understand it correctly, compromise would be adopting OLSR's
unified metric representation, but as I said, I'm under the impression
that's not in your favour either.
- 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.
