[aodvv2-discuss] Re: RFC 6621 considerations

  • From: Victoria Mercieca <vmercieca0@xxxxxxxxx>
  • To: aodvv2-discuss@xxxxxxxxxxxxx
  • Date: Wed, 18 Nov 2015 23:32:24 +0000

Hi Charlie,

Thanks for the quick reply, comments in line. Apologies if it's scruffy,
replying on my phone.

On 18 Nov 2015 22:14, "Charlie Perkins" <charles.perkins@xxxxxxxxxxxxx>
wrote:


Hello Vicky,


On 11/18/2015 1:35 AM, Victoria Mercieca wrote:

Hi all,

I'm reviving this thread in light of the comments overnight from Thomas
Clausen and Christopher Dearlove.

Aside from Thomas' comments about interoperability:
"
Different routers using different relay selection algorithms in the same
network will not *just* cause loss of efficiency, but *will* cause
interoperability issues.

For example if "router A" decides to suppress its message relaying
because it estimates that "router B" provides sufficient coverage - and
conversely "router B" suppresses relaying for the same reason: neither A
nor B would relay, and so any routers reachable only via A and B would not
be covered.

This is not a far-sought example: it can be as simple as A and B simply
using self-selecting relay algorithms with different tie-breakers.
"



There are no such algorithms in RFC 6621, as far as I know. But someone
could in the future specify a dominating set algorithm including exactly
that horrible feature, regardless of whether or not the future algorithm
had any redeeming performance features.



If no 6621 algorithms do this, then we need to respond with that fact on
the MANET list?



I still didnt understand how this would actually work. From the previous
conversation:


On Sun, Oct 11, 2015 at 12:44 AM, Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx> wrote:

Hello Vicky,

Follow-up below.

On 10/10/2015 9:45 AM, Victoria Mercieca wrote:

Hi Charlie,

Still trying to understand how it works, so I cant say whether the
statement you mentioned we could make, or the extra draft, will be helpful.

So... is this how it works?

When originating an RREQ, a router sends it without involving a 6621
implementation.


Check.

A router receives a multicast RREQ message. A 6621 implementation
makes a note of whether it should be re-sent.


It should never be re-sent at this point because TTL=1.


So if TTL is 1, would the RFC6621 implementation note that the message
shouldnt be resent, and would AODVv2 be told the message wouldnt be resent?
In which case, AODVv2 wouldnt send a regenerated version either.

Also, what if the packet contains multiple MANET messages? And how can
we be sure TTL is 1 and RFC6621 wouldnt resend? In this case, surely we
need to get the 6621 implementation to find out if there's an AODVv2
message included, and not forward the packet? Or strip the AODVv2 part out
and maybe forward the non-AODVv2 parts? How would this even work?


If the messages are in the same packet, then they are going to the same
multicast address. On the basis of an MPR or dominating-set algorithm, all
such messages equally well need to be sent or not sent.


So a 6621 implementation would forward that packet? Even though it contains
an AODVv2 message, which actually shouldn't be forwarded? The AODVv2
message needs regenerating not forwarding...forwarding that packet with the
AODVv2 message inside it would be wrong. The other messages in the packet
might well want forwarding by 6621 though. I don't see how this would work.



AODVv2 processes the message.
There are then two options:
Router prepares a regenerated version of the RREQ, and checks with the
6621 implementation if it should send it, then sends it. The 6621
implementation doesn't resend any version of it.


Any version of it will already be unsendable because TTL=1.


How do we know TTL is 1? Is it always 1, on any RREQ that gets sent? See my
next comment.


As above, if the RFC6621 implementation would have not resent the
message anyway due to TTL being 1, then AODVv2 will check with the 6621
implementation and see that it shouldnt be resent, and AODVv2 would not
send a regenerated version either?


That would be the right idea.


If TTL is 1, and as you said above, 6621 would say the message wouldn't be
forwarded, then the signal to AODVv2 is that the message wouldn't be
forwarded, so I would think this means AODVv2 wouldn't regenerate the
message? I think AODVv2 should regenerate it, unless by looking at some set
it is known that it is unnecessary. That shouldn't be related to TTL
though, should it?





Or
Router creates RREP, and sends it without checking anything with 6621.
Again the 6621 implementation doesn't resend anything.


Check.

Wouldnt this require changes to 6621 implementations, so that they can
find out if they received a multicast packet containing an AODVv2 message
and decide not to resend it and signal to AODVv2 to handle it? How does it
handle the fact that the multicast packet can contain multiple messages
from different protocols all using 5444? Does the 6621 implementation need
to parse 5444 formatting and separate out the AODVv2 bit


What needs to happen is that AODVv2 does not multicast regenerated
RteMsgs if multicast retransmission is inhibited by RFC 6621.


How does it get notified that multicast retransmission would be
inhibited by 6621? Does this require changes to 6621 implementations?


Alternatively, we could add a step in the regeneration algorithm that
says "Do not regenerate if RFC 6621 is inhibiting retransmission". That
would be the content of the Internet Draft I would write, and probably will.


Again, how exactly will AODVv2 know that 6621 would inhibit retransmission?
In the same was as we have "requirements of the forwarding plane" section,
do we need to write that we have a requirement from 6621 implementations
too?



I have offered to write an Internet Draft for the above purpose. I can
have it done early next week. Would you support this draft? Please let me
know.

Properly speaking, it is not relevant to AODVv2, and I doubt there would
be any difficulty encountered by people implementing AODVv2. But it is a
point of order that has a tiny chance of being misinterpreted, and I am
tired of it being held up as an actual problem.


I'm sorry for my part in that but I still can't get my head around how this
actually works.

Regards,
Charlie P.



Regards,
Vicky.

Other related posts:

  1. Home
  2. aodvv2-discuss
  3. Archive
  4. 11-2015