Subject: Re: [manet] DLEP: request for new metric type

From: Teco Boot <[email-masked]>
Date: Mon, 2 Apr 2012 06:56:36 +0200

Op 31 mrt. 2012, om 09:46 heeft Henning Rogge het volgende geschreven:

> On Fri, Mar 30, 2012 at 18:38, Teco Boot <[email-masked]> wrote:
>> Stan,
>> 
>> Seen the discussion on hop-count and probably lots of other
>> nice to haves, an employee of a random router vender would
>> easily get crazy to get all of this in a useful metric for
>> the routing protocols.
>> 
>> I suggest to define a new metric type, to be used by modems,
>> to provide a dimensionless value that is used directly in the
>> routing protocol. After a bit of discussion, we have a nice
>> outcome of a 12-bit compressed form of a link metric OLSRv2.
>> http://tools.ietf.org/html/draft-ietf-manet-olsrv2-14#section-6.2
>> 
>> You may have a need for a 16-bit uncompressed dimensionless value
>> for OSPF. You could opt for a / 256 of the decompressed value
>> or go for another metric type. Important: OSPF needs the metric
>> for outgoing traffic, OLSR for incoming traffic (OLSR transfers
>> it to neighbor with hello).
>> 
>> You could use the Neighbor Incoming / Outgoing Metric bits, you
>> have the 4-bit placeholder already.
> If Layer-2 data is available, it should be exported in "raw" format by
> the DLEP service/server. Especially data that cannot be easily
> calculated by the connected computer like "Throughput" (real one, not
> just hardware transmission speed), Transmission loss and transmission
> attempts.
The real throughput is a nice metric. But it is not "raw", it is
computed from modulation data rate, loss ratio and set of delays.
CDR could be used for throughput (at sender).

> And for Radios we definitely need Frequency and Bandwidth (width of
> the radio channel in Hz). These two values are also interesting to use
> in the "request link characteristic" message to reconfigure a radio.
At the end we have a complete configuration tool. Is that the target?

>> With MAC address-block TLVs, assuming a 6-byte MAC address with
>> first 3 bytes mostly being equivalent, the space per neighbor
>> would be 5 bytes. Not that bad. But to make use of this, you
>> may need to have repeatedly having send this info instead of
>> having a reliable transport inside DLEP. This needs validity
>> timers, so it is not a minor change.
> 
> You mean space including your dimensionless metric TLV?
Yes.

> Something different, is the addition of IPs to the DLEP messages
> really a common usecase? DLEP defines the radio to be a layer-2 bridge
> to the ethernet (most likely VLAN tagged to separate it from the
> control stream), so the radio/modem does not need any IP address
> except for some linklocal one on the control interface.
I would use non-linklocals also, for managing the radio/modem.

Teco

> 
> Henning Rogge
> -- 
> Steven Hawkings about cosmic inflation: "An increase of billions of
> billions of percent in a tiny fraction of a second. Of course, that
> was before the present government."

---

From: "Rick Taylor" <[email-masked]>
Date: Mon, 2 Apr 2012 11:20:54 +0100

Sorry to top post, but I want to summarise my responses to several
threads

1) Teco, The metric you propose is a routing metric, and DLEP is about
reporting link metrics.  OLSR and other routing protocols can/will
generate your metric for their own use.  It is not the business of the
radio to do this.

2) But, Teco's metric does highlight one missing piece of DLEP metric
TLV's: No direction indication. Can we have some flags with each metric
indicating direction (up/downstream) and the 'rawness' of the metric
(smoothed, live, ...) 

3) IP addressing is not really needed when DLEP refers to neighbours.
Layer 2 MAC will identify neighbours correctly, and I would recommend
using it with RFC5444 address blocks.  Any associated layer 3 addresses
are already covered by the DLEP address TLVs, or can be discovered by
routers (ARP etc)

4) Hop-count - As a number of people have said, smart layer 2 meshing
and layer 3 routing will fight if the layer 3 routers cannot discover
the connectivity between radio devices.  There must be some mechanism in
DLEP for a smart radio mesh to describe the topology in enough detail to
prevent a layer 3 routing protocol from making incorrect decisions about
connectivity.  Ideas include a hop-count TLV or a Via TLV for
neighbours.  This information is about connectivity, not about 'metrics'
or 'routes'.

