Subject: [manet] FW: I-D Action:draft-ietf-manet-nhdp-mib-07.txt (UNCLASSIFIED)

From: "Cole, Robert G Dr CIV USA" <[email-masked]>
Date: Mon, 3 Jan 2011 09:26:00 -0500

Classification: UNCLASSIFIED
Caveats: NONE

We have updated the NHDP-MIB draft.  It is now in a reasonably final
state.  We have addressed the outstanding issues from previous drafts.
We have completed the Notifications Group and cleaned up the issues
found by running through 'smilint' (for the most part).  Two issues
remain:

1) this draft needs a thorough review by the WG and by some outside MIB
experts.  We'll work with the AD to get some outside the WG reviewers.

2) We have chosen to use a new TC called Float32 for the link quality
objects.  Float32 is currently in draft form.  We cannot finalize our
draft until the Float32 draft is published. We have been told by the
Float32 authors and the ADs that this draft will move quickly to
publication.

Thanks,
Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Monday, January 03, 2011 5:15 AM
To: [email-masked]
Cc: [email-masked]
Subject: [manet] I-D Action:draft-ietf-manet-nhdp-mib-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Mobile Ad-hoc Networks Working Group of
the IETF.

	Title           : Definition of Managed Objects for the
Neighborhood Discovery Protocol
	Author(s)       : U. Herberg, et al.
	Filename        : draft-ietf-manet-nhdp-mib-07.txt
	Pages           : 64
	Date            : 2011-01-03

This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community.
In particular, it describes objects for configuring parameters of the
Neighborhood Discovery Protocol (NHDP) process on a router.  The MIB
defined in this memo, denoted NHDP-MIB, also reports state, performance
information and notifications.  This additional state and performance
information is useful to troubleshoot problems and performance issues
during neighbor discovery.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-mib-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Classification: UNCLASSIFIED
Caveats: NONE

---

From: <[email-masked]>
Date: Mon, 3 Jan 2011 14:37:13 +0000

How are the link quality metrics in float32 format here meant to be reconciled with the percentage link quality metrics in
draft-ietf-manet-dlep-00 ?

thanks,

Lloyd Wood
http://sat-net.com/L.Wood
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Cole, Robert G Dr CIV USA [[email-masked]]
Sent: 03 January 2011 14:26
To: [email-masked]
Subject: [manet] FW: I-D Action:draft-ietf-manet-nhdp-mib-07.txt        (UNCLASSIFIED)

Thanks,
Bob

---

From: "Cole, Robert G Dr CIV USA" <[email-masked]>
Date: Mon, 3 Jan 2011 10:10:18 -0500

Lloyd,

Sorry, but they are not meant to reconcile with
draft-ietf-manet-dlep-00, instead there are meant to reconcile with the
NHDP draft, i.e.:

"Link quality information is defined in this specification as a
   normalized, dimensionless, value in the interval zero to one,
   inclusive, where the greater the value, the better the link quality."

Thanks,
Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, January 03, 2011 9:37 AM
To: Cole, Robert G Dr CIV USA; [email-masked]
Subject: RE: [manet] FW: I-D
Action:draft-ietf-manet-nhdp-mib-07.txt(UNCLASSIFIED)

How are the link quality metrics in float32 format here meant to be
reconciled with the percentage link quality metrics in
draft-ietf-manet-dlep-00 ?

thanks,

Lloyd Wood
http://sat-net.com/L.Wood
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Cole,
Robert G Dr CIV USA [[email-masked]]
Sent: 03 January 2011 14:26
To: [email-masked]
Subject: [manet] FW: I-D Action:draft-ietf-manet-nhdp-mib-07.txt
(UNCLASSIFIED)

Thanks,
Bob

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 3 Jan 2011 16:15:03 +0100

Lloyd,

I agree with Bob. NHDP has been accepted for publication, so we will not
change that. Maybe it might be worth changing the DLEP draft to also use
values between 0.0 and 1.0, but I don't have a strong opinion on that.

