Hello John,
Basically, for such metrics, "LoopFree()" is probably undefined.
Of course you can (tautologically) say they are for further study.
Wouldn't you be just as happy with a metric which is related
to bandwidth, but which is monotonically increasing?
On the other hand, for point-to-point links there is no problem, because
they aren't multihop and "LoopFree()" does not need to be defined.
Also, for point-to-point links the increasing multihop metric related to
bandwidth is also trivial (because it's not multihop!), and is simply the
link occupancy time. Actually, I am not even sure what "increasing"
means if constrained to be evaluated on single-hop routes.
I am pretty sure there are published results that contradict the claim
that it's too hard for multihop paths, but maybe they are talking about
some other metric besides link occupancy time.
Regards,
Charlie P.
On 4/20/2015 4:02 AM, John Dowdell 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 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).
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.
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,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"?
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.
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
