Subject: [manet] #51 (nhdp-optimization): Analysis of OLSRv2/NHDP-optimized Handling neighbor connection with link quality change

From: "manet issue tracker" <[email-masked]>
Date: Sun, 10 Aug 2014 10:23:41 -0000

#51: Analysis of OLSRv2/NHDP-optimized Handling neighbor connection with link
quality change

 The neighbor nodes reaction to changes in the link quality is not
 considered by the draft.
 For example:

 A ------- B ------- C     (node B is N1 and C is N2)

 When link quality change,

 A - - - - B - - - - C      (node A lost links but still aware)

 N1 and N2 may optimise as well for their links quality change.
 B has A as N1 and C as N1, so B lost links.

 When A has change in link quality then:

 A ------- B -------- C    (at node A recovered links)

 A - - - -  B  - - - -  C     (at node B lost links which is N1 for A)

 B is not connected to C but A thinks they are. There is high probability
 that when the quality changes in links between A-B there will be changes
 in B-C. Furthermore, C may not be optimizing router, so it will loose A as
 neighbour but A still has C as 2-hop symmetric  neighbor. This can
 increase packet loss in the network.

 Best,

 AB

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-manet-nhdp-
  [email-masked]         |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  nhdp-optimization        |    Version:
 Severity:  In WG Last Call          |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://tools.ietf.org/wg/manet/trac/ticket/51>
manet <http://tools.ietf.org/manet/>

---

From: Christopher Dearlove <[email-masked]>
Date: Sun, 10 Aug 2014 12:59:20 +0100

> #51: Analysis of OLSRv2/NHDP-optimized Handling neighbor connection with link

I'm not sure what #51 means, but the analysis is flawed.

> The neighbor nodes reaction to changes in the link quality is not

That's because it has no reaction to changes in the link quality as viewed by A. A's link quality is not communicated to B. If the change lasts until the next HELLO message, A will report the link lost, and then B will react. Exactly as it would have done without this optimisation. If B does its own link quality process, it won't necessarily (very often won't) have the same transients in it, and then B's reaction will be governed by it running the protocol, optimised or not.

> N1 and N2 may optimise as well for their links quality change.

Your notation is messed up here. Your nodes are A, B, and C. I think you are trying to use N1 and N2 for relationship, but then N1 and N2 can't do anything. What's done is done by A and B. This does not help.

> B has A as N1 and C as N1, so B lost links.

I don't know what you are trying to say here exactly, but B has not lost anything due to A's link quality decisions, until A sends a HELLO message. If A does send a HELLO message then the optimisation is irrelevant.

The only way B is affected is if it also has a link quality change. Which is possible, but by no means certain. And not a problem if it does.

> B is not connected to C

Why? There absolutely no reason why the B-C link has changed, when we are talking about a change in quality in the B to A link. If it does this is now compounding even more effects.

> but A thinks they are. There is high probability
> in B-C.

Why? Completely depends on why the link is poor. To say "there is high probability there will be changes" is simple assertion without evidence.

> Furthermore, C may not be optimizing router, so it will loose A as

lose

> increase packet loss in the network.

The optimisation is really irrelevant here. If the B-C link changes then A won't know about it until B signals that. That's completely irrelevant to this optimisation.

If the link to B has more than a transient failure, B will be lost as a neighbour. B's links are then irrelevant, so whop cares if a link B-C is kept or not?

If the link to B has a transient failure, you are suggesting that B to C will fail (not justified) and that therefore you should discard C, because the B-C link is bad. But now you have chosen to discard the assumption of correlation that you used when it suited you, because now A to B transient fails (the case of interest, as longer term failure will have its usual non-optimised effect) but B to C is assumed permanently (not transiently) failed.

That's just unrealistic special case pleading (you've assumed in particular that B-C fails at the same time, that this is detected by B, but it is longer term, not transient  - that only transient matters is because if nontransient  then the main protocol will define what happens when a HELLO message is next sent). Of course we can devise cases where any change happens not to work well here. But the best you've found makes unjustified assumptions, to make things no worse than they would have been had, for example, A used a more smoothed link quality. Meanwhile actually realistic cases where things are improved are ignored by you.

