Bug 1917

Created attachment 1841 [details]
Bug solution

PROBLEM:

Currently, when a node initiates a route discovery process, it schedules every RREQ retry with "requestId" parameter not incremented. This makes a packet being resent maximum "RreqRetries==16" times with the unwanted result of being dropped by neighbour nodes, which save every request in the "receivedRreqEntryList". For example, first RREQ is saved in mentioned list and next 15 RREQ retries are dropped, because all of them have the same request ID (they are treated as duplicate requests). Finally, initiator of RREQ has to restart route discovery process with new, this time incremented, request ID. Moreover, according to the DSR RFC : http://www.ietf.org/rfc/rfc4728.txt

"To initialize the Route Request option, the
node performs the following sequence of steps: (...)
The Identification field in the option MUST be set to a new value,
different from that used for other Route Requests recently
initiated by this node for this same target address. For example,
each node MAY maintain a single counter value for generating a new
Identification value for each Route Request it initiates."

SOLUTION:

Every RREQ packet, before being sent and scheduled for next retry, should have the DsrOptionRreqHeader ID field incremented. The code, that can be changed, is inside DsrRouting::RouteRequestTimerExpire method in the very last "else" block of code. The change I suggest in the attachment is the least invasive one but it decapsulates a packet just to change one field in the option header (request ID) and builds a new packet again. Perhaps it can be done in a better way.

RESULTS AFTER FIXING THE BUG:

Decrease in overall number of sent packets in the simulation by a factor dependent on the simulation configuration (in my case at least 5 times) while preserving the amount of data packets being dropped or delivered (model functioning remains correct). Unneeded packets do not flood the network. Simulation real-time decreases.