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