Hello Vicky,
I am resending because my previous attempt caused an error due to the
4MB attachment size. This time I include the URL below.
Setting MAX_METRIC wouldn't even work for 16-bit metrics with realistic
mid-range values (for instance, in [roll] for RPL). It doesn't really
matter about the fractional part anyway, if values could range from 100
to 10,000, but having fractional parts makes it quite unrealistic.
I have made a proposal for Received Signal Weakness (RSW). A previous
draft was tentatively accepted for 802.15.10 and this new proposal
responds to comments received. I expect to formulate it as an Internet
Draft soon. Comments would be greatly appreciated.
The URL is:
https://mentor.ieee.org/802.15/dcn/15/15-15-0925-02-0010-received-signal-weakness-rsw-metric-specification.docx
I'll also do an RFC 6621 adaptation draft.
Regards,
Charlie P.
On 11/18/2015 11:54 PM, Victoria Mercieca wrote:
Hi Charlie,
That is a good point. Could we set MAX_METRIC for that metric to be a multiple of the "lowest possible fraction", where the multiple can be the desired hop-limit?
Vicky
On Wed, Nov 18, 2015 at 10:00 PM, Charlie Perkins <charles.perkins@xxxxxxxxxxxxx <mailto:charles.perkins@xxxxxxxxxxxxx>> wrote:
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> 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] *On Behalf Of
*Victoria Mercieca
*Sent:* Wednesday, November 18, 2015 4:53 AM
*To:* 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>
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>
Cc: "manet@xxxxxxxx" <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> 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
https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
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 email
in error, please delete it and immediately notify the sender.
_____________________________________________________
