Hello folks,
I am O.K. with Stan's proposed resolution.
This is also related to discussion I sent out for a proposed resolution
employing Payload information elements. That would be a very good
solution, but would also have a very large impact on the specification.
Any such additional design should wait, I think.
Regards,
Charlie P.
On 12/2/2015 10:53 AM, Stan Ratliff wrote:
On Wed, Dec 2, 2015 at 10:23 AM, Victoria Mercieca <vmercieca0@xxxxxxxxx <mailto: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
<mailto: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.
There is something of a trap in that statement, which I've seen Thomas state on the list - How can we say this "...has never been reported in practice..." when AODVv2 is effectively a brand-spanking-new protocol? Is this something where AODVv2 substantially (or completely) mimics the behavior of AODV, and therefore, we can make the claim? Since that verbiage has already been used on-list, and the response was (more or less) 'How can you say that about a new protocol', then I think we're in trouble...
Having said that, I believe the way to continue is to note (I'm not sure this needs to be in the spec, but at least on-list) that yes, the exposure exists, and yes, it will clear itself, and yes, there would be a window of time where traffic would be lost. However, in the opinion of the authors, it represents an edge-case. Actually, a 'self-healing edge case', and as such, further optimization is deferred.
Just my $0.02 worth.
Regards,
Stan
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.
