Hi Vicky,
Am 04.02.2016 um 11:35 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:
Cheers Lotte,
I've removed any reference to those fields and also MAX_HOPCOUNT.
...except for the optional feature of expanding ring multicast which would
use hop limit to limit how far route requests would go. But without saying
how to deal with hop limits, this feature isn't possible any more... which
leads back to the thought I had before, that we would then need to define our
own hop-count type TLV to enable this feature. So should I also remove that
optional feature?
Kind regards,
Vicky.
On Wed, Feb 3, 2016 at 3:14 PM, Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx> wrote:
Hi Vicky,
Am 03.02.2016 um 15:21 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:
Thanks Lotte, I made that change to a MUST NOT.
To do the update, should we use hop limit and set it to 1, or omit it
completely? Based on a quick scan of RFC5444, I'm not sure how it is
interpreted if omitted. Ignored completely I guess.
If I understand it correctly, yes. Both fields are optional, so if the
mhashoplimit and mhashopcount flags aren't set, they're just not there (or
else there's a bug in the builder code ^^).
Should we include checks that if hop limit is included it must be 1, else
discard the message?
Should we include checks that if hop count is included it must be 0, else
discard the message?
I'd say just don't include them and that's the end of it... This way the
other side won't have to add code handling this extra case (which is
semantically equivalent to them not being there) and we don't have to
describe it. If an implementation insists on setting them explicitly they're
not standard-compliant. Does that make sense?
Or is your intention to keep a "loophole" open for future drafts? Then again,
I think they might not be backwards compatible either way, so....
Regards,
Lotte
Vicky.
On Tue, Jan 26, 2016 at 1:06 PM, Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx> wrote:
Hi Vicky, Hi all,
Am 26.01.2016 um 10:12 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:
Hi all,
This is one of three things I think we said needed further discussion in
our last teleconf. Pasted below are the main comments so far - apologies if
I missed anything. Has anyone else had a chance to mull it over, I'd like
it if we were all in agreement!
I still think your idea makes sense... I haven't been able to find a
scenario where a message would circulate endlessly, at least. If we really
want to make sure there's no loophole, we could ask the people from Tehran
if they could check it, since they've asked us if we had any suggestions?
The only tidbit I could find was that
6.8. Suppressing Redundant Messages Using the Multicast Route Message
Table
says
If the message is redundant, update the Timestamp and RemoveTime on
the entry, since matching route messages are still traversing the
network and this entry should be maintained. This message SHOULD NOT
be regenerated or responded to.
And I was wondering if we should make that a MUST NOT if we're relying on
this mechanism to kill rogue packets, at least on the regeneration part?
Kind regards,
Lotte
Kind regards,
Vicky
3. Use of msg-hop-limit and msg-hop-count:
Thomas:
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.
AODVv2: Discussion is still needed here. We wonder if these fields are
necessary at all for AODVv2. We were using them to limit the number of
regenerations of a RREQ. However, the hop limit value needs to be large
enough to allow a RREQ from one side of the network to another. It might be
the case that using the hop limit, almost every router in the network would
receive that RREQ anyway, and by using the redundancy check, we already
stop RREQs from circulating endlessly.
Charlie:
Yes, the RREQ would stop circulating after a while. One could draw cases
in which the RREQ would traverse every node in the network {i.e., O(n)
forwarding actions} as opposed to O(sqrt(n)) if msg-hop-limit were used.
But these cases are relatively rare and it would not be a calamity to just
let them happen occasionally [n == # of AODVv2 routers].
Basically, I am O.K. either way, except I hope we don't have to mandate a
new special-purpose TLV for it.