Ulrich

On Mon, Jan 3, 2011 at 4:10 PM, Cole, Robert G Dr CIV USA <
[email-masked]> wrote:

> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: <[email-masked]>
Date: Mon, 3 Jan 2011 18:51:25 +0000

Thanks for the context.

DLEP representing the quality metric as a percentage 1-100 is actually pretty sensible, as that's just a single-byte char or integer, and requires less processing power than representing 0.0-1.0 as a fraction in 32-bit float.

What does introducing the increased complexity of a floating-point number actually give as a benefit? Do you really need third or better decimal place? (This is a criticism of NHDP, not the MIB following it.)

On 3 Jan 2011, at 15:15, Ulrich Herberg wrote:

> Lloyd,
> 
> I agree with Bob. NHDP has been accepted for publication, so we will not change that. Maybe it might be worth changing the DLEP draft to also use values between 0.0 and 1.0, but I don't have a strong opinion on that.
> 
> Ulrich
> 
> On Mon, Jan 3, 2011 at 4:10 PM, Cole, Robert G Dr CIV USA <[email-masked]> wrote:

Lloyd Wood
[email-masked]

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 3 Jan 2011 20:04:56 +0100

Lloyd,

as far as I see it, NHDP does not impose any specific representation
of the link quality, such as 32-bit float, it just says that it should
be between 0 and 1. Thus, an implementation could also use a single
octet to store the link quality (and for example encode the link
quality as: value/256, or use an encoding similar to the one in
TimeTLVs). This would depend on the implementation. Since the link
quality values are not exchanged between routers, that should not pose
any interoperability issues.
But maybe one of the NHDP authors could clarify that.

For the MIB, we thought that it is more flexible to use a 32-bit float
instead of a single unsigned byte (and then dividing the value by
256), because it gives more precision, and we need to accommodate all
sort of implementations and link quality values.

Ulrich

---

From: Thomas DuBuisson <[email-masked]>
Date: Mon, 3 Jan 2011 11:16:50 -0800