And, should you run in a network with unusual properties, you still always have the option don't use the optimisation.

You're whole argument boils down to "I'm trying hard, making unrealistic assumptions, to find a special case where there's a problem". And on that basis you suggest that the optional optimisation that will demonstrably help in realistic cases shouldn't be defined.

That's not a good argument.

---

From: Thomas Clausen <[email-masked]>
Date: Sun, 10 Aug 2014 14:31:32 +0200

> On 10 Aug 2014, at 12:23, "manet issue tracker" <[email-masked]> wrote:
> 

Did you actually read RFC6130/7182?

The Link Quality is only ever recorded and used inside a router, and is never communicated to neighbors. 

This draft does not change that.

> N1 and N2 may optimise as well for their links quality change.

I do not understand what the above sentence means.

> B has A as N1 and C as N1, so B lost links.

If Router A's link quality decisions means that it considers the link to B as "lost", then that doesn't cause  B to lose anything. That can only due to a local decision by B as to link quality - or, when B receives a HELLO message from A....which renders this discussion moot.

> B is not connected to C but A thinks they are.

Now I am convinced that you need to go back and re-read RFC6130. Why would a local decision in A based on its perceived link-quality of the link A-B have the faintest impact on the link B-C?

> There is high probability

No, that's decidedly not a true statement. There is absolutely no reason to assume that a change in the link-quality of the link between A and B will also change the link quality of the link between B and C. For example, if the link quality changes due to "noise" being generated "to the left of A", it may not reach the link B-C. Or A-B and B-C may be links over different channels, medias, ...

> Furthermore, C may not be optimizing router,

I do not know what that is.

> so it will loose A as

Incorrect.

A's operation does not depend on if "B" or "C" implement (or not) the optimization in this draft.

Now, if A has C as a 2-hop symmetric neighbor when B has lost the link, then (i) that's a transient effect, and (ii) A will know about it (in either case) when B sends a HELLO message, and (iii) if the link A-B is more than just transiently broken, then A won't use it (and, won't use the link B-C either).

May I also point out that you are actually first making an (incorrect) assertion in your argument (that if the link quality for A-B as seen by A, degrades, then so does the link quality for B-C, as seen by B, both transiently), then disregarding the very same assertion in your argument by assuming that the incurred failure affects B-C permanently. 

Self-contradicting arguments like that make for a very, very unconvincing case.

Thomas

---

From: Henning Rogge <[email-masked]>
Date: Sun, 10 Aug 2014 16:52:05 +0200

Abdussalam,

are you maybe mixing up "link quality" and "link metric" ?

One is a local value (often with hysteresis) to turn links on and of.

The other one is communicated between nodes and used by the dijkstra algorithm.

Henning Rogge

On Sun, Aug 10, 2014 at 12:23 PM, manet issue tracker
<[email-masked]> wrote:
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 10 Aug 2014 17:21:29 +0200

I considered to follow the method of your initial analysis within the
presentation of IETF 89 meeting. Please see slides 21-24 related to the
draft before adoption.

> I'm not sure what #51 means, but the analysis is flawed.
Means analysing the router decisions/performances if it considers connected
with neighbors or not while it has link quality change.

> That's because it has no reaction to changes in the link quality as viewed
> by A.

The reaction is link lost within router A and other reaction specified
within A.

> A's link quality is not communicated to B.

Yes I agree.

> If the change lasts until the next HELLO message, A will report the link
> lost, and then B will react.

Agree

>  Exactly as it would have done without this optimisation. If B does its
> own link quality process, it won't necessarily (very often won't) have the
> same transients in it, and then B's reaction will be governed by it running
> the protocol, optimised or not.
>
> > For example:
> >
> Your notation is messed up here. Your nodes are A, B, and C. I think you
> are trying to use N1 and N2 for relationship, but then N1 and N2 can't do
> anything. What's done is done by A and B. This does not help.

Neighbor relationship for hop 1 and hop 2.

