Subject: Re: [manet] Link metric drafts

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 1 Mar 2010 09:51:41 -0000

> More important, transmitter decides data rate, modulation, Tx power
etc.

The Tx may decide, but the Rx also knows the data rate and modulation.
The Tx power isn't important, what's important is the signal to noise
(and interference) ratio, and it's the Rx that knows that.

I will just note that we didn't pick this out of a hat, I recall
discussions that were agreed on this, and I haven't seen any reason
so far to suggest a change. (There are minor Tx advantages, but these
are things that can be handled at the Rx. There are major Rx advantages
that can't be handled at the Tx without extra signalling.)

>My experience with link metrics without dampening and hysteresis aren't

>that good. Could be dependent in implementation, timers, scenario's
etc.

I'm not sure why you are raising this, no one has disagreed. The draft
points out that changing a metric is a topology change, and like other
topology changes, shouldn't be too fast.

Having such mechanisms at multiple places (radio driver, MANET protocol,

multiple devices) makes things complex. I suggest sending all available
information to a single, well defined point. Here, the metric
calculation
takes place, including dampening and hysteresis. Then, the signaling
protocol(s) to distribute the outcome.

>> I don't like the idea someone else specifies what I should do.
>
>OLSR is a cooperative protocol. Lots of stuff in it causes node A
>to force node B to do stuff (the importance of MPR selectors means
>that I require you to relay in particular). I don't see that as
>something new.

Not new at all. In routing protocols, nodes must forward routing
messages.
And forward packets. But a router with metric support can decide to
increase a link metric, which would result in fewer packets to forward.
(I guess you respond with rat race scenario).

> More important: let's face this one:

This is no different to problems with link breakages not being
propagated. And as links metrics are used non-locally and sent
in TC messages there is always a possible transient problem if
messages get lost, regardless of whether decided by the Tx or Rx.

********************************************************************
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: Mon, 1 Mar 2010 09:54:14 -0000

> I completely agree to this, dampening/hysteresis should be done before
the 
> linkcost value is flooded into the network.

There needs to be a metric as soon as there is a link.
Sometimes that is immediately possible. When not, the
safe thing is to set the metric high, so the link will
only be used as a last resort, then reduce it when a
better estimate is available.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 1 Mar 2010 10:00:47 -0000

> b) Current implementation is blocking for enhancements, 
>    for example use available better link metrics, e.g. RSSI.

I don't follow that at all. The OLSRv2 draft will have an
agnostic view of metrics, as long as signalled properly.
The ETX metric isn't simply a metric, it's a protocol
extension that creates a metric. But OLSRv2 won't care
about that, it will just use the netric. There will be
(if this draft is accepted) a coupling between a particular
metric type number and this ETX protocol, but if not using
either you could define another type number for RSSI or
whatever.

---

From: Marcello Caleffi <[email-masked]>
Date: Mon, 1 Mar 2010 16:20:36 +0100

> better estimate is available.

I agree with Cris. Let us use first well estimated links, but if we are in trouble let us use unknown links.
However, it is necessary to be sure that the lack of well estimation on that link be not caused by congestion.

Marcello

---

From: Teco Boot <[email-masked]>
Date: Wed, 3 Mar 2010 15:49:00 +0100

> either you could define another type number for RSSI or

My comment was on olsrd and ETX implementation. It is hard to implement RSSI or whatever in a compatible way. The ETX values are sent all over the place, and each node calculates the link metrics for all links.

I suggest not to distribute ETX specific info, not even in HELLO. Instead, the receiving node sends a dimensionless metric, which is calculated from missed packets, RSSI, LQ, rate etc. This would make thinks compatible. Having more specific info by sending metric TLVs is fine, but better without.

Your OLSRv2 metric draft is OK (but we don't agree on using sending_node or receiving_node metric, and I have more thoughts on it).
The ETX draft has potential compatibility issues.

Regards, Teco.