> What does introducing the increased complexity of a floating-point number actually give as a benefit? Do you really need third or better decimal place? (This is a criticism of NHDP, not the MIB fol…

Thank you for bringing this up, extra dependencies for NHDP negatively
effect OLSRv2 and DYMO which already have many dependencies (NHDP,
NHDP-MIB, PacketBB, PacketBB-Sec, timetlv (5497), jitter (5148),
etc)... it's good to see Ulrich say Float is just a possible
representation.

It's slightly off topic for this list, but related to the point here -
does anyone in IETF-manet have a visual representation of necessary
and optional dependencies, perhaps rooted at OLSRv2 or DYMO?  I find
the prospect of implementing either protocol slightly daunting for a
hobby project, which is unfortunate as AODV and OLSRv1 struck me as
ideal for hobby hacking.

Cheers,
Thomas M. DuBuisson

---

From: "Justin Dean" <[email-masked]>
Date: Mon, 3 Jan 2011 15:03:50 -0500

http://www.ietf.org/proceedings/69/slides/manet-2.pdf

It's a little old and in need of an update but this should be a good
starting point in understanding the document relationships.

Justin

> Of Thomas DuBuisson
> Sent: Monday, January 03, 2011 2:17 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [manet] FW: I-D Action:draft-ietf-manet-nhdp-mib-
> 07.txt(UNCLASSIFIED)
> 
> > DLEP representing the quality metric as a percentage 1-100 is
> actually pretty sensible, as that's just a single-byte char or integer,
> and requires less processing power than representing 0.0-1.0 as a
> fraction in 32-bit float.
> >
> > What does introducing the increased complexity of a floating-point
> number actually give as a benefit? Do you really need third or better
> decimal place? (This is a criticism of NHDP, not the MIB following it.)
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 4 Jan 2011 11:49:01 -0000

Also note that link quality in NHDP is not a metric 
(that term is not used, it's not additive etc.)
Link metric will be an orthogonal concept in OLSRv2.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Communications and Networks Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Cole, Robert G Dr CIV USA
Sent: 03 January 2011 15:10
To: [email-masked]; [email-masked]
Subject: Re: [manet] FW:
I-DAction:draft-ietf-manet-nhdp-mib-07.txt(UNCLASSIFIED)

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.

Lloyd,

Thanks,
Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, January 03, 2011 9:37 AM
To: Cole, Robert G Dr CIV USA; [email-masked]
Subject: RE: [manet] FW: I-D

thanks,

Lloyd Wood

Thanks,
Bob

-----Original Message-----

********************************************************************
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: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 4 Jan 2011 11:57:29 -0000

The use of a 32 bit float is not in NHDP, so your redirected
criticism is also misplaced. NHDP just specifies a value in
the interval 0 to 1, and it's up to an implementer to decide
how precise he needs it. In terms of NHDP itself all that
matters is where the value stands relative to two thresholds.
However the use of a value that may be more precise than
this allows implementers to use the approaches described in
RFC 3626 for OLSR, with whatever precision they require.

as to what is appropriate to a MIB, I am uncertain.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: 03 January 2011 18:51
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [manet] FW: I-D
Action:draft-ietf-manet-nhdp-mib-07.txt(UNCLASSIFIED)

                    *** WARNING ***

Thanks for the context.

DLEP representing the quality metric as a percentage 1-100 is actually
pretty sensible, as that's just a single-byte char or integer, and
requires less processing power than representing 0.0-1.0 as a fraction
in 32-bit float.

On 3 Jan 2011, at 15:15, Ulrich Herberg wrote:

> Lloyd,
> 
> I agree with Bob. NHDP has been accepted for publication, so we will
not change that. Maybe it might be worth changing the DLEP draft to also
use values between 0.0 and 1.0, but I don't have a strong opinion on
that.

Lloyd Wood
[email-masked]

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 4 Jan 2011 12:08:49 -0000

Essentially what are now NHDP and RFCs 5148, 5444 and 5197 all
were originally part of OLSRv2. But NHDP and the packet/message
format were spun into separate documents because others (notably
SMF and DYMO, but now also DLEP) wanted to use them. The other
two needed reference from NHDP and what is now OLSRv2, and so
were spun-off separately to avoid duplication. So OLSRv2
necessarily requires all of these except jitter (RFC 5148)
which is optional (but strongly advised for some MAC layers).

The separation and some generalisation (the "multiplexing"
approach in RFC 5444) has in some ways complicated the
presenattion of OLSRv2, in other ways made it easier. The
same applies to other changes from OLSRv1 to OLSRv2, some
easier (no MIDs or HNAs), some more complicated (for various
reasons).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Justin Dean
Sent: 03 January 2011 20:04
To: 'Thomas DuBuisson'; [email-masked]
Cc: [email-masked]
Subject: Re: [manet] FW:I-D
Action:draft-ietf-manet-nhdp-mib-07.txt(UNCLASSIFIED)

                    *** WARNING ***

Justin

---

From: <[email-masked]>
Date: Tue, 4 Jan 2011 12:11:32 +0000

NHDP's choice of 0 to 1 still has to be represented as a floating point number, so my criticism stands - and holds for OLSR's link quality in section 13 of RFC3626 as well.

Yes, it could be represented less accurately as a compromise with integer division (e.g /256, as mentioned earlier.)

0 to 100 makes some sense as an equivalent for avoiding processing/arithmetic overhead at the receiver - and for then avoiding the ambiguity of translating between different representations of 0 to 1, with varying rounding errors introduced by integer division/different floating points etc.

-----Original Message-----
From: Dearlove, Christopher (UK) [mailto:[email-masked]] 
Sent: 04 January 2011 11:57
To: Wood L Dr (Electronic Eng); [email-masked]
Cc: [email-masked]
Subject: RE: [manet] FW: I-D Action:draft-ietf-manet-nhdp-mib-07.txt(UNCLASSIFIED)
Importance: High

The use of a 32 bit float is not in NHDP, so your redirected criticism is also misplaced. NHDP just specifies a value in the interval 0 to 1, and it's up to an implementer to decide how precise he needs it. In terms of NHDP itself all that matters is where the value stands relative to two thresholds.
However the use of a value that may be more precise than this allows implementers to use the approaches described in RFC 3626 for OLSR, with whatever precision they require.

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 03 January 2011 18:51
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [manet] FW: I-D

                    *** WARNING ***

Thanks for the context.

> I agree with Bob. NHDP has been accepted for publication, so we will
not change that. Maybe it might be worth changing the DLEP draft to also use values between 0.0 and 1.0, but I don't have a strong opinion on that.

Lloyd Wood
[email-masked]

********************************************************************
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: <[email-masked]>
Date: Tue, 4 Jan 2011 12:12:26 +0000

Good point. A metric using units is meaningful; a dimensionless indication of 'quality' rather less so...

-----Original Message-----
From: Dearlove, Christopher (UK) [mailto:[email-masked]] 
Sent: 04 January 2011 11:49
To: Cole, Robert G Dr CIV USA; Wood L Dr (Electronic Eng); [email-masked]
Subject: RE: [manet] FW: I-DAction:draft-ietf-manet-nhdp-mib-07.txt(UNCLASSIFIED)
Importance: High

Also note that link quality in NHDP is not a metric (that term is not used, it's not additive etc.) Link metric will be an orthogonal concept in OLSRv2.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cole, Robert G Dr CIV USA
Sent: 03 January 2011 15:10
To: [email-masked]; [email-masked]
Subject: Re: [manet] FW:

                    *** WARNING ***

Lloyd,

Sorry, but they are not meant to reconcile with draft-ietf-manet-dlep-00, instead there are meant to reconcile with the NHDP draft, i.e.:

Thanks,
Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, January 03, 2011 9:37 AM
To: Cole, Robert G Dr CIV USA; [email-masked]
Subject: RE: [manet] FW: I-D

How are the link quality metrics in float32 format here meant to be reconciled with the percentage link quality metrics in draft-ietf-manet-dlep-00 ?

thanks,

Lloyd Wood

We have updated the NHDP-MIB draft.  It is now in a reasonably final state.  We have addressed the outstanding issues from previous drafts.
We have completed the Notifications Group and cleaned up the issues found by running through 'smilint' (for the most part).  Two issues
remain:

1) this draft needs a thorough review by the WG and by some outside MIB experts.  We'll work with the AD to get some outside the WG reviewers.

2) We have chosen to use a new TC called Float32 for the link quality objects.  Float32 is currently in draft form.  We cannot finalize our draft until the Float32 draft is published. We have been told by the
Float32 authors and the ADs that this draft will move quickly to publication.

Thanks,
Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, January 03, 2011 5:15 AM
To: [email-masked]
Cc: [email-masked]
Subject: [manet] I-D Action:draft-ietf-manet-nhdp-mib-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF.

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.
In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router.  The MIB defined in this memo, denoted NHDP-MIB, also reports state, performance information and notifications.  This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery.

Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.
Classification: UNCLASSIFIED
Caveats: NONE

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 4 Jan 2011 12:24:08 -0000

0 to 1 does not have to be represented as a floating point number.
A fixed point number is just as valid a representation. The 0 to
100 you are proposing is just such a fixed point number, just
you've called the top value 100 rather than 1. As internally
all that matters is comparisons there is no difference, except
you've imposed an arbitrary value of 100.

When you refer to "the receiver" you seem to be under the
misapprehension that the link quality values are transmitted.
they are not. In particular they are not included in a HELLO
message. They are defined in NHDP as limited to the router
they are used on, so there shouldn't be any of the issues
you note (possible effort in converting to float - which is
not specified in NHDP - aside).

(You could collect link quality values across a network. But
those would be meaningless except in comparison with the
specified thresholds, and then all that matters is ordering.)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 04 January 2011 12:12
To: Dearlove, Christopher (UK); [email-masked]
Cc: [email-masked]
Subject: RE: [manet] FW: I-D

                    *** WARNING ***

NHDP's choice of 0 to 1 still has to be represented as a floating point
number, so my criticism stands - and holds for OLSR's link quality in
section 13 of RFC3626 as well.

Yes, it could be represented less accurately as a compromise with
integer division (e.g /256, as mentioned earlier.)

0 to 100 makes some sense as an equivalent for avoiding
processing/arithmetic overhead at the receiver - and for then avoiding
the ambiguity of translating between different representations of 0 to
1, with varying rounding errors introduced by integer division/different
floating points etc.

-----Original Message-----
From: Dearlove, Christopher (UK) [mailto:[email-masked]] 
Sent: 04 January 2011 11:57
To: Wood L Dr (Electronic Eng); [email-masked]
Cc: [email-masked]
Subject: RE: [manet] FW: I-D

The use of a 32 bit float is not in NHDP, so your redirected criticism
is also misplaced. NHDP just specifies a value in the interval 0 to 1,
and it's up to an implementer to decide how precise he needs it. In
terms of NHDP itself all that matters is where the value stands relative
to two thresholds.
However the use of a value that may be more precise than this allows
implementers to use the approaches described in RFC 3626 for OLSR, with
whatever precision they require.

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

-----Original Message-----

                    *** WARNING ***

Thanks for the context.

Lloyd Wood
[email-masked]

---

From: "Rogge Henning" <[email-masked]>
Date: Tue, 4 Jan 2011 13:24:51 +0100

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] 
> 
> NHDP's choice of 0 to 1 still has to be represented as a 
> floating point number, so my criticism stands - and holds for 
> OLSR's link quality in section 13 of RFC3626 as well.
> 
> Yes, it could be represented less accurately as a compromise 
> with integer division (e.g /256, as mentioned earlier.)
> 
> processing/arithmetic overhead at the receiver - and for then 
> avoiding the ambiguity of translating between different 
> representations of 0 to 1, with varying rounding errors 
> introduced by integer division/different floating points etc.

