Hi all,
Just some thoughts on this before I go back to Thomas.....
If we were to send a RREQ with hop limit set to 1, the receiving router
would have to assume it should regenerate. If it does regenerate, and the
next router also regenerates, and the next, etc, etc, there's no limit to
prevent the RREQ "from endlessly circulating in a MANET", besides the fact
that once everyone has heard it once, they will avoid regenerating it a
second time. So everyone in the network will hear the RREQ at least once,
process it, and regenerate it once. Any further versions will be seen as
redundant.
My thinking was that by using msg-hop-limit and msg-hop-count, we limit
this. Currently by choosing to stop regenerating an RREQ after MAX_HOPCOUNT
hops, I thought we were likely to avoid having EVERY router in the network
having to handle the RREQ and regenerate it. I think I may have been
wrong....Bear with me while I explain my thinking...I had imagined a
scenario where a router in the centre of the network sent a RREQ, and
routers either side received it and regenerated. Obviously only one of them
is regenerating in the right direction.
e.g. A ---- B ---- C ---- D ---- E ---- F ---- G ----- H ------ I ------ J
As an example, F sends a RREQ for I. E and G regenerate. D and H
regenerate, etc. The RREQ being regenerated towards A is pointless. But, in
this network, MAX_HOPCOUNT would have to be 9 to enable A and J to discover
each other. So even if we set MAX_HOPCOUNT to 9, this doesnt help the
initial scenario - the RREQ will always get regenerated in the wrong
direction as well as the right one.
So if MAX_HOPCOUNT has to be big enough to allow a request from one side of
the network to the other side, then is it likely that every router in the
network will end up receiving the RREQ and having to process it and
regenerate it, despite us setting a <msg-hop-limit> in the message? i.e. is
there any point in setting <msg-hop-limit> to MAX_HOPCOUNT and incrementing
<msg-hop-count>?
Kind regards,
Vicky.
---------- Forwarded message ----------
From: <ietf@xxxxxxxxxxxxxxxxx>
Date: Thu, Dec 3, 2015 at 11:37 AM
Subject: Re: [manet] draft-ietf-manet-aodvv2-12 and draft-ietf-manet-dlep-17
To: Victoria Mercieca <vmercieca0@xxxxxxxxx>
Cc: manet <manet@xxxxxxxx>
Victoria,
On Nov 19, 2015, at 17:09, Victoria Mercieca <vmercieca0@xxxxxxxxx> wrote:
Hi Thomas and Christopher,
Thank you for your comments. If I may address just one point for starters
- regeneration vs forwarding. We use the term regeneration since forwarding
seems inappropriate when the message content changes at each hop.
The changes we make to the message content are:
1) 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
2) AckReq only applies between hops, so needs to be removed at each hop,
and a new AckReq element may need to be added for the next hop.
3) ValidityTime could potentially be added by any intermediate router that
wishes to limit the time it will forward packets on the route.
4) Stripping out Unreachable Addresses from RERR which did not affect our
route set.
Can we really use the term "forwarding" if we are changing the metric
value, adding a validity time, adding/removing AckReq or removing addresses
and their associated TLVs?
Further, in reply to the comment about use of the msg-hop-count and
msg-hop-limit fields, I think it does not matter that a message only
travels one hop in that particular form, with that exact set of information
enclosed. Hop limit and hop count are part of the message and used by the
routing protocol, and so they refer to the multi-hop path that the AODVv2
message will follow, indicating when not to regenerate any further. So
AODVv2 uses these fields as suggested in RFC5444 Appendix B, to limit the
number of hops across which it will regenerate a packet so as to "prevent
messages from endlessly circulating in a MANET”.
Mmmh…based on what you describe in the above:
1) a router receiving a control message may chose to respond by doing any
(and possibly more than one) of:
a) ignore the message
b) process the message
c) generate a new control message, possibly integrating the state
acquired through b.
2) consequently, your protocol control messages are only ever exchanged
between neighboring routers
1c) is what you call “regenerate” a control message - akin to any other DV
protocol, which (possibly) shares its distance vector with its neighbors
after having processed a received message.
While I’m not sure that I particularly like the word “regenerate”, I’m not
too hung up on that — but, at the very least it does deserve a precise
definition somewhere in the specification since, at least, I stumbled over
its interpretation.
But, either way, as according to your model *messages* are never forwarded,
but always are intended for receipt by a router which is a direct neighbor,
then a <msg-hop-limit> >1 (which applies to the *message*) seems
inappropriate.
Actually, according to that model, I would even say that receipt of a
*message* with a <msg-hop-count> >1 should be interpreted as a malfunction.
As you refer to RFC5444 appendix B, do note that Appendix B of RFC5444
(and, note the errata 4003) talks about:
<msg-hop-limit> field, if present, contains the number of hops on
which the message is allowed to travel before being discarded by a
MANET router. The <msg-hop-limit> is set by the message
originator and is used to prevent messages from endlessly
circulating in a MANET.
Specifically “set by the *message* originator” and “number of hops on which
the *message* is allowed to travel” — with your control messages traveling
just one hop, I believe that setting <msg-hop-limit> = 1 is correct.
Best,
Thomas
Kind regards,
Victoria.
On Wed, Nov 18, 2015 at 8:49 AM, Christopher Dearlove <
christopher.dearlove@xxxxxxxxx> wrote:
I've not had time to look at either yet, though I hope to review DLEP very
soon.
But this has made me think about the RFC 6621 reference in AODVv2. It's
always been clear this has been rather a throwaway comment that needed
thought, but until now I hadn't really given it any.
And it doesn't work. RFC 6621 is fundamentally unusable here. Let's
consider each on turn.
AODVv2 is in the RFC 5444 structure. As has been noted on many occasions,
AOVDVv2 gets to use messages, but packets are not in its competence.
RFC 6621 is about packets. But not even RFC 5444 packets but IP packets.
It's about whether or not to forward them. But RFC 5444 packets aren't just
not forwarded in unchanged IP packets, they aren't even forwarded at all.
They are each a single hop construct, and if a message is forwarded (which
is by the routing protocol, as far as RFC 5444 is concerned, it's a new
message) it will be in a new packet, with possibly new companions.
If AODVv2 wants to use a more efficient flooding process, it needs one at
the message level. Now an example of that exists - the mechanism on RFC
7181. Unfortunately we didn't break that out as a separate draft (we would
have liked to, but there were reasons we didn't).
And even if (by reference or other means) it were used - or some related
mechanism such as a CDS - that processing/forwarding mechanism assumes you
have defined MPRs (or similarly, that you have defined a CDS). And that
needs a local exchange of information, such as NHDP's HELLO messages (and
the rest of NHDP) augmented with RFC 7181's MPR TLV (though only the
flooding bit is needed).
In other words, taking some real work to define. And also raising a
question for the WG - why do we want a reactive protocol? The main
attraction as I see it is the "if you're not doing anything, you're not
transmitting" property. Which adding this voids. Of course maybe the WG
doesn't value that. Or it is acceptable as an option. But if so it needs to
be an option that all routers use, or none. And if all, compatibly. (MPR
flooding allows different MPR selection algorithms - but only as long as
they satisfy the fundamental MPR algorithm properties.)
In short, RFC 6621 must go. The alternative is nothing, or significant
work.
--
Christopher Dearlove
christopher.dearlove@xxxxxxxxx (iPhone)
chris@xxxxxxxxxxxxxxxxxxxxx (home)
On 18 Nov 2015, at 01:35, Thomas Clausen <ietf@xxxxxxxxxxxxxxxxx> wrote:
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
_______________________________________________
manet mailing list
manet@xxxxxxxx
https://www.ietf.org/mailman/listinfo/manet
