Subject: [manet] AODVv2 MetricType TLV discussion

From: Lotte Steenbrink <[email-masked]>
Date: Wed, 4 Mar 2015 16:18:36 +0100

Hi all,
as you can see, the current revision of AODVv2 has an optional Message TLV called “MetricType”, which has to be set for any other than DEFAULT_METRIC_TYPE (i.e. hop count).
I'd like to ask the WG for their opinion on a change concerning this situation. I'd like to propose to turn MetricType into an extension type of the Metric TLV instead of using it as a MessageTLV.
In my opinion, the current approach has two downsides:

1) Putting the MetricType TLV it in an entirely different location than the actual Metric value is counterintuitive to me (and I fear that it's going to cause headaches bloaty code from an implementation perspective)
2) making it an optional Message TLV saves bytes for deployments using Hop Count as a metric, but at the cost of penalizing everyone that is using a different metric. If I understand RFC5444 correctly, extension types are cheaper than fully-fledged TLVs, byte-wise.

Now, these extension types could be 
a) mandatory for *all* metrics (including the default), which would allow for smoother processing
b) mandatory for all metrics *except* for the default metric, which would save some extra space for those kinds of deployments.

I'm still a bit on the fence about preferring a) or b), but in general, I really like the idea of using extension types.
What does the rest of the WG think? Does my approach make any sense at all and if so, how should one go about introducing them to AODVv2 metric TLVs?

Regards,
Lotte

---

From: Henning Rogge <[email-masked]>
Date: Sat, 7 Mar 2015 10:05:49 +0100

> 2) making it an optional Message TLV saves bytes for deployments using Hop Count as a metric, but at the cost of penalizing everyone that is using a different metric. If I understand RFC5444 correc…

Having 10 addresses in an address block with the same TLV will cost
you a total of 1 byte for adding the same extension types to everyone
(because you only need one multi-value TLV for all addresses).

> b) mandatory for all metrics *except* for the default metric, which would save some extra space for those kinds of deployments.

I think I made the same suggestion 20-30 months ago... and if we would
assign "metric 0" for the default metric, a) and b) automatically
become the same anyways.

Henning Rogge

---

From: Charlie Perkins <[email-masked]>
Date: Sat, 07 Mar 2015 02:40:56 -0800

Hello folks,

Sounds like a good idea to me.  I'll put it on the list of things
to discuss at the IETF meeting, but if anyone has objections
please don't wait for the meeting ...

Regards,
Charlie P.

On 3/7/2015 1:05 AM, Henning Rogge wrote:
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Henning Rogge <[email-masked]>
Date: Sat, 7 Mar 2015 11:54:22 +0100

> please don't wait for the meeting ...

This mechanism (use extension type for metric selection) is already
the same thing we are doing with OLSRv2.

It makes things easier (no need for the "metric type" message TLV) and
more compact for AODVv2... and it might also help to convert AODVv2
into a multitopology protocol later (similar what happened with
OLSRv2).

Now, if all AODVv2 metrics are "additive", you should be able to drop
the "AODVv2 needs to know the type of metric" requirement.

If you just define your metric TLV as an "1-4 bytes long integer" with
a dimensionless cost you can easily put hopcount, ETX, signal strength
or anything else there without loosing efficiency. You cannot reuse
the NHDP/OLSRv2 metric TLV because you have to encode path-cost, not
link cost... and exponential encoding doesn't work well for
path-costs.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 9 Mar 2015 11:15:54 +0000

As Henning says on most points.

It's worth, I think, commenting on OLSRv2, not because I'm saying you should do it the same way, but because it may be worth understanding why we did it the way we did, so you can see whether similar considerations apply, or not (some points, clearly not).

We also have a special case zero, not for hop count (because we did not want to encourage hop count, rather the reverse) but for administratively configured.

