Subject: [manet] Fwd: New Version Notification for draft-ietf-manet-nhdp-optimization-02.txt

From: Thomas Clausen <[email-masked]>
Date: Thu, 7 Aug 2014 17:34:33 +0200

All,

We’ve updated draft-ietf-manet-nhdp-optimization, to reference the recently published draft-ietf-manet-rfc6779bis (which allowed removing the MIB considerations section from this I-D) added by way of a paragraph to the introduction.

Of course, in an attempt to prove that I’m almost as human as our AD, I ended up submitting a -01 which contained a wrong (& convoluted) version of that paragraph….hence, this recent submission of -02.

In both -01, we also cleaned up a couple of warnings that IDnits threw at us.

In accordance with what Stan proposed a short while back, we’d like to ask that the WG chairs issue a WGLC for:

	o	draft-ietf-manet-nhdp-optimization
	o	draft-ietf-manet-rfc6779bis

Given that this is a question that is bound to come up, might as well take it now:

	“This co-author of these two I-Ds confirm, that he’s not aware of any IPR related to
	  these documents"

Ball over to Stan now ;)

Best,

Thomas

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-ietf-manet-nhdp-optimization-02.txt
> Date: August 7, 2014 at 17:26:47 GMT+2
> To: Thomas Heide Clausen <[email-masked]>, "Christopher Dearlove" <[email-masked]>, "Thomas H. Clausen" <[email-masked]>, Christopher Dearlove <[email-masked]>
> 
> 
> A new version of I-D, draft-ietf-manet-nhdp-optimization-02.txt
> has been successfully submitted by Thomas Heide Clausen and posted to the
> IETF repository.
> 
> Name:		draft-ietf-manet-nhdp-optimization
> Revision:	02
> Title:		An Optimization for the MANET Neighborhood Discovery Protocol (NHDP)
> Document date:	2014-08-07
> Group:		manet
> Pages:		10
> URL:            http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-optimization-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-optimization/
> Htmlized:       http://tools.ietf.org/html/draft-ietf-manet-nhdp-optimization-02
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-nhdp-optimization-02
> 
> Abstract:
>   The link quality mechanism of the MANET Neighborhood Discovery
>   Protocol (NHDP) enables "ignoring" some 1-hop neighbors if the
>   measured link quality from that 1-hop neighbor is below an acceptable
>   threshold, while still retaining the corresponding link information
>   as acquired from HELLO message exchange.  This allows immediate
>   reinstatement of the 1-hop neighbor if the link quality later
>   improves sufficiently.
> 
>   NHDP also collects information about symmetric 2-hop neighbors.
>   However it specifies that if a link from a symmetric 1-hop neighbor
>   ceases being symmetric, including while "ignored" as described above,
>   then corresponding symmetric 2-hop neighbors are removed.  This may
>   lead to symmetric 2-hop neighborhood information being permanently
>   removed (until further HELLO messages are received) if the link
>   quality of a symmetric 1-hop neighbor drops below the acceptable
>   threshold, even if only for a moment.
> 
>   This specification updates RFC6130 "Mobile Ad Hoc Network (MANET)
>   Neighborhood Discovery Protocol (NHDP)", and RFC7181 "The Optimized
>   Link State Routing Protocol version 2 (OLSRv2)" to permit retaining,
>   but ignoring, symmetric 2-hop information when the link quality from
>   the corresponding 1-hop neighbor drops below the acceptable
>   threshold.  This allows immediate reinstatement of the symmetric
>   2-hop neighbor if the link quality later improves sufficiently, thus
>   making the symmetric 2-hop neighborhood more "robust".
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 7 Aug 2014 17:47:38 +0000

Working group participants, 

This is a working group last call on the two documents mentioned above. Please submit any issues or concerns via the list on or before August 21, 2014. 

Regards,
Stan

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 7 Aug 2014 23:36:07 +0200

My comment: there was an object the optimization draft to be a standard
track with an open questioning/discussion, however, no sign for reply from
editors, so I don't see reason/interest for my review for the new update
versions.

AB

On Thursday, August 7, 2014, Stan Ratliff (sratliff) wrote:

> This is a working group last call on the two documents mentioned above.
> Please submit any issues or concerns via the list on or before August 21,
> 2014.
>
> Regards,
> Stan
> _______________________________________________
> manet mailing list
> [email-masked] <javascript:;>
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Christopher Dearlove <[email-masked]>
Date: Thu, 7 Aug 2014 22:48:36 +0100

WGLC is when discussion is held (and before it of course). I do not recall any objection, nor open question.

On 7 Aug 2014, at 22:36, Abdussalam Baryun wrote:

> My comment: there was an object the optimization draft to be a standard track with an open questioning/discussion, however, no sign for reply from editors, so I don't see reason/interest for my review for the new update versions. 
> 
> AB
> 
> [email-masked]
> [email-masked]

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 8 Aug 2014 18:33:17 +0100

Chris,
 
I believe Abdussalam is referring to an email he sent on 3rd July this year
(although it would have been helpful had he made this clear).
 
In http://www.ietf.org/mail-archive/web/manet/current/msg16408.html he raised
some questions during the poll for document adoption. A quick, non-scientific,
and unthorough  scan of the archives does not show an answer.
 
I can't say that I can parse the referenced email with ease, but I think I see a
request to substantiate the assertion implicit in the draft that there is some
optimization benefit to the work. You might reasonably respond to that "allowing
immediate reinstatement of the symmetric 2-hop neighbor if the link quality
later improves sufficiently obviously makes the symmetric 2-hop neighborhood
more robust, and so the updates to the two RFCs clearly represents an
optimization."
 
I must say that I find it hard to correlate that old email with the new comment
that "there was an object the optimization draft to be a standard track with an
open questioning/discussion." I do not see any objection in the archive to the
publication of the draft on the Standards Track. All I see is a "vote" to not
adopt the I-D.
 
Abdussalam: You go on to say "I don't see reason/interest for my review for the
new update versions."  That's OK. There is no requirement for you to review this
document nor to send any email commenting on whether or not you have reviewed
it.
 
Adrian

From: Christopher Dearlove [mailto:[email-masked]] 
Sent: 07 August 2014 22:49
To: Abdussalam Baryun
Cc: Stan Ratliff (sratliff); <[email-masked]>; manet-ads; manet
IETF; Thomas Clausen
Subject: Re: [manet] Working group last call for draft-ietf-manet-rfc6779bis and
draft-ietf-manet-nhdp-optimization
 
WGLC is when discussion is held (and before it of course). I do not recall any
objection, nor open question.

My comment: there was an object the optimization draft to be a standard track
with an open questioning/discussion, however, no sign for reply from editors, so
I don't see reason/interest for my review for the new update versions. 
 
AB

This is a working group last call on the two documents mentioned above. Please
submit any issues or concerns via the list on or before August 21, 2014.

Regards,
Stan

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 8 Aug 2014 18:04:20 +0000

All,

I'll also add that Abdussalam states in that email (in part):

"I vote don't adopt until seeing a presented results of optimisation performance in terms of net data rate and delay with MANET size scenarios and with determined thresholds (experiments or simulations)."

That being the only opinion expressed in the negative, I determined that Abdussalam was "in the rough". Thus, we proceeded. I'll also say that in general, I'm adamantly opposed to *requiring* simulation runs/output for anything occurring in the MANET WG.

Regards,
Stan

On Aug 8, 2014, at 1:33 PM, Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:

Chris,

I believe Abdussalam is referring to an email he sent on 3rd July this year (although it would have been helpful had he made this clear).

In http://www.ietf.org/mail-archive/web/manet/current/msg16408.html he raised some questions during the poll for document adoption. A quick, non-scientific, and unthorough  scan of the archives does not show an answer.

I can't say that I can parse the referenced email with ease, but I think I see a request to substantiate the assertion implicit in the draft that there is some optimization benefit to the work. You might reasonably respond to that "allowing immediate reinstatement of the symmetric 2-hop neighbor if the link quality later improves sufficiently obviously makes the symmetric 2-hop neighborhood more robust, and so the updates to the two RFCs clearly represents an optimization."

