Hello folks,
How does this interact with my analysis from March 28?
Hello folks,
Here is some discussion about the second purported loop. It does not use RREP, and so it is simpler to understand.
First, I reckon there is some confusion and the diagrams 1(a) and 1(b) are switched. So reverse the labeling and follow the steps.
In step 7, node n1 should never use the previous unconfirmed route because that previous route has an older sequence number. Moreover, the previous route has a larger metric, which would make it ineligible for use compared to the more recent route.
Finally, given all the serious recriminations against ever ever ever using unconfirmed routes to do routing, I remain at a loss to understand why unconfirmed routes could be considered part of a routing loop. It is an immediate absurdity to claim that a route that cannot be used, would be a route that has a routing loop. It would be like giving a speeding ticket to something that can't move (e.g., a mountain). Or like assigning a routing violation to something that can't route.
Note, however, that I continue to think that unconfirmed routes SHOULD be allowed to carry control information that is aimed at CONFIRMING the unconfirmed route.
Regards,
Charlie P.
FYI
Anfang der weitergeleiteten Nachricht:
*Von: *Behnaz yousefi <behyousefi@xxxxxxxxx <mailto:behyousefi@xxxxxxxxx>>
*Betreff: **Aw: loop scenario*
*Datum: *7. April 2016 um 15:23:45 MESZ
*An: *Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx <mailto:lotte.steenbrink@xxxxxxxxxxxx>>
*Antwort an: *Behnaz yousefi <behyousefi@xxxxxxxxx <mailto:behyousefi@xxxxxxxxx>>
Dear Lotte,
Thanks very much for your reply. We were in "Nowruz (https://en.wikipedia.org/wiki/Nowruz)" holidays for our new year, and the colleague were not available to discuss your reply.
> Oh, of course, I'm sorry I didn't get back to you sooner. We've
> discussed your scenario and thought it was feasible. Based on your
> findings, we've decided to stop storing multiple Unconfirmed routes.
I believe that you could still store multiple Unconfirmed routes but to prevent loop formation routing table must only keep the best and freshest routes, i.e. routes which have the best metric, i.e. hop count, and greatest destination sequence number. In other words, for each destination it should only keep those unconfirmed routes which have the same hop count and destination sequence number, and only their next hops is different from each other. Since unconfirmed routes only differ in next hops, they can be kept as one entry in the routing table where Route.NextHop is actually an array of next hops which have the same sequence number and hop count. In this way, all the unconfirmed routes are kept together and whenever a better route were found, it can update this entry after removing existing next hops from the next hop array. In case the new next hop had the same hop count and destination sequence number, it would be added to the next hop array. This procedure can be summarized as follows:
·If a matching route exists and the route state is unconfirmed:
oIf the new route offers improvement, all existing next hops must be removed from the next hop array of the existing route and then the existing route is updated with the information from the new route
oIf the new route have the same sequence number and hop count, the next hop of the new route should be added to the next hop array.
Note that we abstracted from time here, therefore we didn’t talked about timed elements of the route entry, e.g. Route.LastSeqNumUpdate. I believe to take those element into consideration you can store each one of them in an array to keep the corresponding value for each element of next hop array. For example, LastSeqNumUpdate is an array where LastSeqNumUpdate[i] referes to the time the sequence number for this route with next hop of NextHop[i] was last updated.
>> However, regarding your stated assumptions:
>>
>> ·n0 attempts to resend the "rreq" message when it doesn't receive an
>> "ack" from n1
>> ·The resending procedure of the "rreq" message by n0 takes long enough
>> that the "rreq" message passes through two nodes and be processed by
>> them.
> What exactly do you mean by „an „ack" from n1"? RREQs are not acked per
> se- are you referring to a RREP (which implicitly acks >the RREQ, i
> suppose)? Or do you mean that n0 didn't see n1 re-broadcasting the RREQ
> and therefore re-sends the RREQ to n1? The >latter shouldn't happen...
> n1 should only re-send if the RREP isn't received within
> RREQ_WAIT_TIME. If the RREP takes longer >than RREQ_WAIT_TIME to arrive
> at n0, and n0 reacts with a RREQ retransmission, the loop you've
> described will form.
Many thanks for your explanation, It really helped. We assumed that
broadcasting an RREQ is reliable, i.e., an ack is expected from each
neighbor. However, you explained it is sent via the unreliable broadcast.
Hide original message
> Out of curiosity- I don't know much about Model Checking, so I had a
> hard time >reading your paper, but I want to make sure I don't
> misunderstand what you're doing. >The way I understand it, you didn't
> implement AODVv2, but rather extracted a set of >rules from the
> specification, fed those to a specialized model checker, and checked
> >whether the rules allowed unwanted behavior. Is that correct?
Exactly. We abstract the timing issues, and specify how each received
message could be handled. I have attached our specification given in
wRebeca (it has a Java like syntax) and can be easily followed.
