Hello Vicky,
It is not true that MAX_METRIC solves the problem.
I have written a cost metric for received signal strength -- to be
published soon. It has fractional values in the range of the open
interval (0, MAX_METRIC). The name of the metric is "Received Signal
Weakness"; the larger the metric value, the weaker the signal strength.
If every signal was received at near maximal strength, the value on
every link would be the least possible fraction representable in that
interval.
This means that MAX_METRIC would allow hundreds of hops at maximum
signal strength, whereas any reasonable hop count would be far less.
Regards.
Charlie P.
PS. My goal is to eliminate the need for non-cost metrics... I won't be
able to eliminate the seeming desire for some people to have them, but
at least they will not *need* to have them.
On 11/18/2015 7:03 AM, Victoria Mercieca wrote:
Hi Stan, hope you're well!
Well... we are allowed to set these fields...so we can use them for our own purposes since they are part of the AODVv2 message...at least we thought we could set and use them as we like...but Thomas seems to think this inappropriate.
If we dont use them, we dont have the concept of "network diameter", and a maximum number of hops allowed in a route discovery. Unless we are using the hopcount metric type, in which case the test for MAX_METRIC accomplishes this anyway. In fact for any cost metric type, MAX_METRIC accomplishes this type of limit...
...so maybe we can do away with the msg_hop_count and msg_hop_limit fields, set them to 1 every time? Unless I'm forgetting something else.....
Regards,
Vicky
On Wed, Nov 18, 2015 at 2:36 PM, Ratliff, Stanley <sratliff@xxxxxxxxxxx <mailto:sratliff@xxxxxxxxxxx>> wrote:
Vicky,
As I read the comment, RFC5444 hop-limit/hop-count just flat don’t
work, because the message is (effectively) “generated anew” at
each hop. The document may call it “regenerated”, but fact is it’s
a “new packet” – not something that we’ve just noticed as it flew
by, but something that is effectively consumed, then a fresh (and
potentially modified) copy is issued again.
That being the case, I don’t understand how the hop count is
anything other than ‘1’. Each and every time.
Regards,
Stan
*From:*aodvv2-discuss-bounce@xxxxxxxxxxxxx
<mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx>
[mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx
<mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx>] *On Behalf Of
*Victoria Mercieca
*Sent:* Wednesday, November 18, 2015 4:53 AM
*To:* aodvv2-discuss@xxxxxxxxxxxxx
<mailto:aodvv2-discuss@xxxxxxxxxxxxx>
*Subject:* [aodvv2-discuss] regeneration vs forwarding
Hi all,
Regarding Thomas comments on this subject in the email to MANET
overnight (below).
I thought we took this decision to "regenerate" since for RREQ and
RREP, we may add TLVs (AckReq, ValidityTime) or remove TLVs
(AckReq), and because we change the metric in the message. In RERR
we remove addresses (and associated TLVs) that there is no point
re-reporting, i.e. Unreachable Addresses that didnt affect any of
our own routes.
Somewhere in the back of my mind there was some statement that
when using RFC5444 we shouldnt change anything other than header
fields of a message when forwarding it... but now I cant find
where that was written. Since we are changing the metric, and
potentially adding or removing TLVs, was the problem that it would
affect the value in an ICV field?
The changes we make to the message content are:
* We change the metric so that each router along the path learns
a route from the message, with the metric associated with the
path up to that point
* AckReq only applies between hops, so needs to be removed or
added accordingly.
* ValidityTime could potentially be added at any intermediate
router that wishes to limit the time it will forward packets
on the route.
* Stripping out Unreachable Addresses from RERR which did not
affect our route set.
Picking one particular comment from Thomas Clausen's email:
"Second, if a RREQ message is hop-by-hop only, then I do not think
that the use of the RFC5444 hop-limit/hop-count fields is
appropriate."
I think we only really use these to test if the message has
exceeded MAX_HOPCOUNT, i.e. the diameter of the network?
Regards,
Vicky.
---------- Forwarded message ----------
From: *Thomas Clausen* <ietf@xxxxxxxxxxxxxxxxx
<mailto:ietf@xxxxxxxxxxxxxxxxx>>
Date: Wed, Nov 18, 2015 at 1:35 AM
Subject: Re: [manet] draft-ietf-manet-aodvv2-12 and
draft-ietf-manet-dlep-17
To: "Ratliff, Stanley" <sratliff@xxxxxxxxxxx
<mailto:sratliff@xxxxxxxxxxx>>
Cc: "manet@xxxxxxxx <mailto:manet@xxxxxxxx>" <manet@xxxxxxxx
<mailto:manet@xxxxxxxx>>
Dear all,
I have started looking through the recently
updated draft-ietf-manet-aodvv2-12. A lot has changed, and I
regret not to have had a blow-by-bow comeback to the previous
review comments - would have made it a somewhat easier task to
check if all have been addressed or not.
But, I will work through it and produce a detailed review - but
from my first quick read-through there're a couple of issue that
jumped at me as worth bringing forward on a more global level already.
The first relates to how RREQs are forwarded -- or, more
generally, are not.
The protocol currently talks about "message is regenerated" rather
than "forwarded". I have understood that this means that a RREQ is
actually not an "end to end" entity, but is a "hop by hop" entity.
First, that is a curious design choice, is there any reason why
this is so considered?
Second, if a RREQ message is hop-by-hop only, then I do not think
that the use of the RFC5444 hop-limit/hop-count fields is appropriate.
Third, the statement in section 6.5 on the use of RFC6621 is
incorrect in two ways: RFC6621 does specify how messages are
*forwarded* (but, as discussed above, you are not forwarding
messages).
More seriously, this paragraph is incorrect:
"Implementations MAY choose to employ techniques to reduce the
number of multicast messages sent. Use of [RFC6621
<https://tools.ietf.org/html/rfc6621>] in deployments is
recommended. Employing [RFC6621
<https://tools.ietf.org/html/rfc6621>] in a subset of the
operational AODVv2 routers in a network, or configuring
different algorithms on different routers, will not cause
interoperability issues, but will reduce the effectiveness of
the multicast reduction scheme."
Different routers using different relay selection algorithms in
the same network will not *just* cause loss of efficiency, but
*will* cause interoperability issues.
For example if "router A" decides to suppress its message relaying
because it estimates that "router B" provides sufficient coverage
- and conversely "router B" suppresses relaying for the same
reason: neither A nor B would relay, and so any routers reachable
only via A and B would not be covered.
This is not a far-sought example: it can be as simple as A and B
simply using self-selecting relay algorithms with different
tie-breakers.
In short: I think that the whole message flooding/regeneration
part requires serious work.
The second issue is that I also suspect that there is some issue
with buffering, or rather with how it is specified; starting in
section 6.6, I am not sure that leaving that as "a matter of
policy at each router" is entirely right.
Also on buffering, I am wondering if the "start delivering
buffered packets" conditions (penultimate paragraph in 6.6, and of
course through the processing sections) is sufficient; I suspect
that the condition "When a valid route is installed" is not
sufficient - that there are situations where a routing table entry
is installed, but the complete route is not available or is not
bidirectional?This obviously is related to RREP_Ack being
hop-by-hop and not end-to-end....
Either way, the parts of the specification that relate to
buffering contain a mixture of normative and non-normative
verbiage (a lot of "can" but also a lot of MUST/SHOULD) which I
think could do with a tightening up.
But....is buffering even something that should be specified by
this document? It does not impact interoperability and it
interferes substantially with transport and congestion control,
and I am not sure that we understand the consequences (I am not
convinced that the claims in the document on benefits to TCP are
substantiated or even true).
As I indicated, a complete review will follow, but I thought that
these was a global enough topics to call out and get engineered right.
Thomas
PS: I remain convinced that the security considerations section is
insufficient ; I will try to articulate my thoughts on why that
is, but for starters looking at the recently raised (by somebody
else, the Chris replied) AODV security questions would probably be
helpful
On 10 Nov 2015, at 02:10, Ratliff, Stanley <sratliff@xxxxxxxxxxx
<mailto:sratliff@xxxxxxxxxxx>> wrote:
Hello WG participants –
The above referenced drafts were posted Oct. 13 (for AODVv2),
and Oct. 16 (DLEP). The co-authors and the chairs ask that you
please take some time to review and comment on the new
submissions.
Regards,
Stan
_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the
individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email
to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding,
printing, or
copying of this email is strictly prohibited. If you received
this email
in error, please delete it and immediately notify the sender.
_____________________________________________________
_______________________________________________
manet mailing list
manet@xxxxxxxx <mailto:manet@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@xxxxxxxx <mailto:manet@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/manet
_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the
individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this
in error, please delete it and immediately notify the sender.
_____________________________________________________
