Subject: [manet] Metric TLV for AODVv2

From: Victoria Mercieca <[email-masked]>
Date: Fri, 15 Apr 2016 21:31:19 +0100

Hi everyone,

The AODVv2 author team are discussing, amongst other things, our metric
TLV, and would appreciate your input. Currently our draft defines a new
PATH_METRIC TLV, where we use the type extension to indicate MetricType and
the value length varies dependent on metric type.

There have been a couple of suggestions of alternatives.

1) Recent suggestions that metric fields in general should use 32 bits. If
we go ahead with this, we alter our current metric TLV very slightly, still
using Type, Type Extension for indicating MetricType, Length, and Value
fields, but with length set to 32 bits for every metric type. 32 bits seems
like overkill for a hopcount metric, and suitability for other metric types
may vary.

2) Other suggestions that we re-use the LINK_METRIC TLV used by OLSRv2. It
has a value length of 16 bits total. If we do use that, I believe we could
still use extension type to indicate MetricType like we are currently with
our own TLV. I don't believe its a big change to the AODVv2 draft either. We
would need define how to set the 'kind' and 'direction' bits for AODVv2
metrics, since ours are accumulated route metrics, rather than link or
neighbor metrics.

We would love to hear the opinions of the working group on this topic. Any
preferences or alternative suggestions?

Kind regards,
Vicky.

---

From: Henning Rogge <[email-masked]>
Date: Fri, 15 Apr 2016 22:54:22 +0200

On Fri, Apr 15, 2016 at 10:31 PM, Victoria Mercieca
<[email-masked]> wrote:
> Hi everyone,
>
> The AODVv2 author team are discussing, amongst other things, our metric TLV,
> and would appreciate your input. Currently our draft defines a new

32 bit would also have the same range as the "path cost" of OLSRv2...

> metrics, since ours are accumulated route metrics, rather than link or

This doesn't work because the LINK_METRIC TLV has an exponential
encoding. It is not really useful for path metrics.

Henning Rogge

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 15 Apr 2016 17:07:16 -0400

Henning: 

Can you explain why OLSRv2 used exponential encoding for a link?  I'm trying
to compare this with the ISIS/OSPF link metrics and the TE metrics. 

Sue 

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: Friday, April 15, 2016 4:54 PM
To: Victoria Mercieca
Cc: manet
Subject: Re: [manet] Metric TLV for AODVv2

On Fri, Apr 15, 2016 at 10:31 PM, Victoria Mercieca <[email-masked]>
wrote:
> Hi everyone,
>
> The AODVv2 author team are discussing, amongst other things, our 
> metric TLV, and would appreciate your input. Currently our draft 
> defines a new PATH_METRIC TLV, where we use the type extension to 
> indicate MetricType and the value length varies dependent on metric type.
>
> 1) Recent suggestions that metric fields in general should use 32 
> bits. If we go ahead with this, we alter our current metric TLV very 
> slightly, still using Type, Type Extension for indicating MetricType, 
> Length, and Value fields, but with length set to 32 bits for every 
> metric type. 32 bits seems like overkill for a hopcount metric, and 
> suitability for other metric types may vary.

> 2) Other suggestions that we re-use the LINK_METRIC TLV used by 
> OLSRv2. It has a value length of 16 bits total. If we do use that, I 
> believe we could still use extension type to indicate MetricType like 
> we are currently with our own TLV. I don't believe its a big change to 
> the AODVv2 draft either. We would need define how to set the 'kind' 
> and 'direction' bits for AODVv2 metrics, since ours are accumulated 
> route metrics, rather than link or neighbor metrics.

This doesn't work because the LINK_METRIC TLV has an exponential encoding.
It is not really useful for path metrics.

Henning Rogge

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

---

From: Henning Rogge <[email-masked]>
Date: Fri, 15 Apr 2016 23:09:39 +0200

> to compare this with the ISIS/OSPF link metrics and the TE metrics.

https://tools.ietf.org/html/rfc7181#section-6.2

The OLSRv2 metric encoding use an 8 bit mantissa and a 4 bit exponent.

That works well for a Link State protocol, but not for Distance Vector ones.

Henning Rogge

---

From: Christopher Dearlove <[email-masked]>
Date: Fri, 15 Apr 2016 22:14:56 +0100

I'm not going to jump in with a suggestion right now, but rather to summarise what I think are the key features of the OLSRv2 metric.

First, the 16 bit value field is, as you've noted, 4 flag bits and 12 data bits. I'll consider those in turn and then other aspects.