I must say that I find it hard to correlate that old email with the new comment that "there was an object the optimization draft to be a standard track with an open questioning/discussion." I do not see any objection in the archive to the publication of the draft on the Standards Track. All I see is a "vote" to not adopt the I-D.

Abdussalam: You go on to say "I don't see reason/interest for my review for the new update versions."  That's OK. There is no requirement for you to review this document nor to send any email commenting on whether or not you have reviewed it.

Adrian

From: Christopher Dearlove [mailto:[email-masked]<http://gmail.com/>]
Sent: 07 August 2014 22:49
To: Abdussalam Baryun
Cc: Stan Ratliff (sratliff); <[email-masked]<mailto:[email-masked]>>; manet-ads; manet IETF; Thomas Clausen
Subject: Re: [manet] Working group last call for draft-ietf-manet-rfc6779bis and draft-ietf-manet-nhdp-optimization

AB

Regards,
Stan
_______________________________________________
manet mailing list
[email-masked]<javascript:;>
https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet

---

From: Christopher Dearlove <[email-masked]>
Date: Fri, 8 Aug 2014 21:56:29 +0100

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.

-- 
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)

> On 8 Aug 2014, at 19:04, "Stan Ratliff (sratliff)" <[email-masked]> wrote:
> 
> All, 
> 
>> On Aug 8, 2014, at 1:33 PM, Adrian Farrel <[email-masked]> wrote:
>> 
>> Chris,
>>  
>> Cc: Stan Ratliff (sratliff); <[email-masked]>; manet-ads; manet IETF; Thomas Clausen

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 9 Aug 2014 13:25:35 +0200

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

---

From: Christopher Dearlove <[email-masked]>
Date: Sat, 9 Aug 2014 12:52:11 +0100

I didn't understand all of that.

But just understand what the extension does. It retains unused certain information that was thrown away. It makes it available immediately it becomes "good" again without waiting for it to be reconfirmed by signalling. It was even an arbitrary decision by the router that caused it to be thrown away. Finally it's an entirely optional decision to use it.

Given all that, the objection is essentially one that says it might be harmful not to have to wait for valid information that you used to have, and that is optional to use. That makes no sense at all.

(The update of the MIB is just a consequence, it's nothing fundamental.)

> On 9 Aug 2014, at 12:25, Abdussalam Baryun <[email-masked]> wrote:
> 
> 
> 
>  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
>

---

From: Thomas Clausen <[email-masked]>
Date: Sat, 9 Aug 2014 14:05:32 +0200

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.

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.

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.

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. 

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

Thomas

> On 09 Aug 2014, at 13:25, Abdussalam Baryun <[email-masked]> wrote:
> 
> 
>

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Sat, 9 Aug 2014 22:55:27 +0000

Abdussalam,

On Aug 9, 2014, at 7:25 AM, Abdussalam Baryun <[email-masked]<mailto:[email-masked]>> wrote:

There is a long history in the IETF of promoting standards and extensions using a thorough logical analysis of the protocols. Note that this does *not* imply an analysis of *a given implementation* of a protocol, via simulation or otherwise. The analysis of a given protocol, or extension, is undertaken by the authors, and by Working Group participants with sufficient interest (and time) to undertake the analysis. This is a critical part of the consensus mode of operation within the IETF, and has never required formal proofs, or simulation runs/output, etc. The stated goal of the IETF has always been "rough consensus and working code".

So at this point, we *still* have the authors, and others in the WG, in consensus that the document represents *exactly* what it says it represents - an optimization for NHDP. If you have analysis to the contrary, WGLC is *exactly* the time to bring that analysis up, and share with the WG situations where you believe implementing this change will have an adverse effect - either on performance, or on protocol integrity. Otherwise, with my co-chair hat firmly on, it still looks like we have rough consensus, with you being "in the rough".

Regards,
Stan

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 10 Aug 2014 02:42:55 +0200

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

---

From: Christopher Dearlove <[email-masked]>
Date: Sun, 10 Aug 2014 10:50:57 +0100

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

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

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

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

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