If I remember the "link quality" in NHDP right, it's just an internal value
calculated to decide when a link should be declared "active". I don't think
it is ever transmitted to other nodes, so both the range or representation
of this value it totally implementation specific without breaking
compatiblity.

You can use a float between 0 and 1, you can use integer arithmetic between
0 and any fixed number or even something else, it doesn't really matter as
long as your link hysteresis algorithm behaves well.

In some cases you can even use the OLSRv2 link metric to trigger your
hysteresis.

Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für 
Kommunikation, Informationsverarbeitung und Ergonomie FKIE 
Kommunikationssysteme (KOM) Neuenahrer Straße 20, 53343 Wachtberg, 
Germany Telefon +49 228 9435-961,   Fax +49 228 9435 685 
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 

> However the use of a value that may be more precise than this 
> allows implementers to use the approaches described in RFC 
> 3626 for OLSR, with whatever precision they require.
> 
> Registered Office: Warwick House, PO Box 87, Farnborough 
> Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered 
> in England & Wales No: 1996687
> 
> actually pretty sensible, as that's just a single-byte char 
> or integer, and requires less processing power than 
> representing 0.0-1.0 as a fraction in 32-bit float.
> 
> What does introducing the increased complexity of a 
> floating-point number actually give as a benefit? Do you 
> really need third or better decimal place? (This is a 
> criticism of NHDP, not the MIB following it.)
> 
> not change that. Maybe it might be worth changing the DLEP 
> draft to also use values between 0.0 and 1.0, but I don't 
> have a strong opinion on that.
> > 
> > Ulrich
> > 
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > This draft is a work item of the Mobile Ad-hoc Networks 
> Working Group
> of
> > the IETF.
> > 
> > 
> 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: <[email-masked]>
Date: Tue, 4 Jan 2011 12:36:43 +0000

