Hello Vicky,
For any metrics other than strictly increasing, my understanding of the
theoretical
correctness falls apart. If you know of any work to guarantee
loop-freedom, etc,
please let me know.
I think the other kinds should use a word besides metric. The
properties of metric
spaces are well known, and when you take away strictly increasing, you
end up
with something that might be as mysterious as dark matter.
BUT, having said that, if someone works out LoopFree() etc., then
absolutely I
agree with you, and it was my original motivation for defining those
abstract
functions.
I am sort-of O.K. with your suggestion to just leave it to the next
designers, without
any mention of how otherworldly it might become. A small part of me
feels a bit
irresponsible about, as you might say, failing to alert people to likely
disaster, but
now I can say that the other co-authors all wanted to have that language :-)
Regards,
Charlie P.
On 4/30/2015 9:42 AM, Victoria Mercieca wrote:
Hi John,
My feeling is that the draft, as it is, is open to the possibility of these metric types.
It defines for hopcount the Cost and LoopFree functions, also says broadly that we can support additive metrics using the same type of cost function, and support strictly increasing metrics using the same LoopFree function (I feel like this statement is correct but I havent worked through any examples to try to disprove it). Also, the route evaluation procedure now includes a statement that reinforces the fact that for the default hopcount metric, lowest cost value is best, but for other metric types, the best route might be the one with the highest cost value, and then uses the words "better" and "not better" instead of "higher" or "lower".
However, I do think the test for LoopFree might need to go before the metric comparison in the Evaluating Route Information section. It doesnt matter for our default hopcount metric, since our LoopFree function effectively says "if cost is greater, its not guaranteed LoopFree" and we also check if cost is greater in the cost comparison step. I think correct and generic behaviour would be to check LoopFree first, then compare route cost.
The draft clearly states that alternate metrics will need their own Cost and LoopFree functions which are out of scope for this document. However, if someone wanted to implement those kinds of metrics and could work out the correct Cost and LoopFree functions, I dont see why AODVv2 couldnt be used to support those. This matches your comment that "you can use such metrics but you'll have to work out the methodology yourself".
I think (hope) it's worded in a way that makes the use of other metric types possible, identifying which bits are for the implementor to work out.
Regards,
Vicky.
On Mon, Apr 20, 2015 at 12:02 PM, John Dowdell <john.dowdell486@xxxxxxxxx <mailto:john.dowdell486@xxxxxxxxx>> wrote:
Hi Charlie
On 20/04/15 06:06, Charlie Perkins wrote:
Hello John,By "not allow" do you mean "forbids" or "is not currently
AODVv2 does not allow metrics like "bandwidth" because they are
not monotonically
increasing, in fact I think that it is monotonically decreasing
in all real life cases.
configured for"? I was trying to allow some hooks for an extension
draft that could deal more deeply with metrics such as bandwidth
which do not obey the monotonically increasing algorithm, and not
to do all the thinking in this draft. From our work on DLEP, I
would be appalled if AODVv2 forbade the use of other metric
behaviours, particularly bandwidth (simply a minima function).
On the other hand, to save time and calls from the gallery during
WGLC, do we simply state (we might already) that metrics with
different behaviours are for further study? I'd be happier if we
added in some text to say "you can use such metrics but you'll
have to work out the methodology yourself".
It has to be inverted into something like "occupancy of theThat's a conversation we have avoided on DLEP for about 4 years,
medium", which sort of works.
because it's on the "too difficult to do" pile. We have asked
radio vendors about this, and the answer for anything other than a
point-to-point radio is that it's mathematically too difficult.
Regards
John
I wish the word "metric" was reserved for something that
satisfied the triangle inequality.
Regards,
Charlie P.
On 4/14/2015 5:32 AM, John Dowdell wrote:
Hi all, so we're back to 'cost' of a route once more .... see
below in line
On 13/04/15 23:04, Lotte Steenbrink wrote:
Hi again,OK so this is fine for metrics with progressively increasing
Am 13.04.2015 um 23:37 schrieb Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx
<mailto:lotte.steenbrink@xxxxxxxxxxxx>>:
Hi folks,
I'm revisiting my code that checks whether a route update
offers improvement right now, and imho the “To briefly
summarize, ..” Part of section 8.1. is a bit misleading, since
it doesn't cover all the cases clearly (and being lazy, I used
it as my only reference first). Therefore, I'd propose to
remove the following paragraphs:
To briefly summarize, AdvRte must satisfy the following conditions
compared to the existing route table entry before it can be used:
o AdvRte is more recent, (i.e., AdvRte.SeqNum > Route.SeqNum) OR
o AdvRte is not stale and can safely restore an invalid route (i.e.
LoopFree (AdvRte, Route) == TRUE), OR
o AdvRte is not stale and is less costly.
Regards,
Lotte
also,
* If the advertised route's cost is the same or greater than the
stored route, and the stored route is valid, the incoming
information does not offer any improvement and SHOULD NOT be
used to update the stored route table entry.
costs such as hop count and latency, and maybe even power
consumption, but the wording doesn't quite work for metrics that
are not like that (such as bandwidth). Perhaps use "better" or
"improved" rather than "lower", or "worse" or "impaired" (or
some other word which escapes me just now) instead of "higher"?
Regards
John
* If the advertised route's cost is lower than the stored route,
AdvRte offers improvement and SHOULD be used to update the
stored route table entry.
* If the advertised route's cost is the same or greater than the
stored route, but the stored route's state is Invalid,
continue processing to see whether there is a danger of a
routing loop.
could be rearranged so that the branches of the checks line up
as follows:
if (advertised cost < stored route){
USE;
}
else {
if (route is valid) {
DO NOT USE;
}
}
like so:
* If the advertised route's cost is lower than the stored route,
AdvRte offers improvement and SHOULD be used to update the
stored route table entry.
* If the advertised route's cost is the same or greater than the
stored route, and the stored route is valid, the incoming
information does not offer any improvement and SHOULD NOT be
used to update the stored route table entry.
* If the advertised route's cost is the same or greater than the
stored route, but the stored route's state is Invalid,
continue processing to see whether there is a danger of a
routing loop.
Having the positive check first would be similar to the order
of the checks regarding stale routes, and grouping the other
two checks together is easier to read, imo.
What do you think?
Regards,
Lotte