> I don't know what you are trying to say here exactly, but B has not lost
> anything due to A's link quality decisions, until A sends a HELLO message.
> If A does send a HELLO message then the optimisation is irrelevant.

B lost not because of A, I mentioned that N1 and N2 may optimize as well so
if there is a change in B links then it will make them as lost.

>
> The only way B is affected is if it also has a link quality change. Which
> is possible, but by no means certain. And not a problem if it does.

That was my point. So why it is no problem.

> Why? There absolutely no reason why the B-C link has changed, when we are
> talking about a change in quality in the B to A link. If it does this is
> now compounding even more effects.

Because C is optimizing also in this example, so the three nodes optimize
after change in the two links, but link AB changes before BC.

> Why? Completely depends on why the link is poor. To say "there is high
> probability there will be changes" is simple assertion without evidence.

Happens Within the mobile channel characteristics  as MANET, the movement
and the node environment  are usually the largest reason of link quality
change.

> The optimisation is really irrelevant here. If the B-C link changes then A
> won't know about it until B signals that.

Yes A will not know but while it recover as connected but B is having that
link lost.

> That's completely irrelevant to this optimisation.
>
> If the link to B has more than a transient failure, B will be lost as a
> neighbour. B's links are then irrelevant, so whop cares if a link B-C is
> kept or not?

The example is showing after recovering for A. As you showed in your
presentation that there is difference in reaction between A if it optimise
or not. If A optimises then at recovery it will not loose 2 hop link but in
normal it does loose.

>
> If the link to B has a transient failure, you are suggesting that B to C
> will fail (not justified) and that therefore you should discard C, because
> the B-C link is bad. But now you have chosen to discard the assumption of
> correlation that you used when it suited you, because now A to B transient
> fails (the case of interest, as longer term failure will have its usual
> non-optimised effect) but B to C is assumed permanently (not transiently)
> failed.
>
> That's just unrealistic special case pleading (you've assumed in
> particular that B-C fails at the same time, that this is detected by B, but
> it is longer term, not transient  - that only transient matters is because
> if nontransient  then the main protocol will define what happens when a
> HELLO message is next sent).

It can happen as routers have different quality threshold and
neighbor links may have similar failur reasons.

Of course we can devise cases where any change happens not to work well
> here. But the best you've found makes unjustified assumptions, to make
> things no worse than they would have been had, for example, A used a more
> smoothed link quality. Meanwhile actually realistic cases where things are
> improved are ignored by you.
>
> And, should you run in a network with unusual properties, you still always
> have the option don't use the optimisation.
>
> You're whole argument boils down to "I'm trying hard, making unrealistic
> assumptions, to find a special case where there's a problem". And on that
> basis you suggest that the optional optimisation that will demonstrably
> help in realistic cases shouldn't be defined.

I disagree, I think it is very simple with three nodes as neighbors.
Usually MANET working group look into large networks with very high
probability of link changes. Overall, we can assume worst case and good
case for this three node example, so the probability is about 0.25 when all
nodes optimise. We can go into analysing all cases and then find the
absolute probability which includes if nodes are optimising or not or with
larger sizes.

> That's not a good argument.

It is good as long there are no test results with different MANET sizes
proving optimization as with good performance. We need to look into the
worst cases while analysing. Do you think my example was the worst case?

AB

> [email-masked] <javascript:;>

---

From: Christopher Dearlove <[email-masked]>
Date: Sun, 10 Aug 2014 16:34:47 +0100

I'm just not going to do this (going through posting point by point) again. I'm just going to reply to your last point. No, I don't think this is a useful, consistent, well thought through or relevant case or objection. I've explained why.

