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

[Christopher Dearlove <[e-mail]>]

Comments inline


On 10 Aug 2014, at 01:42, Abdussalam Baryun wrote:

> 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. 

That's pure speculation, and speculation that doesn't really make sense, because if it were so then receiving information would be bad in the same way. Of course that's theoretically possible in some cases, but in that case you've got a bigger problem than this.

> 
> 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. 

How? It can certainly have lower possibility of packet loss (it can reestablish what might be the only link to a two hop neighbour, and routers beyond that).

> 
> 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. 

I don't know what that means.

> 
> 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.

That's again pure speculation, and same comment applies.

> 
> 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.  

What do you mean by performance? Recovering the use of links quickly can improve various things I would consider performance (may include better routes, and reestablishing necessary routes hence improving delivery).

And finally, if you find some exotic circumstance where this makes things worse, then just don't use it. If you don't trust what you consider unknown, then just don't use it.

Meanwhile the acknowledgements include my colleague Liz Cullen who observed routing inefficiencies in a simulated scenario and identified what was happening (glitch in local link quality causing longer term two hop router loss). The draft is the result I worked out for how to fix that. So this started from a case that showed where not having this caused inferior performance. Without any change in signalling, so no extra overhead or compatibility issues.

> 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
>> 
>>>