We have all metric types to be handled the same way, so the OLSRv2 code itself is metric agnostic, it just needs to be told which number to use. As Henning notes, we have the advantage of only handling link metrics. The compressed form we have satisfied people's requirements for low bandwidth while still having a 24 bit dynamic range (24 as then path metrics fit is 32 bits). That we have four kinds of metric made it all fit very conveniently for us.

We do have a metric type TLV. That arose for two reasons. First, we were putting metrics into NHDP HELLO messages, and we weren't allowed (by ourselves as much as anyone, but Justin was one person driving this) to assume that we were the only user of the HELLO message, so we needed a "this is an OLSRv2-aware HELLO message" anyway, and adding the metric type to that added one byte. Second, we were planning ahead to multitopology (Stan being keen on this) and while we hadn't designed MT yet, that gave us something we would later need.

-- 
Christopher Dearlove
Senior Principal Engineer, Information Assurance 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: manet [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 07 March 2015 10:54
To: Charlie Perkins
Cc: MANET IETF
Subject: Re: [manet] AODVv2 MetricType TLV discussion

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

On Sat, Mar 7, 2015 at 11:40 AM, Charlie Perkins <[email-masked]> wrote:
> Hello folks,
>
> Sounds like a good idea to me.  I'll put it on the list of things to 
> discuss at the IETF meeting, but if anyone has objections please don't 
> wait for the meeting ...

This mechanism (use extension type for metric selection) is already the same thing we are doing with OLSRv2.

It makes things easier (no need for the "metric type" message TLV) and more compact for AODVv2... and it might also help to convert AODVv2 into a multitopology protocol later (similar what happened with OLSRv2).

Now, if all AODVv2 metrics are "additive", you should be able to drop the "AODVv2 needs to know the type of metric" requirement.

If you just define your metric TLV as an "1-4 bytes long integer" with a dimensionless cost you can easily put hopcount, ETX, signal strength or anything else there without loosing efficiency. You cannot reuse the NHDP/OLSRv2 metric TLV because you have to encode path-cost, not link cost... and exponential encoding doesn't work well for path-costs.

Henning Rogge

********************************************************************
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: Henning Rogge <[email-masked]>
Date: Mon, 9 Mar 2015 15:59:36 +0100

> We do have a metric type TLV. That arose for two reasons. First, we were putting metrics into NHDP HELLO messages, and we weren't allowed (by ourselves as much as anyone, but Justin was one person…

Are you mixing this up with the MPR_WILLING or CONT_SEQ_NUM message
TLV defined in RFC 7181?

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 9 Mar 2015 15:06:34 +0000

No, I'm getting it confused with the MPR_TYPES TLV added in MT-OLSRv2. We also decided we didn't need to include the link metric type as a message TLV, but we still have the message TLV, which as you note is MPR_WILLING.

OK, sorry about that.

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 09 March 2015 15:00
To: Dearlove, Christopher (UK)
Cc: Charlie Perkins; MANET IETF
Subject: Re: [manet] AODVv2 MetricType TLV discussion

> We do have a metric type TLV. That arose for two reasons. First, we were putting metrics into NHDP HELLO messages, and we weren't allowed (by ourselves as much as anyone, but Justin was one person…

Are you mixing this up with the MPR_WILLING or CONT_SEQ_NUM message TLV defined in RFC 7181?

Henning Rogge

---

From: Lotte Steenbrink <[email-masked]>
Date: Thu, 12 Mar 2015 21:52:26 +0100

Hi Henning, hi all,

> Am 07.03.2015 um 10:05 schrieb Henning Rogge <[email-masked]>:
> 
> I think I made the same suggestion 20-30 months ago...

Well then it really is about time we look at this again...

> and if we would

Ooh, I like the sound of that.
Thank you for your input on the issue! I'm away from my computer this week, but I'll try to come up with an appropriate change to the draft as soon as I return home.
If there are any more suggestions or complaints, just let me know.

Regards, 
Lotte