The 4 flag bits are specified with link state in mind. The incoming/outgoing is obviously straightforward. (If bidirectional - though I don't believe that is reliable - just set both.) But link/neighbour are neither route, so reinterpretation would be needed.

The 12 bits are a compressed form of a 28 bit representation. Why 28? Because accumulating 255 (or even 256) of them can't exceed 32 bits. So the OLSRv2 usage is to send compressed link metrics that are expanded, summed exactly and used locally. You never need to convert a 32 but value back to compressed representation.

But now you would have to sum and convert back. That poses three problems. The first is range, 28 bits is now a bit odd. But quite usable. The second is overflow. Which I suggest saturates at maximum. The third is rounding. The sum of two representable values is not, in general, representable. So you need a well-defined rounding rule. Not hard, but needed.

Assuming you're over all that, what about someone who says we don't need two octet a for hop count. Here I refer you to 7188 which has ruled (currently only mandated for NHDP/OLSRv2) for what if TLV value fields are short. If you adopted those, you could use one octet values, and for hop count just one value. Except that doesn't play nicely with the route metric ideas above, so it doesn't work for you. Never mind, worth trying. But note that going back to two octets, we can represent all values from 1 to 256 exactly, hence hop count exactly, without rounding issues, if you use 1 (coded as 0) as your one metric value. (Actually some other values work too, but ignore them.)

Now what about meaning? Well, so far reserved are just 8 values for administrative definition. There are good reasons to want those. (It was increased to 8 in MT btw.) Even Henning's draft (going for an AUTH48 record Henning?) doesn't reserve a code point.

We didn't reserve code points for specific meanings (delay, bandwidth etc.) for a variety of reasons. And any reservations would need careful thought. But the whole point of the OLSRv2 design was to never need to know about allocations within OLSRv2. (Of course whatever process, probably cross-layer, that comes up with values needs to know. But no OLSRv2 code would need to change if code point 57 were allocated tomorrow as delay in nanofortnights.)

Anyway, as I said, not coming down any way in particular here. Just indicating factors I think matter, and if you pick this route need answers. (All answers are possible.) Of course other routes have their own questions.

(And something to seriously consider if using another approach is the protocol-specific TLV type space.)

-- 
Christopher Dearlove

> On 15 Apr 2016, at 21:31, Victoria Mercieca <[email-masked]> wrote:
> 
> Hi everyone,
> 
> The AODVv2 author team are discussing, amongst other things, our metric TLV, and would appreciate your input. Currently our draft defines a new PATH_METRIC TLV, where we use the type extension to indicate MetricType and the value length varies dependent on metric type.
> 
> 1) Recent suggestions that metric fields in general should use 32 bits. If we go ahead with this, we alter our current metric TLV very slightly, still using Type, Type Extension for indicating MetricType, Length, and Value fields, but with length set to 32 bits for every metric type. 32 bits seems like overkill for a hopcount metric, and suitability for other metric types may vary.
> 
> 2) Other suggestions that we re-use the LINK_METRIC TLV used by OLSRv2. It has a value length of 16 bits total. If we do use that, I believe we could still use extension type to indicate MetricType like we are currently with our own TLV. I don't believe its a big change to the AODVv2 draft either. We would need define how to set the 'kind' and 'direction' bits for AODVv2 metrics, since ours are accumulated route metrics, rather than link or neighbor metrics.
> 
> We would love to hear the opinions of the working group on this topic. Any preferences or alternative suggestions?
> 
> Kind regards,
> Vicky.
> 
>

---

From: Christopher Dearlove <[email-masked]>
Date: Fri, 15 Apr 2016 22:18:19 +0100

See RFC 7185.

But in short, because it worked and was compact. As Henning has said, it's designed for link metrics, see my other posting.

--  
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)

> On 15 Apr 2016, at 22:07, Susan Hares <[email-masked]> wrote:
> 
> Henning: 
>

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 15 Apr 2016 17:18:51 -0400

Henning: 

Thanks for the explanation and the pointer.   It will help me dig into the TE links for Distance vector/Path Vector (BGP) versus link-state. 

Sue 

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: Friday, April 15, 2016 5:10 PM
To: Susan Hares
Cc: Victoria Mercieca; manet
Subject: Re: [manet] Metric TLV for AODVv2

On Fri, Apr 15, 2016 at 11:07 PM, Susan Hares <[email-masked]> wrote:
> Henning:
>
> Can you explain why OLSRv2 used exponential encoding for a link?  I'm 
> trying to compare this with the ISIS/OSPF link metrics and the TE metrics.

Henning Rogge

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 15 Apr 2016 17:20:03 -0400

Chris: 

Thanks for this posting and the other posting. It was very helpful on a
Friday evening. 

Sue 

-----Original Message-----
From: Christopher Dearlove [mailto:[email-masked]] 
Sent: Friday, April 15, 2016 5:18 PM
To: Susan Hares
Cc: Henning Rogge; Victoria Mercieca; manet
Subject: Re: [manet] Metric TLV for AODVv2

See RFC 7185.

But in short, because it worked and was compact. As Henning has said, it's
designed for link metrics, see my other posting.

>> we are currently with our own TLV. I don't believe its a big change 
>> to the AODVv2 draft either. We would need define how to set the 'kind'

---

From: Christopher Dearlove <[email-masked]>
Date: Fri, 15 Apr 2016 22:21:11 +0100

That's the what. We wrote a whole RFC on the why, as I indicated 7185.

> On 15 Apr 2016, at 22:09, Henning Rogge <[email-masked]> wrote:
>

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 15 Apr 2016 17:25:43 -0400

Christopher: 

Thanks for the reference to the why.  I'll look into RFC7185 this weekend. 

Sue

---

From: Thomas Heide Clausen <[email-masked]>
Date: Sat, 16 Apr 2016 11:57:13 +0200

Victoria, all,

On these matters, I am generally in favor of letting actual experience guide the decision process. 

Thus in order to inform that decision process (eg in order to understand if 32 bits are too many/few, if the exponential nature of the encoding of the LINK_METRIC TLV would work, etc.), it might help to know something about what metrics are used in actual (i.e. outside the controlled confines of a lab, and not in a network simulator) AODV (v1/v2) deployments? 

I would assume that part of the experiment that was RFC3561 would have been to understand if not the "kind" of metrics to use (i.e. not if ETT/ETX/DAT/* is better/worse, which likely would be heavily media/environment dependent) then at least the range and nature of metrics values that would be useful?

Most, if not all, published work I've seen has referred to hop-count in ns2 - both of which are a poor approximation (on this matter) of what to expect in the real world.

So, what's actually being used in "real world" deployments, and what lessons can be drawn from that?

Best,

Thomas

-- 
Thomas Heide Clausen
http://www.thomasclausen.org

> On 15 avr. 2016, at 22:31, Victoria Mercieca <[email-masked]> wrote:
> 
> Hi everyone,
>