[manet] Working group last call for draft-ietf-manet-rfc6779bis and draft-ietf-manet-nhdp-optimization

[Abdussalam Baryun <[e-mail]>]

Hi Thomas,

I agree that the draft finds ways to reduce overhead but I wanted to make
sure of the overall performance.

On Saturday, August 9, 2014, Thomas Clausen wrote:

> Abdussalam,
>
> If you, in your implementation of NHDP/OLSRv2, do not want to include this
> optimization, then you can simply decide to not implement it. Your
> implementation will, then, still be fully interoperable with an
> implementation that does include this optimization -- this is described in,
> for example, the applicability statement of the document.
>

IMHO with just seeing draft with no results the Interoperable may be with
better performance for optimiz-routers and can give less performance
to normal routers within MANET.  I think the draft has no recommendations
related to that issue.


> However, in the situations clearly described in the document (for example,
> in paragraph 4 of the introduction), your implementation will then take
> longer time to recover from certain types of link failure.
>

I agree, but what about packet loss, there is a trade off, so
quicker recover can have higher possibility of packet loss.


>
> The exact benefit from including this optimization in your deployments of
> NHDP/OLSRv2 are for you to evaluate -- nobody can do that in your place: we
> do not know the frequency of the type of link failures where this
> optimization is effective in your deployment specifics.
>

 Ok but I was thinking to find a solution for the user of the draft, as
the method that determines the optimization related to failure frequency.


> There are, however, no "downsides" to implementing this optimization, no
> situations in which it degrades performance, and -- as we indicated -- it's
> very light to implement. So even if you do not expect to benefit from the
> optimization, then it'd probably be silly to not do so.
>

I cannot be sure of no downside only if I see results, you are sure may
be because you have seen some. I think there can be downsides if there are
no conditions for this optimisations.


>
> Now, I am not sure why you talk about "optimum", or "best performance", I
> do not believe that anybody has claimed such absolutes.
>

Ok now I understand that this draft is reducing overhead, quick recover,
and not optimising for best performance.

AB


>
> Thomas
>
> On 09 Aug 2014, at 13:25, Abdussalam Baryun <[e-mail]>
> wrote:
>
>
>
> On Friday, August 8, 2014, Christopher Dearlove wrote:
>
>> Adrian
>>
>> Thanks for the effort in unearthing this. I take the same view as Stan. I
>> will note that I have implemented this, but don't have any publishable
>> performance results. But as I said, I agree with Stan on the lack of
>> necessity of this.
>>
>
>  The draft is updating two standards, and promoting better performance. I
> remember when the first present of the draft at IETF 89, I asked you of its
> difference, and the answer was no much code difference just performance.
>
>  When we promote optimum that means best performance? So how can this WG
> get sure of that optimum behavior, do we just follow
> the author/implementor, is that IETF practice.  The results can be
> necessary to prove it's a suitable standard update. If you want it to be
> not necessary to give results then no need to update our standards, just a
> new standard extension.
>
> AB
>
>
>>