(I'll just comment that an illustration of that is the simple invention of a 0.25 figure, which has no foundation whatsoever.)

On 10 Aug 2014, at 16:21, Abdussalam Baryun wrote:

> I considered to follow the method of your initial analysis within the presentation of IETF 89 meeting. Please see slides 21-24 related to the draft before adoption. 
> 
> Means analysing the router decisions/performances if it considers connected with neighbors or not while it has link quality change. 
> 
>  
> That's because it has no reaction to changes in the link quality as viewed by A. 
> 
> The reaction is link lost within router A and other reaction specified within A. 
>  
> If the change lasts until the next HELLO message, A will report the link lost, and then B will react.
> 
> Agree 
>  
>  Exactly as it would have done without this optimisation. If B does its own link quality process, it won't necessarily (very often won't) have the same transients in it, and then B's reaction will be governed by it running the protocol, optimised or not.
> 
> > For example:
> >
> B lost not because of A, I mentioned that N1 and N2 may optimize as well so if there is a change in B links then it will make them as lost. 
>  
> 
> Because C is optimizing also in this example, so the three nodes optimize after change in the two links, but link AB changes before BC. 
>  
> 
> Happens Within the mobile channel characteristics  as MANET, the movement and the node environment  are usually the largest reason of link quality change. 
> 
> 
> The optimisation is really irrelevant here. If the B-C link changes then A won't know about it until B signals that. 
> 
> Yes A will not know but while it recover as connected but B is having that link lost. 
>  
> The example is showing after recovering for A. As you showed in your presentation that there is difference in reaction between A if it optimise or not. If A optimises then at recovery it will not loose 2 hop link but in normal it does loose. 
>  
> 
> That's just unrealistic special case pleading (you've assumed in particular that B-C fails at the same time, that this is detected by B, but it is longer term, not transient  - that only transient matters is because if nontransient  then the main protocol will define what happens when a HELLO message is next sent). 
> 
> It can happen as routers have different quality threshold and neighbor links may have similar failur reasons. 
> 
> Of course we can devise cases where any change happens not to work well here. But the best you've found makes unjustified assumptions, to make things no worse than they would have been had, for example, A used a more smoothed link quality. Meanwhile actually realistic cases where things are improved are ignored by you.
> 
> I disagree, I think it is very simple with three nodes as neighbors. Usually MANET working group look into large networks with very high probability of link changes. Overall, we can assume worst case and good case for this three node example, so the probability is about 0.25 when all nodes optimise. We can go into analysing all cases and then find the absolute probability which includes if nodes are optimising or not or with larger sizes. 
>  
> 
> It is good as long there are no test results with different MANET sizes proving optimization as with good performance. We need to look into the worst cases while analysing. Do you think my example was the worst case?
> 
> AB
>

---

From: Thomas Clausen <[email-masked]>
Date: Sun, 10 Aug 2014 17:42:34 +0200

> On Sunday, August 10, 2014, Christopher Dearlove wrote:

<SNIP>

> That was my point. So why it is no problem.  

It doesn’t work that way - you do not get to ask someone to “prove a negative”.

The onus is on you to prove that there is a problem, Abdussalam.

<SNIP>

> Happens Within the mobile channel characteristics 

I do not know what “mobile channel characteristics” are.

>  as MANET, the movement and the node environment  are usually the largest reason of link quality change. 

Anybody who has run a multi-hop wireless network with static routers can testify to the fact that link quality change happens for a great many factors other than “movement”. 

<SNIP>

> I disagree, I think it is very simple with three nodes as neighbors. Usually MANET working group look into large networks with very high probability of link changes. Overall, we can assume worst ca…

I am sorry, I am not sure that I understand the above, nor the relevance of the above.

> It is good as long there are no test results with different MANET sizes proving optimization as with good performance. We need to look into the worst cases while analysing. Do you think my example…

No, your example was invalid because you changed your assumptions as you worked through it.

Thomas

---

From: Henning Rogge <[email-masked]>
Date: Sun, 10 Aug 2014 17:48:27 +0200

On Sun, Aug 10, 2014 at 5:42 PM, Thomas Clausen
<[email-masked]> wrote:
> Anybody who has run a multi-hop wireless network with static routers can
> testify to the fact that link quality change happens for a great many
> factors other than “movement”.

Exactly... especially with metrics based on packet loss.

Hell, even on a simulated link with a perfect random generator you get
fluctuations of ETX or ETT metrics because of the effects of the
statistical distribution of packet loss events (e.g. Binomial
distribution).

Henning Rogge

---

From: Christopher Dearlove <[email-masked]>
Date: Sun, 10 Aug 2014 17:46:25 +0100

