Subject: [manet] (DLEP) Relative Link Quality and routing metrics

From: Henning Rogge <[email-masked]>
Date: Fri, 20 Apr 2018 10:00:57 +0200

Hello,

I am currently looking for a good way to integrate the RLQ value of
DLEP into a cost based routing metric, e.g. DAT. But I am not sure how
to do this...

has anyone here good experience using RLQ and maybe an advise how
"hard" you should penalize a link with a RLQ less than 100?

Henning Rogge

---

From: Rick Taylor <[email-masked]>
Date: Fri, 20 Apr 2018 11:02:20 +0000

I have always suggested that RLQ should be a measure of how hard the
modem is working to maintain the link, i.e. the higher the RLQ, the
more stable the link is, and a low RLQ indicates that the link may well
radically change metrics, or dissapear soon.

One can imagine a sophisticated modem maintiaining a link in very
adverse conditions, reporting a low RLQ, but otherwise good metrics.

Whether RLQ is a good metric to use as a route cost is a more difficult
question.  I've always been of the opinion that RLQ and Resources make
a good tie-breakers, but CDR and Latency make better 'primary' metrics.

Hope that helps a little?

Rick

On Fri, 2018-04-20 at 10:00 +0200, Henning Rogge wrote:
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Henning Rogge <[email-masked]>
Date: Fri, 20 Apr 2018 13:05:09 +0200

Sorry,

but this does not help...

lets say I estimate the link cost for a link (based on data-rate) to be 1000...

if the radio reports RLQ=100, I would keep the 1000... but how do I
modify it for a RLQ of 80... or 50... or 1?

If I cannot integrate the value into the cost metric, I have no use
for the value. Unfortunately it is often the ONLY value the radio
reports.

Henning

---

From: Teco Boot <[email-masked]>
Date: Fri, 20 Apr 2018 14:02:06 +0200

Assume two types of radio's.

First one is 802.11 type of radio. It has rate adaption and retry statistics. It reports CDR, this is the *good-put* the radio would have taking all the airtime. In this case, utility of RLQ is low.
But when the radio reports only the average or most recent *TX rate*, the RLQ can be of value. At higher rates, RLQ would be 100, because rate adaption takes care of variation in link budget. But at lower rates and high retry ration (and backoff timers... RLQ would provide kind of fast DAT, when RLQ is based on RSSI and/or retry counters.

Second one is more like a legacy data-radio. It has fixed rate, fixed TX power and it is often used for broadcast, i.e. the messages are addressed to all receivers. For the sender, RLQ is always 100, it doesn't mater if there is any receiver. In military, it is called fire and forget. But for receivers, there is a variation in metrics. Nearby nodes would receive all packets, nodes far from the sender would receive nothing. Somewhere between, nodes would receive part of the messages sent by a node. This is called the grey zone. Reported metrics could be loss ratio, RSSI, Eb/No or RLQ. Here, RLQ could be a compound value, based on the mentioned metrics.

Because RLQ would be very specific to the type of radio, you could design some kind of plugin or profile mechanism, where an administrator could select a calculation model.

I did some work using RSSI to RLQ mapping, the router used that to calculate the routing protocol metric. I used a lookup table. Tuning the table is tough, different conditions need different mapping.

Teco

> Op 20 apr. 2018, om 13:05 heeft Henning Rogge <[email-masked]> het volgende geschreven:
> 
> Sorry,
>

---

From: Rick Taylor <[email-masked]>
Date: Fri, 20 Apr 2018 12:55:34 +0000

Inline...

> for the value. Unfortunately it is often the ONLY value the radio

I would suggest you return to the radio vendor and request they support
more metrics than RLQ in updates.

If they are DLEP compliant, then they MUST support MDR,CDR,Latency per
session, and you could modify the session-wide CDR values by the RLQ in
some non-uniform manner.

Rick

> > > DLEP into a cost based routing metric, e.g. DAT. But I am not
> > > sure
> > > how
> > > to do this...
> > >

---

From: Stan Ratliff <[email-masked]>
Date: Fri, 20 Apr 2018 15:06:11 -0400

Henning,

> modify it for a RLQ of 80... or 50... or 1?

What we did at Cisco was to add to the route cost, based on how much RLQ
had dropped. A document on the route cost calculations (for OSPF) is at
https://www.cisco.com/c/en/us/td/docs/ios/12_4t/ip_mobility/configuration/guide/ip_manet.html
Look for Section "OSPF Cost Calculation for VMI Interfaces". You'll see we
used a hard-coded '65535' in the calcuations, IIRC, (it's been a few
years), that's the maximum OSPF route cost.

My guess is that this specific equation won't fit your needs, but it might
serve as a template for you.

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Fri, 20 Apr 2018 21:18:24 +0200

> session, and you could modify the session-wide CDR values by the RLQ in

We are working on extending an existing radio with a DLEP adapter...
so asking for other metric data is difficult. ;)

On Fri, Apr 20, 2018 at 9:06 PM, Stan Ratliff <[email-masked]> wrote:
> Henning,
>
> What we did at Cisco was to add to the route cost, based on how much RLQ had
> dropped. A document on the route cost calculations (for OSPF) is at
> used a hard-coded '65535' in the calcuations, IIRC, (it's been a few years),
> that's the maximum OSPF route cost.

Interesting... yes, this is helpful.

It is also funny how complicated some part of the formula got because
of integer arithmetic (by multiplying most of the things with 100).

Henning

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 30 Apr 2018 23:05:17 +0200

> Interesting... yes, this is helpful.

It looks somewhat random to me.

-- Juliusz