Link quality values are transmitted and collected across a network in
RFC5578
http://tools.ietf.org/html/draft-ietf-manet-dlep-00

and, of course, via SNMP or similar for the MIB information that started this thread. If the information is meaningless, why include it in a MIB?

-----Original Message-----
From: Dearlove, Christopher (UK) [mailto:[email-masked]] 
Sent: 04 January 2011 12:24
To: Wood L Dr (Electronic Eng); [email-masked]
Cc: [email-masked]
Subject: RE: [manet] FW: I-D Action:draft-ietf-manet-nhdp-mib-07.txt(UNCLASSIFIED)
Importance: High

0 to 1 does not have to be represented as a floating point number.
A fixed point number is just as valid a representation. The 0 to 100 you are proposing is just such a fixed point number, just you've called the top value 100 rather than 1. As internally all that matters is comparisons there is no difference, except you've imposed an arbitrary value of 100.

When you refer to "the receiver" you seem to be under the misapprehension that the link quality values are transmitted.
they are not. In particular they are not included in a HELLO message. They are defined in NHDP as limited to the router they are used on, so there shouldn't be any of the issues you note (possible effort in converting to float - which is not specified in NHDP - aside).

(You could collect link quality values across a network. But those would be meaningless except in comparison with the specified thresholds, and then all that matters is ordering.)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 04 January 2011 12:12
To: Dearlove, Christopher (UK); [email-masked]
Cc: [email-masked]
Subject: RE: [manet] FW: I-D

                    *** WARNING ***