Actually, I'm going to add one more comment. No, the worst case is not what matters. I can devise a worst case. In it the whole protocol doesn't work. For example that could be down to a mismatch in mobility and interval parameters. Or an ever-thrashing link quality. Or other possibilities. This optimisation is irrelevant to actual worst cases.

What matters is does it improve the case it is designed for? (yes). Does it behave well in other normal cases, such as link quality going bad and staying there? (yes). Can it behave catastrophically? (no, because if left everything will time out).  Is there a common case it seriously makes worse? (none has been presented - no, this is not one). Is there a mitigation in unusual circumstances where there is a problem? (yes, don't use it, it's optional).

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 11 Aug 2014 12:08:18 +0200

> factors other than “movement”.
That change with static depend on the channel as you mentioned above
that you did not know (defined by many if googled), but I included it as a
factor with mobility. The network/node movement affects the channel
characteristic as well.

 Usually as the draft applicability statement has accepted the general
purpose scenario, so the A-B link frequency channel mostly similar to the
B-C frequency channel so both links can have high correlation of
link quality change.

AB

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 11 Aug 2014 10:20:10 +0000

The key words there are “can have”. Not “will have”.

And even then you weren’t consistent, you assume B-C went down when A-B did, but not that B-C went up when A-B did. This may be considered attempting to have your cake and eat it, if the cake is finding a problem. (I’m not sure why you are trying hard to find a problem no one else has, but that seems to be the case.)

And, as has been said several times, if you have a scenario with a problem, just don’t use it.

(Similarly if you have a scenario where it is pointless, you can decide not to use it. An example there could be a heavily damped link quality that if it goes down can’t come back up in less than REFRESH_INTERVAL time. It won’t do any harm – except a trivial amount of storage and processing – but it won’t do much good either.)

--
Christopher Dearlove
Senior Principal Engineer, Information Assurance Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked]<mailto:[email-masked]> | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

From: manet [mailto:[email-masked]] On Behalf Of Abdussalam Baryun
Sent: 11 August 2014 11:08
To: Thomas Clausen
Cc: Christopher Dearlove; [email-masked]
Subject: Re: [manet] #51 (nhdp-optimization): Analysis of OLSRv2/NHDP-optimized Handling neighbor connection with link quality change

That change with static depend on the channel as you mentioned above that you did not know (defined by many if googled), but I included it as a factor with mobility. The network/node movement affects the channel characteristic as well.

 Usually as the draft applicability statement has accepted the general purpose scenario, so the A-B link frequency channel mostly similar to the B-C frequency channel so both links can have high correlation of link quality change.

AB

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 11 Aug 2014 13:27:43 +0200

On Monday, August 11, 2014, Dearlove, Christopher (UK) wrote:

> Yes I used that "can have" because I want to consider the real full
possibilities, so we not trying to make the problem but we consider it in
our draft. so I think you agree with the word I used.

>
>
> And even then you weren’t consistent, you assume B-C went down when A-B
> did, but not that B-C went up when A-B did. This may be considered
> attempting to have your cake and eat it, if the cake is finding a problem.
> (I’m not sure why you are trying hard to find a problem no one else has,
> but that seems to be the case.)
>
> I think this is the analysis of one possible issue. I did consider that
they become up together as well and they may not be together. The key
problem that you may missed is that each neighbour node don't need to have
same quality level threshold so the becoming up together may not happen
with time difference period of when they went down. The examples considers
optimization as if each node can have different quality level (I think this
is allowed that optimized routers can have different measures). So
three factors to consider within the example: the routers
(optimizing/normal), the optimized-routers' measures of quality
same/different, and the links' frequency of change below threshold.

> Or we can find a way to amend the draft to consider such
situation/condition and solve it.

