Hello Stan,
I'll publish the "using RFC 6621 draft". Then either I or any one of
you can relay Vicky's comments to the mailing list; please let me know
if you would like for me to do it.
It would be nicer to use the mailing list for discussions if the general
mood were constructive instead of vitriolic.
Regards,
Charlie P.
On 3/3/2016 6:30 AM, Stan Ratliff wrote:
On Thu, Mar 3, 2016 at 8:47 AM, Charlie Perkins <charles.perkins@xxxxxxxxxxxxx <mailto:charles.perkins@xxxxxxxxxxxxx>> wrote:
Hello Vicky,
I am O.K. with what you said, but I want to reiterate that the
*reason* that RFC 6621 was published was *exactly* so that
protocols like AODVv2 could use it. I know this because I was one
of the main contributors -- specifically the parts about hashing
for duplicate detection and much of the part about CDSs. Somehow
RFC 5444 seems to have gotten in the way. I also did a thorough
analysis of the chances of failure due to hash collisions and the
recommendation makes the failure mode far less common than packet
drops due to interference.
Anyway, the suggestion that RFC 6621 is inapplicable relies on a
distortion of reality.
Regards,
Charlie P.
On 3/3/2016 1:21 AM, Victoria Mercieca wrote:
I believe that we caused a lot of confusion with our attempt to
explain this at the time, which is why it was removed from the
core draft. Yes, 6621 is inapplicable in that (I think due to the
rules John pointed out in another email I just read) the packets
would not be deemed to be forwardable by 6621. In any case we
dont want them to be forwarded by some type of 6621
implementation since we want AODVv2 to process and regenerate
them instead. 6621 also discusses duplicate suppression, which is
handled by AODVv2 itself already, plus I'm not sure if the way
6621 determines duplicity would achieve AODVv2's idea of
redundancy. Lets not argue about that anyway...because ...
I think what Charlie was getting at was that if AODVv2 knew
whether the router was elected as a forwarding router then it
could decide whether it should regenerate messages, as a general
rule rather than on a packet by packet basis. I think this
technique is still covered by statements like "The router MAY
choose not to regenerate the RREQ, for example if the router is
heavily loaded or low on energy and therefore unwilling to
advertise routing capability for more traffic." This covers
implementers who wish to be clever with any 6621-inspired
decisions, without getting into the details and confusing people.
Charlie's draft explains this, but it seems unnecessary to have a
separate draft for such a short explanation. Why don't we explain
this to MANET properly, get some feedback, and if they still hate
it, leave the draft without any mention, because the statement I
quoted is enough (in my opinion anyway) to allow an
implementation to use some 6621-influenced technique to decide
whether to regenerate.
I'm good with this approach - someone creates an explanation for the MANET list, essentially reiterating what's in Charlie's draft. Heck, it could even attach the draft. We then point out that 6621-inspired decisions *could* be made by an implementer. I'm positive that a follow-on question will be "Suppose you have an implementation. I have my own implementation. You chose to make some 6621-inspired decisions. I didn't. Will these two different AODVv2 implementations inter-operate?" It would be fantastic if the explanation includes text as to whether or not this is OK (obviously, if it's NOT OK, that would be a show-stopper).
I'll also say again - we need to get these discussions out on the MANET list. We're going to face more and more flak for trying to keep this private.
Regards,
Stan
Kind regards,
Vicky.
On Wed, Mar 2, 2016 at 5:03 PM, Charlie Perkins
<charles.perkins@xxxxxxxxxxxxx
<mailto:charles.perkins@xxxxxxxxxxxxx>> wrote:
Hello again folks,
It seems like I recall seeing a complaint by Christopher
Dearlove to the effect that RFC 6621 is simply inapplicable
to AODVv2. Is that comment something I should respond to on
the mailing list?
I am re-sending the attached draft to show just how wrong his
complaint is. Please let me know if you have any comments.
I sent it out earlier (on November 26 of last year) but did
not get any comments. It's very short. Please take a look.
Regards,
Charlie P.