[aodvv2-discuss] Re: Some proposed resolutions for AODVv2 issues in the issue tracker
- From: Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx>
- To: aodvv2-discuss@xxxxxxxxxxxxx
- Date: Tue, 6 Jan 2015 00:58:52 +0100
Hi Stan, hi all,
Am 31.12.2014 um 20:29 schrieb Stan Ratliff <ratliffstan@xxxxxxxxx>:
> If the penalty is "less improvement", and not failure. then I'll push harder
> for the text change. Otherwise, we're caught in the procedural issue of a
> standards-track doc having a downref to an informational RFC, and the other
> problems that Thomas noted - it is legitimate to state that RFC 6621
> specifies multiple schema, and to question whether those schema interoperate
> with regard to AODVv2. Replacing it with text saying "It's up to you, oh
> mighty implementer." addresses the issue by taking it off the table.
>
For what it's worth, these arguments seem very convincing to me. However, the
information that RFC 6621 describes a suitable way to achieve this may be a
helpful hint for someone less experienced than you are (Remembering my
struggles with neighbor monitoring mechanisms, I would've found such hints very
helpful). Would it be possible and/or useful to downgrade the reference to RFC
6621 from normative to informative by mentioning it in a half-sentence, for
example like so:
“Implementations are free to choose their own heuristics, for reducing
multicast overhead. One example for this is [RFC6621].”
?
Regards,
Lotte
> Regards,
> Stan
>
>
> On Wed, Dec 31, 2014 at 2:11 PM, Charlie Perkins
> <charles.perkins@xxxxxxxxxxxxx> wrote:
>
> Hello Stan,
>
> I am O.K. with that, maybe, especially regarding duplicate transmissions.
> However, RFC 6621 specifies ways of implementing reduced relay sets that
> can substantially improve performance.
>
> If some nodes implement RFC 6621, and others do not, the penalty is
> not failure, but less improvement. It's always better than brute force,
> though, even if some nodes do not implement.
>
> Regards,
> Charlie P.
>
>
> On 12/31/2014 10:57 AM, Stan Ratliff wrote:
>> *** This email is about Issue #32 (Multicast transmission) ***
>>
>>
>> ============================================================
>>
>> [manet] #32 (aodvv2): Multicast transmission
>>
>> I updated the issue tracker with some discussion from Abdussalam.
>>
>> We should ask Adrian if we can close this issue.
>>
>> ============================================================
>>
>> I think the current draft statement "In order to reduce multicast overhead,
>> retransmitting multicast packets in MANETs SHOULD be done according to
>> methods specified in [RFC6621]" should be changed. I propose we use the
>> standard "cop-out" that is in many, many places in DLEP:
>> "Implementations are free to choose their own hueristics for reducing
>> multicast overhead."
>> Provided, of course, that won't cause interoperability issues (e.g two
>> different implementations, using different multicast retransmission schemes,
>> trying to connect to each other).
>>
>> Regards,
>> Stan
>>
>
>
Other related posts:
