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>
wrote:
Hi Charlie
On 20/04/15 06:06, Charlie Perkins wrote:
Hello John,
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.
By "not allow" do you mean "forbids" or "is not currently 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 the medium", which
sort of works.
That's a conversation we have avoided on DLEP for about 4 years, 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,
Am 13.04.2015 um 23:37 schrieb Lotte Steenbrink <
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.
OK so this is fine for metrics with progressively increasing 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