>
>
> (Similarly if you have a scenario where it is pointless, you can decide
> not to use it. An example there could be a heavily damped link quality that
> if it goes down can’t come back up in less than REFRESH_INTERVAL time. It
> won’t do any harm – except a trivial amount of storage and processing – but
> it won’t do much good either.)
>
>
The optimization is working to improve for the time below the refresh
interval. So my example is about times below that time. The draft
mentions that the optimization is used to improve when there are temporary
short quality changes. IMHO it only considers one link failure, which is
A-B the first hop (I suggest to mention that in the applicability
statement). what about if both neighbor hops get considered changed by
optimize-routers of the routing path.

AB

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 11 Aug 2014 12:10:45 +0000

There is no need (or even advantage) to change (amending suggests a problem, which there isn’t) the draft based on anything you have posted.

There isn’t even anything that could be changed because, and let’s say it again, link quality information is not communicated. In addition two hop information is not communicated (only one hop information that becomes two hop information, but it’s about it as two hop information that this applies).

From: Abdussalam Baryun [mailto:[email-masked]]
Sent: 11 August 2014 12:28
To: Dearlove, Christopher (UK)
Cc: Thomas Clausen; Christopher Dearlove; [email-masked]
Subject: Re: [manet] #51 (nhdp-optimization): Analysis of OLSRv2/NHDP-optimized Handling neighbor connection with link quality change

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.

On Monday, August 11, 2014, Dearlove, Christopher (UK) wrote:
The key words there are “can have”. Not “will have”.
Yes I used that "can have" because I want to consider the real full possibilities, so we not trying to make the problem but we consider it in our draft. so I think you agree with the word I used.

And even then you weren’t consistent, you assume B-C went down when A-B did, but not that B-C went up when A-B did. This may be considered attempting to have your cake and eat it, if the cake is finding a problem. (I’m not sure why you are trying hard to find a problem no one else has, but that seems to be the case.)
I think this is the analysis of one possible issue. I did consider that they become up together as well and they may not be together. The key problem that you may missed is that each neighbour node don't need to have same quality level threshold so the becoming up together may not happen with time difference period of when they went down. The examples considers optimization as if each node can have different quality level (I think this is allowed that optimized routers can have different measures). So three factors to consider within the example: the routers (optimizing/normal), the optimized-routers' measures of quality same/different, and the links' frequency of change below threshold.

And, as has been said several times, if you have a scenario with a problem, just don’t use it.
Or we can find a way to amend the draft to consider such situation/condition and solve it.

The optimization is working to improve for the time below the refresh interval. So my example is about times below that time. The draft mentions that the optimization is used to improve when there are temporary short quality changes. IMHO it only considers one link failure, which is A-B the first hop (I suggest to mention that in the applicability statement). what about if both neighbor hops get considered changed by optimize-routers of the routing path.

AB

--

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 13 Aug 2014 09:21:24 -0700

I concur with Chris.

Ulrich

On Mon, Aug 11, 2014 at 5:10 AM, Dearlove, Christopher (UK)
<[email-masked]> wrote:
> There is no need (or even advantage) to change (amending suggests a problem,
> which there isn’t) the draft based on anything you have posted.
>
>
>
> There isn’t even anything that could be changed because, and let’s say it
> again, link quality information is not communicated. In addition two hop
> information is not communicated (only one hop information that becomes two
> hop information, but it’s about it as two hop information that this
> applies).
>
>
>
> --
>
> Christopher Dearlove
>
> [email-masked] | http://www.baesystems.com
>
> Subject: Re: [manet] #51 (nhdp-optimization): Analysis of
> OLSRv2/NHDP-optimized Handling neighbor connection with link quality change
>
>
>
>
>
> *** WARNING ***
>
> For information regarding Red Flags that you can look out for in emails you
> receive, click here.
> If you feel the email is suspicious, please follow this process.
>
>
>
> And even then you weren’t consistent, you assume B-C went down when A-B did,
> but not that B-C went up when A-B did. This may be considered attempting to
> have your cake and eat it, if the cake is finding a problem. (I’m not sure
> why you are trying hard to find a problem no one else has, but that seems to
> be the case.)
>
> I think this is the analysis of one possible issue. I did consider that they
> become up together as well and they may not be together. The key problem
> that you may missed is that each neighbour node don't need to have same
> quality level threshold so the becoming up together may not happen with time
> difference period of when they went down. The examples considers
> is allowed that optimized routers can have different measures). So three
> factors to consider within the example: the routers (optimizing/normal), the
> optimized-routers' measures of quality same/different, and the links'
> frequency of change below threshold.
>
>
>
> (Similarly if you have a scenario where it is pointless, you can decide not
> to use it. An example there could be a heavily damped link quality that if
> it goes down can’t come back up in less than REFRESH_INTERVAL time. It won’t
> do any harm – except a trivial amount of storage and processing – but it
> won’t do much good either.)
>
>
>
> interval. So my example is about times below that time. The draft mentions
> that the optimization is used to improve when there are temporary short
> quality changes. IMHO it only considers one link failure, which is A-B the
> first hop (I suggest to mention that in the applicability statement). what
> about if both neighbor hops get considered changed by optimize-routers of
> the routing path.
>
>
>
> AB
>
>
>
> --
>
>
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 14 Aug 2014 07:27:11 +0200

