Hello folks,
A little follow-up below.
On 3/8/2016 1:36 PM, Lotte Steenbrink wrote:
Hi Charlie, hi all,
some comments and some proposals– if you (dis)agree with my proposals, please say so, even if it's just a +1/-1, then I know which changes to make (if no one responds, I'll just make them on my own. ;) )
Am 03.03.2016 um 22:12 schrieb Charlie Perkins <charles.perkins@xxxxxxxxxxxxx <mailto:charles.perkins@xxxxxxxxxxxxx>>:
The RREQ should only be requesting a route for a unicast address. Specifying subnet RREQ is not part of the current draft.
I don't think that TargPrefixLen should appear at all in RREQ.
Is that so? I'm sure there are use cases which require RREQs for entire subnets, but if we don't want to support that we'd have to make that more clear.
(consider adding a maximum single hop value JWD)
I don't think this is a good idea.
why so?
(It isn’t clear what the previous sentence means as the link was already part of the route discovery procedure if I know about it yes? JWD)
I thought that such links were blacklisted...?
Yeah, but by the time they are, they've already been part of the discovery process? I think that's why this sentence is misleading. I think we can just delete the "If link bidirectionality cannot be verified,.." sentence– it seems to confuse people, doesn't add anything new, the blacklisting is described in detail elsewhere.
(previous bullet points are a bit wordy consider using upstream and downstream and just list, route request, route reply to confirm downstream and route reqeust, route reply , route reply ack for upstream JWD)
I'm fine with upstream and downstream. Previously there were loud complaints about using those terms.
Yeah I think I remember that too? I like the terms though :(
(What does this mean? How would one determine a link to a neighbor to be broken….suggest removing it JWD)
Does this mean to simply remove the neighbor from the blacklist? I think that would be O.K. unless we have a reason to keep the information. But I don't remember any reason for that.
Huh? I think he's suggesting to remove the following sentence (which he's removed in his version):
Whena link to a neighbor is determinedto be broken, the Neighbor
Table entry SHOULD be removed.
I think we do need to remove these entries in order to stop them from clogging up the table, but we need to be more specific what "broken" means.
o RREQ messages SHOULD be given priority over RERR messages for
newly invalidated routes, since the invalidated routes may not
still be in use, and if there is an attempt to use the route, a
new RERR message will be generated.
(So is this 4th or second? It’s not clear and it should be. JWD)
Well, it appears next after "Second" and "Third", but one could say "Fourth" although it doesn't sound natural to me.
Huh? I think his point here is that the document is saying:
- RERRs are second priority
- but also, RREQs should be prioritized over RERRs for newly invalidated routes
... Which could mean that RREQs are transitively 2nd priority. I think we need to reword this one. How about
* Second priority SHOULD be given to RERR messages for undeliverable IP packets, so that broken routes that are still in use by other
AODVv2 routers can be reported to those routers, to avoid IP data packets being repeatedly forwarded to AODVv2 routers which cannot
forward them to their destination. An exception SHOULD be made if the RERR contains a newly invalidated route and there is a RREQ message available as well.
In this case, the RREQ should be prioritized, since the invalidated routes may not still be
in use, and if there is an attempt to use the route, a new RERR message will be generated.
[...]
* Fourth Priority SHOULD be given to RREQ messages.
? (Bit lengthy though :D)
(It’s not clear to me how this priority works. Do the messages just get dropped when tsome threshold for max number of messages is reached? Is there some queuing method because if their isn’t I don’t see how priority would work at all, as the choices are drop or send. This whole section seems out of place as we have’t talked about generating messages. I’d suggest moving or removing JWD)
This is a good point. In order to be clear, we need to say that there is a queue of messages and then use the priority mechanism to discard low-priority queued messages. Or, perhaps better, we can say that messages are not sent more frequently than one message per (1 / CONTROL_TRAFFIC_LIMIT)th of a second, and then the queue is reordered based on priority.
Any objections? If not I'll craft some text that says that.
If packets are not queued, no notification should be
sent to the source. (What notification is sent to the source when packets are queued? JWD)
ICMP Destination Unreachable ICMP message is mentioned later.
Is that really the correct message for "Hold on a minute, we're working on getting a route for you but it's not ready yet"? I think that sentence should just be deleted. I'm reading it as "the sender shouldn't be notified that we're not buffering". Imo, if someone wants to tell their clients that they're not buffering, they should be able to do so, but specifying the nitty gritty of that is out of scope.
(it’s not clear to me what the use case of removing the sequence number while the route is still active will achieve. suggest removal or some small explination JWD)
We have correctly specified the operation. Keeping sequence numbers past their expiration time seems dangerous to me, but we could explore that as well. Or we could initiate a unicast RREQ to get the new sequence number, but that's just more overhead.
Is there a reason we're keeping these entries at all? Intuitively, I'd say, if the sequence number has expired, the whole route set entry has expired, and should be deleted.
network or result in non-optimal paths.
(This seems like a bad idea to do on the reverse path. It would be a good way to attack a network Forward RREQ and drop all RREP. JWD)
Nevertheless we have to allow it because a node can change its processing context between the time the RREQ is received and the RREP is received. Of course malicious nodes will do this even if you tell them not to do it.
Would it suffice to make it more clear in the security sections that this can happen?
(it’s not clear to me what the point of this invalid route is. It doesn’t get used and doesn’t remove any existing routes. JWD)
The point of an invalid route is to keep the Sequence Number. One point of keeping Sequence Numbers is to avoid processing stale messages that might be received after long queuing delays.
I've taken the liberty to steal this for the MANET reply :)
(is MAX_SEQNUM_LIFETIME the only parameter which MUST be configured the same across the network? JWD)
Not sure about this...
me neither... Different ACTIVE_INTERVALs would probably cause a lot of chaos, but that should heal itself..?
