Hello folks,
Regarding whether the document is ready for Last Call, I would be O.K.
with that. I still need to look at the comments submitted recently to
the list.
But I am not O.K. with completely eliminating all language about using
multicast suppression algorithms (e.g., by forming a connected
dominating set).
Yes, it is a pain in the neck that some people are using this as
something to complain about.
But we have a responsibility for producing a protocol specification that
provides information about how to solve known problems.
The problems are *SERIOUS*. The solutions are *KNOWN*, and were
developed in large part to solve the problems *FOR AODV*. Regardless of
the sniping, I am still having a hard time believing that I am the only
one who wants this information published and effective.
I have written a short document. I respectfully request that you take a
look and support adoption of it. It's not ideal to have it separate
from the document where it belongs. I don't know how to make that
argument any more strongly than I have already made it.
Regards,
Charlie P.
On 11/25/2015 9:57 PM, Charlie Perkins wrote:
Hello folks,
In the case of RFC 6621, it is a known fact that reliance on brute force flooding causes severe performance degradation at high interference. It's obvious on the face of it, and has been studied many times.
In the case of MTU, all I asked was to get some indication from RFC 5444 whether or not they agreed it was RFC 5444 responsibility. If not, then it is a big mistake to delete the MTU limitation. I would request at least that section 6.5 contain a notification that implementers should check that their RFC 5444 implementation avoids fragmentation due to MTU problems. Certainly I understand the argument that it doesn't *have* to be AODVv2's responsibility. I am really surprised that the actual need is not being acknowledged.
I will write the document about how to use RFC 6621. If it is insisted to remove the reference to RFC 6621, then I hope you would support the adoption of this supplementary document. History has *shown* that it is needed to say something about this issue. People told me for over 10 years that AODV had severe problems because it *specified* a HELLO beacon, although not mandated for use when neighborhoods were determined by other means. In other words, we ran the experiment (of not specifying a dominating-set algorithm), and got pretty conclusive results. The *reason* I strongly pushed for (and contributed a lot of information to) RFC 6621 was exactly so that AODVv2 could use it. I guess no one else on the author team was around for that.
Regards,
Charlie P.
On 11/19/2015 9:51 AM, John Dowdell wrote:
On 19 Nov 2015, at 01:55, Stan Ratliff <ratliffstan@xxxxxxxxx> wrote:
On Wed, Nov 18, 2015 at 5:14 PM, Charlie Perkins<charles.perkins@xxxxxxxxxxxxx <mailto: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.
I'm going to respectfully disagree. Looking at RFC 6621, the appendices specify 2 possible algorithms. On just a quick scan, it looks like S-MPR or MPR-CDS *might* cause the issue above. I think we should change the text to some vague reference about 'implementers MAY choose to employ schemes that reduce the overhead of multicast flooding", and leave it at that. We have *both* Clausen and Dearlove complaining about this; it will need to be thoroughly refuted, or it's not going to pass.
regards,
Stan
Stan, I’m inclined to agree with you. Having kicked this around the office this morning, there is a whole heap of worms we could get into, but it’s a heap that is not ours to farm.
Regards
John
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.
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.
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.
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.
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.
Regards,
Charlie P.
