Hi Vicky
If the text is as you say, them I'm happy. We should focus on what we do know,
while leaving hooks for those coming after.
John
-----Original Message-----
From: "Charlie Perkins" <charles.perkins@xxxxxxxxxxxxx>
Sent: 30/04/2015 20:21
To: "aodvv2-discuss@xxxxxxxxxxxxx" <aodvv2-discuss@xxxxxxxxxxxxx>
Subject: [aodvv2-discuss] Re: 8.1. Evaluating Incoming Routing Information
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>
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
