Hi Vicky, hi all,
Am 07.04.2016 um 22:58 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:For the record: +1.
I think we are all in agreement. Unconfirmed potential routes need to be
LoopFree and have seqnum checked, and we changed the draft to reflect this.
Behnaz says we could still store multiple unconfirmed routes and if I
interpret her text correctly, they would all have to have the same hopcount
and seqno (ie pass the LoopFree test), so basically only have a different
next hop. Whereas in the draft currently we only store one unconfirmed route.
I'm tempted to say leave as is for now and potentially in future we could
revisit having multiple unconfirmed routes.
Kind regards,
Vicky.
On 7 Apr 2016 17:49, "Charlie Perkins" <charles.perkins@xxxxxxxxxxxxx
<mailto:charles.perkins@xxxxxxxxxxxxx>> wrote:
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.
Should I forward this to the other authors?
Regards,
Charlie P.
On 4/7/2016 1:34 PM, Lotte Steenbrink wrote:
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>https://en.wikipedia.org/wiki/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:
o If 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
o If 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.