WG to analyse the packet loss problem for this optimization. All MANETs
have packet lost but the proposed optimized routers need to avoid its
possible increase.

On Monday, August 11, 2014, Dearlove, Christopher (UK) wrote:

>  There is no need (or even advantage) to change (amending suggests a
> problem, which there isn’t) the draft based on anything you have posted.
>
> You did not analyse by saying no need or isn't a problem. IMHO there is
the packet loss problem because router A when recovered it considers C as
reached through B but B has the link B-C as lost. The optimization
improves packet delay issues but increases packet loss or decreases
average delivery rate for the MANET that has many optimiz-routers.

> again, link quality information is not communicated.
>
> This draft has no update to nhdp's information exchange communication, and
I did not mention communication. The performance difference between normal
router and optimize-router is within packet-delay and packet-loss. However,
the draft gives the opportunity that each optimize-router may change its
link information which may loose consistency with its neighbours'
information, so packets can get lost with higher possibility. I will look
into the draft's update of nhdp/olsv2 algorithm and see if I can solve the
issue without communicating any info.

AB

---

From: Jiazi YI <[email-masked]>
Date: Thu, 14 Aug 2014 09:54:21 +0200

Hi,

On Thu, Aug 14, 2014 at 7:27 AM, Abdussalam Baryun <
[email-masked]> wrote:

> <snip>
> I did not mention communication.
>

<snip>

>  I will look into the draft's update of nhdp/olsv2 algorithm and see if I
> can solve the issue without communicating any info.
>
>
To be honest, what you said is kind of self-contradictory, and hard to
parse.

Jiazi

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 14 Aug 2014 08:43:25 +0000

The flaws in your analysis have been pointed out several times. I’m not going to repeat them.

From: Abdussalam Baryun [mailto:[email-masked]]
Sent: 14 August 2014 06:27
To: Dearlove, Christopher (UK)
Cc: Thomas Clausen; Christopher Dearlove; [email-masked]
Subject: [manet] #51 (nhdp-optimization): Analysis of OLSRv2/NHDP-optimized Handling neighbor connection with link quality change

WG to analyse the packet loss problem for this optimization. All MANETs have packet lost but the proposed optimized routers need to avoid its possible increase.

On Monday, August 11, 2014, Dearlove, Christopher (UK) wrote:
There is no need (or even advantage) to change (amending suggests a problem, which there isn’t) the draft based on anything you have posted.
You did not analyse by saying no need or isn't a problem. IMHO there is the packet loss problem because router A when recovered it considers C as reached through B but B has the link B-C as lost. The optimization improves packet delay issues but increases packet loss or decreases average delivery rate for the MANET that has many optimiz-routers.

There isn’t even anything that could be changed because, and let’s say it again, link quality information is not communicated.
This draft has no update to nhdp's information exchange communication, and I did not mention communication. The performance difference between normal router and optimize-router is within packet-delay and packet-loss. However, the draft gives the opportunity that each optimize-router may change its link information which may loose consistency with its neighbours' information, so packets can get lost with higher possibility. I will look into the draft's update of nhdp/olsv2 algorithm and see if I can solve the issue without communicating any info.

AB