On Wed, Dec 2, 2015 at 10:23 AM, Victoria Mercieca <vmercieca0@xxxxxxxxx>
wrote:
Hi Charlie,
So in a way.... we're listening to see if OrigAddr does start sending, and
traffic does get forwarded via us, and since we sent a recent RREP to
OrigAddr with the route requested for this traffic, we can deduce that
RREQ_Gen got the RREP and that the links are all indeed bidirectional, and
that our route to OrigAddr is valid...! We're requiring interaction with
the forwarding plane anyway to know that packets are being forwarded, so we
could easily determine if the data packets being forwarded are related to a
recently sent RREP, and use that to confirm the validity of the route to
OrigAddr. Feels a bit naughty somehow....Hop by hop Acks are still useful
since after the link is confirmed bidirectional, we can unicast any future
RREPs going across that link.
Could we introduce any issues doing it this way too?
Kind regards,
Vicky.
On Wed, Nov 18, 2015 at 6:01 PM, Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx> wrote:
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.