Rick Taylor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Teco Boot
Sent: 02 April 2012 05:57
To: Henning Rogge
Cc: [email-masked] IETF; Stan Ratliff (sratliff)
Subject: Re: [manet] DLEP: request for new metric type

Yes.

Teco

> Henning Rogge

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

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 2 Apr 2012 11:45:49 +0100

Teco
> we have a nice 

Because this detail is not fully explained in any published document (it
should be in an update of the metrics draft to be converted to a
rationale document) I'd like to provide a thumbnail sketch as to how
this came about.

In OLSRv2, the 12 bits have 4 more bits added to them that indicate the
nature of the metric. It might therefore be supposed that we picked 12
bits so as to fit into two octets.

Actually, no. That this happened was a very fortuitous result. I don't
know what we would have done otherwise, but never had to find out.

The 12 bits arose from that we had a modified mantissa/exponent form
that met people's request for one that started 1,2,3, ... The actual
pattern (possibly hidden in the maths) is 2^m increments by 1, then 2^m
increments by 2, then 2^m increments by 4 etc., for 2^e sets of
increments, where e is the number of "exponent" bits, and m is the
number of "mantissa" bits (quotes because these are not a true
mantissa/exponent form, but are close to one).

Now to pick m and e. And they were picked to satisfy the desire for a
range of values that spanned a range up to (just under) 2^24. Why 2^24?
Because largest possible route metric is summing 255 of these link
metric values, and 2^24 then keeps route metrics less than 2^32. And
m=8, e=4 works for this, which is 12 bits.

(Incidentally if anyone wants to check the maths has these properties,
that's what WGLCs are for.)

********************************************************************
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: Stan Ratliff <[email-masked]>
Date: Mon, 2 Apr 2012 11:41:44 -0400

Teco,

Hmmmm...... a dimensionless value used in the routing protocol.....    
Please see "Radio Link Quality", currently in the DLEP spec.

Regards,
Stan

---

From: Teco Boot <[email-masked]>
Date: Mon, 2 Apr 2012 22:04:07 +0200

Op 2 apr. 2012, om 17:41 heeft Stan Ratliff het volgende geschreven:

> Teco,
> 
> Hmmmm...... a dimensionless value used in the routing protocol.....   Please see "Radio Link Quality", currently in the DLEP spec.

Echo hmmmmm...
I think there are semantics for this metric. And I dislike the limits on its range.

More thoughts: there could be modem devices that are very capable to provide the link metric for MANET routing. For example, the device could run a MANET protocol itself, maybe at sub-IP layer (could be OLSRv2 derivate). It would be nice having the (multi-L2-hop-path) link costs available at L3.

Another deployment model is plug&play interfaces (e.g. USB wifi stick), where DLEP manages this device. Then we need the rich set of attributes, including channel/power/ssid/keys etc. as Henning mentioned. 

Teco

---

From: "Rick Taylor" <[email-masked]>
Date: Tue, 3 Apr 2012 09:44:44 +0100

> I think there are semantics for this metric. And I dislike the limits
on
> its range.

I take Stan's point that RLQ is a catch-all, I would propose
rationalising the set of standard metrics to include a 32bit
dimensionless 'value', as well as some SHOULD support metrics, and
specify default handling for vendor-specific metric TLVs.

I have some thoughts about 'namespacing' the sub-TLVs, particularly for
metrics, that I will post separately.

> More thoughts: there could be modem devices that are very capable to
> provide the link metric for MANET routing. For example, the device
could
> run a MANET protocol itself, maybe at sub-IP layer (could be OLSRv2
> derivate). It would be nice having the (multi-L2-hop-path) link costs
> available at L3.

Even if the modems were performing layer 2 routing via an OLSRv2
derivative, there is still a need for the layer 3 routing to be told
about the connectivity of links via DLEP to prevent fighting,
particularly if the modems are running an advanced protocol.

> Another deployment model is plug&play interfaces (e.g. USB wifi
stick),
> where DLEP manages this device. Then we need the rich set of
attributes,
> including channel/power/ssid/keys etc. as Henning mentioned.

Yes, see my comment above.

Rick Taylor

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 3 Apr 2012 10:00:39 +0100

I think a 24 bit value is better than a 32 bit value if this is to be used as a link metric by a routing algorithm (not the only possible case of course) as you will have to accumulate them along routes. Admittedly the likelihood of the worst case (255 hops with maximal metric each) is low, but the ability to add up within a 32 bit total without having to perform any form of overflow checks is useful.

An uncompressed 3 octet value could be later converted to another representation (e.g. as in OLSRv2) easily.

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

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 Rick Taylor
Sent: 03 April 2012 09:45
To: Teco Boot; Stan Ratliff
Cc: [email-masked]
Subject: Re: [manet] DLEP: request for new metric type

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

on

could

stick),
attributes,

