Subject: [manet] NHDP - Link Quality measurement

From: "Teco Boot" <[email-masked]>
Date: Wed, 12 Dec 2007 11:27:01 +0100

On NHDP:
===
14.4.  Updating Link Quality

   A node MAY update link quality based on any information available to
   it.  Particular cases that MAY be used include:

   o  Information from the link layer, such as signal to noise ratio.

   o  Receipt or loss of packets.  If packets include a packet sequence
      number as defined in [1], then packets on a link SHOULD have
      sequential packet sequence numbers, whether or not they include
      HELLO messages.  Link quality can be updated when a packet is
      received based on, for example, whether the last N out of M
      packets on the link were received, or a "leaky integrator"
      tracking packets.

   o  Receipt or loss of HELLO messages.  If the maximum interval
      between HELLO messages is known (such as by inclusion of a message
      TLV with Type == INTERVAL_TIME, as defined in [3], in HELLO
      messages) then the loss of HELLO messages can be determined
      without the need to receive a HELLO message.  Note that if this
      case is combined with the previous case then care must be taken to
      avoid "double counting" a lost HELLO message in a lost packet
===

Are we sure we want to use packetbb packet <pkt-seq-num>?
I can imagine cases that this is invalid. Packets do not require a packet
header or <pkt-seq-num>. Maybe sequence number is incremented for those
packets. Or sequence number is randomized for security reasons. Or packetbb
is being used for a protocol sending with another destination address or
port number or lower layer protocol.
By the way, the specification: 
      If packets include a packet sequence
      number as defined in [1], then packets on a link SHOULD have
      sequential packet sequence numbers, whether or not they include
      HELLO messages.
is not written down in packetbb.

I think information from the link layer is far more important. Other
available L2 information: statistics on number of retransmits and transmit
failed indication for unicast traffic (sender) and the 802.11 MAC Header
Retry field also for unicast traffic (receiver).
This information is also used by data rate selection algorithm (if used),
data rates higher than the minimum is a good indication that the link
quality is OK.

The NHDP link quality is for the bi-directional link, where both nodes may
use the link quality mechanism. In the current text, the receiver side link
quality is described. I think both nodes may use bi-directional link quality
measurement.

Teco.

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

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 12 Dec 2007 10:43:27 -0000

Comments below with >>> 

-----Original Message-----
From: Teco Boot [mailto:[email-masked]] 
Sent: 12 December 2007 10:27
To: 'Thomas Clausen'; Dearlove, Christopher (UK); 'Justin Dean'
Cc: [email-masked]
Subject: NHDP - Link Quality measurement

               *** WARNING ***

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

On NHDP:
===

>>> No, that's why it's a MAY.

I can imagine cases that this is invalid. Packets do not require a
packet
packets. Or sequence number is randomized for security reasons. Or
packetbb

>>> That made me look back in the history. It did (although not in those
>>> exact words of course) but it got removed at one point. Need to
think
>>> about that. But not including a packet sequence number is not in
itself
>>> a problem if you only increment the number when actually used. (It
may
>>> make the mechanism less useful, but not broken.)

I think information from the link layer is far more important.

>>> No disagreement here. But sometimes you just can't get what you
want,
>>> and an alternative is needed.

Other
available L2 information: statistics on number of retransmits and
transmit
failed indication for unicast traffic (sender) and the 802.11 MAC Header
Retry field also for unicast traffic (receiver).
This information is also used by data rate selection algorithm (if
used),
data rates higher than the minimum is a good indication that the link
quality is OK.

>>> NHDP isn't designed to run only over 802.11. And even when running
>>> over 802.11, different drivers and OSes make different amounts of
>>> information available.

The NHDP link quality is for the bi-directional link, where both nodes
may
use the link quality mechanism. In the current text, the receiver side
link
quality is described. I think both nodes may use bi-directional link
quality
measurement.

>>> To use bidirectional information you would need to transfer it. And
>>> that is not what this is about. Receiver information is what NHDP
>>> works on in general (do you receive HELLO messages?).
Bidirectionality
>>> is established by the (implicit) HELLO handshaking both agreeing
that
>>> the link is usable in their direction.

********************************************************************
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: "Teco Boot" <[email-masked]>
Date: Wed, 12 Dec 2007 12:07:37 +0100

> >>> the link is usable in their direction.
[Teco:] 
Chris, I agree on your comments. But what I meant is that a node may use L2
feedback on transmissions also, when this is available. This could speed up
detecting a broken link. When problems with unicast packet transfer occur,
this information can be used to qualify link quality. Usage with care, of
course. And there is dependency on unicast traffic.