-----Original Message-----

                    *** WARNING ***

Thanks for the context.

Lloyd Wood
[email-masked]

---

From: "Rogge Henning" <[email-masked]>
Date: Tue, 4 Jan 2011 13:45:17 +0100

> Von: [email-masked]
> and, of course, via SNMP or similar for the MIB information 
> that started this thread. If the information is meaningless, 
> why include it in a MIB?

I think there is a lot of confusion about "link quality" and "link cost",
especially because both of them can (but don't need to) be determined by
similar algorithms/protocols (ETX for example).

The link quality of NHDP is used as an internal value to trigger the link
hysteresis. Its a way to prevent a link going "on" and "off" very quickly.
It's not designed to be transmitted to other NHDP nodes for processing.

The link cost of (the comming) OLSRv2 is a routing metric that is used to
calculate best paths through the mesh network.

Yes, you can read the link metric value for remote monitoring, but this is
not part of the NHDP protocol. Reading it through SNMP from a MIB is a way
to learn why a certain link of NHDP is up/down, nothing more.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 4 Jan 2011 13:11:38 -0000

As has already been noted, DLEP's link quality is not the
same as NHDP's link quality. They have different purposes.

I think you've gone too far in "meaningless". Locally, but
not (in general, but a specific network may differ) globally
meaningful. Management may be local.

But I didn't write the MIB, so I leave that to those who did.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 04 January 2011 12:37
To: Dearlove, Christopher (UK); [email-masked]
Cc: [email-masked]
Subject: RE: [manet] FW: I-D

                    *** WARNING ***

and, of course, via SNMP or similar for the MIB information that started
this thread. If the information is meaningless, why include it in a MIB?

-----Original Message-----
From: Dearlove, Christopher (UK) [mailto:[email-masked]] 
Sent: 04 January 2011 12:24
To: Wood L Dr (Electronic Eng); [email-masked]
Cc: [email-masked]
Subject: RE: [manet] FW: I-D

0 to 1 does not have to be represented as a floating point number.
A fixed point number is just as valid a representation. The 0 to 100 you
are proposing is just such a fixed point number, just you've called the
top value 100 rather than 1. As internally all that matters is
comparisons there is no difference, except you've imposed an arbitrary
value of 100.

When you refer to "the receiver" you seem to be under the
misapprehension that the link quality values are transmitted.
they are not. In particular they are not included in a HELLO message.
They are defined in NHDP as limited to the router they are used on, so
there shouldn't be any of the issues you note (possible effort in
converting to float - which is not specified in NHDP - aside).

(You could collect link quality values across a network. But those would
be meaningless except in comparison with the specified thresholds, and
then all that matters is ordering.)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 04 January 2011 12:12
To: Dearlove, Christopher (UK); [email-masked]
Cc: [email-masked]
Subject: RE: [manet] FW: I-D

                    *** WARNING ***

-----Original Message-----

                    *** WARNING ***

Thanks for the context.

Lloyd Wood
[email-masked]

---

From: Bo Berry <[email-masked]>
Date: Tue, 4 Jan 2011 08:13:01 -0500

To help clarify the confusion, RFC5578 defines radio link metrics 
that can be used by the routing protocols to compute a link cost. 
The equation used to compute the link cost from the metrics is
routing protocol dependent. 

-Bo

> to learn why a certain link of NHDP is up/down, nothing more.

----
[email-masked]
This email may contain confidential and privileged material for the sole use of the intended recipient. This email may contain information that is protected by NDA. Any unauthorized review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 4 Jan 2011 13:15:04 -0000

I would nit-pick what Henning wrote slightly. The hysteresis
is there to stop link quality flapping the link on and off.
But that leaves the question why have the link quality at all?

One answer to that is that it is extremely useful when, for
example, running NHDP over IEEE 802.11 to solve the "grey zone"
problem (difference between broadcast and unicast data rates
and ranges).

-----Original Message-----
From: Rogge Henning [mailto:[email-masked]] 
Sent: 04 January 2011 12:45
To: [email-masked]; Dearlove, Christopher (UK); [email-masked]
Cc: [email-masked]
Subject: AW: [manet] FW: I-D Action:draft-ietf-manet-nhdp-mib-07.txt(UNCLASSIFIED)

Henning Rogge

---

From: Bo Berry <[email-masked]>
Date: Tue, 4 Jan 2011 08:15:46 -0500

note, DLEP followed the RFC 5578 link metric model.
-Bo

----
[email-masked]

---

From: "Rogge Henning" <[email-masked]>
Date: Tue, 4 Jan 2011 14:23:29 +0100

> Von: Dearlove, Christopher (UK) 
> 
Hysteresis is there to stop link flapping... it can be implemented by using
a "link quality value".
(I don't think I said it's to prevent the link quality value from flapping)

> problem (difference between broadcast and unicast data rates 
Yes, it can also be used for preventing "too bad" links from being
considered "up", thats right.

Either way, link quality and link cost are similar concepts, just used for
different things. Most input that can be used for a good link quality
estimation (and a good link hysteresis) could be used for calculating a link
cost for routing too. You could even use a multiplicative dijkstra directly
on the link quality values for routing.

Henning Rogge

---

From: "Rogge Henning" <[email-masked]>
Date: Tue, 4 Jan 2011 14:25:22 +0100

> Von: Bo Berry

Maybe it would be a good idea to choose a better metric range than 0-100.
The value is much too small for a good link quality/cost metric unless it's
always a floating point value. OLSRv2 will have link metric costs from 0/1
to 2^24-1.

Henning Rogge

---

From: Bo Berry <[email-masked]>
Date: Tue, 4 Jan 2011 09:01:35 -0500

The relative link quality (RLQ) metric is there to allow radios
to influence the resulting link cost independent of the radio's
wave form.  We have found this metric (0-100) very useful given 
the number of different radios & wave forms. RLQ provides an
abstraction from the radio.

The equations and the heuristics to avoid flapping and flooding
is defined/handled beyond the radio link metrics.

An example of the link cost equation for OSPFv3 MANET can be found
   http://sourceforge.net/projects/dleptools/
Look for sim_ospf_config_syntax.readme as an example. 

Another router-radio protocol defining similalr radio link metrics
can be found at the link below. Understand a draft is forth coming. 
   http://sourceforge.net/projects/r2cptools/

For RFC 5578 (RC 4938)
   http://sourceforge.net/projects/rfc4938/

-Bo

----
[email-masked]