Rick Taylor

---

From: "Rick Taylor" <[email-masked]>
Date: Tue, 3 Apr 2012 10:15:38 +0100

> 
> I think a 24 bit value is better than a 32 bit value if this is to be used
> as a link metric by a routing algorithm (not the only possible case of
> course) as you will have to accumulate them along routes. Admittedly the
> likelihood of the worst case (255 hops with maximal metric each) is low,
> but the ability to add up within a 32 bit total without having to perform
> any form of overflow checks is useful.

I am not proposing that RLQ be used as a routing metric, only as a metric that is available via DLEP. 24/32/64bit I don't really care, I was just agreeing with Teco that a [0..100] seemed a little limited, but in retrospect, as Stan pointed out, it's just a number with no associated semantic information.  Really I would like RLQ dropped as I would prefer DLEP to only report live data concerning the links: latency, bandwidth, USB info, ssid, etc.  Anything that can be calculated or is dimensionless should generated by the consumer of the DLEP metrics.

I would also like to separate the RLQ from any TLV describing topology.  I understand that in OLSRv2, the single metric encapsulates the hop-count information, but pushing that through DLEP as RLQ and changing the meaning of RLQ to "OLSRv2 metric" is just confusing.

I am keen to underline the point that DLEP is about informing layer 3 processes of layer 2 metrics and connectivity.  Whether the layer 3 processes perform routing or just draw a pretty graph with coloured lines is irrelevant to DLEP.

Rick Taylor

> 
> An uncompressed 3 octet value could be later converted to another
> representation (e.g. as in OLSRv2) easily.
> 
> --
> Christopher Dearlove

---

From: Henning Rogge <[email-masked]>
Date: Tue, 03 Apr 2012 11:18:43 +0200

> An uncompressed 3 octet value could be later converted to another representation (e.g. as in OLSRv2) easily.

I agree, if the DLEP-server already creates some "relative estimate" of 
the link quality, giving it the same range (24 bits) than the OLSRv2 
routing metric is a good idea.

Of course its still the decision of the routing protocol how it use the 
different values delivered by DLEP to construct its metric.

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

---

From: Henning Rogge <[email-masked]>
Date: Tue, 03 Apr 2012 11:24:31 +0200

> CDR could be used for throughput (at sender).

The real throughput can be difficult to calculate on the router, even 
with access to statistics on the radio. But its often much easier to 
calculate with the rate-control algorithm on a radio. Thats why an 
(optional) TLV for throughput would be a good idea. If the information 
is available on the radio, DLEP should share it with the clients.

> At the end we have a complete configuration tool. Is that the target?

Frequency and (radio-)bandwidth is also interesting for calculating 
collision groups of radio interfaces. Even if we decide to drop the 
"Request Link Characteristic" message, this data is useful for a routing 
agent.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 3 Apr 2012 10:27:24 +0100

I wouldn't say that giving it the same range as OLSRv2 is what matters, OLSRv2 is just one protocol. Rather that there's logic in why OLSRv2 picked 24 bits (when uncompressed) and that logic may (I put it no stronger) be worth considering as an option in DLEP. All the physically relevant information is of course also important in many contexts.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 03 April 2012 10:19
To: [email-masked]
Subject: Re: [manet] DLEP: request for new metric type

Henning Rogge