[aodvv2-discuss] Re: Unicast v Multicast (was System Integration)
- From: Stan Ratliff <ratliffstan@xxxxxxxxx>
- To: "aodvv2-discuss@xxxxxxxxxxxxx" <aodvv2-discuss@xxxxxxxxxxxxx>
- Date: Wed, 1 Jul 2015 18:30:11 -0400
John,
You kinda-sorta solicited comments. My guess is that I'm going to deeply
regret a further descent into madness, but here goes...
On Wed, Jul 1, 2015 at 4:47 PM, John Dowdell <john.dowdell486@xxxxxxxxx>
wrote:
Here are some solutions do not add any significant overhead:
- Instead of sending RERR for undeliverable RREP, enable temporary use of
the unconfirmed route (semantically, temporarily confirming it)
= after sending, mark the route as unconfirmed again until the RREP_Ack
arrives
I don't believe this is workable, especially in the case where AODVv2 is
running in Linux user space, and sending to an RFC 5444 parser that is
running as an independent process. The issue is that AODVv2 doesn't (and
really can't) know when the the traffic is sent - only when it was sent to
the parser.
- Mark the RREQ-derived entry to OrigAddr as unconfirmed, and allow its
use for RREP but DO NOT allow it for data (status quo)
== this is very sensible from a logical standpoint because we are using
RREP to confirm bidirectionality
== It requires access to the IP route table to insert the unconfirmed
flag
== For implementations that have such access, this is definitely a
preferred solution.
==== We could make it available via a flag (e.g.,
IP_UNCONFIRMED_ROUTES)
As in the case above, I don't see this as workable. Inserting a route with
a new flag assumes that subsequent processes like the 5444 parser know
about the flag, and also assumes that Linux kernel code has been modified
(I think) - for example, this unconfirmed route should never be propagated
to a FIB entry; and forwarding code would need to know the difference
between a true data packet, and control plane packet. That difference is
wiped out when control plane (Layer 3) protocols are running on top of
Layer 4... to the forwarding code, it's all UDP (or TCP).
Setting this type of flag would also require additional signalling between
AODVv2 and any independent 5444 parser, in that the parer would need to
know whether it's OK to send traffic on an unconfirmed route or not.
- Mark the route to OrigAddr as confirmed, but with a huge metric and a
very short timeout. This is not my preferred method, but it would work
because:
== The danger is unmeasurably small that some application somewhere will
suddenly start using the route in preference to its previously discovered
route.
==== Increasing the metric to a huge value will decrease that
small danger by yet another very large factor
== we could also prevent the huge metric route from being supplied for
any future RREQ. Doing this would reduce the danger to be zero.
This is actually a workable, implementable notion. It's also self-contained
with AODVv2, so it doesn't require additional signalling. From a WG
perspective, I'd wager this stands the best chance of the 3 of surviving WG
scrutiny; but may still be perceived as inferior to the MCAST approach.
Another note - as I understand it, we're talking about the time between
RREQ and RREP/RREP-ACK. (To confirm the route and determine
bi-directionality). That being the case, we're talking about a host route,
right? I mean, we're discussing a /32 or a /128 route, back to the
originator of RREQ, in order to send things *to* said originator. We're not
in any way, shape or form attempting to send things *through* the RREQ
originator. So John, I'm not seeing the possibility of a huge black hole -
it would be vastly different if this injects a subnet route (e.g., a /8 or
a /16).
Regards,
Stan
Other related posts:
