[aodvv2-discuss] Re: buffering, complete routes and acks

  • From: Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>
  • To: aodvv2-discuss@xxxxxxxxxxxxx
  • Date: Wed, 18 Nov 2015 10:01:29 -0800


Hello folks,

On 11/18/2015 3:00 AM, Victoria Mercieca wrote:

Hi all,

Regarding the comments on buffering from Thomas Clausen's email...specifically:/
"
Also on buffering, I am wondering if the "start delivering buffered packets" conditions (penultimate paragraph in 6.6, and of course through the processing sections) is sufficient; I suspect that the condition "When a valid route is installed" is not sufficient - that there are situations where a routing table entry is installed, but the complete route is not available or is not bidirectional?This obviously is related to RREP_Ack being hop-by-hop and not end-to-end..../
/"

/
The route not being bidirectional (ie a complete route existing in both directions between OrigAddr and TargAddr) doesnt matter. Once we install a valid route (either to OrigAddr or to TargAddr) we will start using it, it doesnt matter if there is a route back... it can be requested if necessary.

A link in the route being bidirectional or not, does matter... Thomas is right about RREP_Ack. Because it is hop-by-hop, then even when a valid route is installed we cant guarantee that the complete route is available. But we would start sending anyway. The issue occurs if data packets are forwarded to intermediate routers before the intermediate router installed a valid route (in fact they might never install a valid route if a link is not bidirectional). If this happened, there would be packet drops and RERRs, and the route to OrigAddr would be removed at routers that were trying to use it. A new RREQ would then have to go out on behalf of the source of the traffic. So this problem would sort of fix itself....but not without lost packets, RERRs, and a new RREQ/RREP cycle. But this issue might be seen so infrequently in practise that the effort required to avoid this issue is not worth it.

It has never been reported in practice, to my knowledge.

If signaling is designed to prevent this problem, then the feature would have to be weighed against the loss of performance from additional interference, etc.

If we wanted to get into payload Information Elements, then a simple fix is available by piggybacking a "route completion" IE into the first payload packet. I would be dead set against requiring any new control signaling before enabling use of the route, but setting an indication into a payload which would be transmitted anyway would be O.K.

In fact, there are other great uses for such payload Information Elements which I would strongly support. For instance, in some circumstances the RREQ should be such a payload IE as well as the RREP.

These are optimizations which are light-years better than encumbering the existing AODV with more useless-in-practice signaling.

If anyone wants to answer this complaint, I would suggest just saying that it has never been observed to be an issue in practice, especially over existing popular layer 2 technologies.

Regards,
Charlie P.



Other related posts: