Subject: [manet] Resolution for whether or not to use the RFC 6551 registry for link metrics

From: Charlie Perkins <[email-masked]>
Date: Mon, 18 Apr 2016 09:18:16 -0700

Hello folks,

After extensive discussion with various people, I think there does not 
exist today a suitable IETF registry for protocol-independent link 
metrics.  My earlier support for using the RFC 6551 registry was not 
appropriate because the formats for the metrics defined in that document 
are not protocol-independent.

In the case of AODVv2, the cure is simple. RFC 6551 was only cited in 
section 11.6. That section can be easily modified to lose the citation. 
The result is:

11.6.  MetricType Allocation

    The metric types used by AODVv2 are identified according to a new
    table to be created and maintained by IANA.  All implementations MUST
    use these values.

           +---------------------+----------+--------------------+
           | Name of MetricType  | Type     | Metric Value Size  |
           +---------------------+----------+--------------------+
           | Unassigned          | 0        | Undefined          |
           | Hop Count           | 1        | 1 octet            |
           | Unallocated         | 2 - 254  | TBD                |
           | Reserved            | 255      | Undefined          |
           +---------------------+----------+--------------------+

                        Table 7: AODVv2 Metric Types

This will also require some new text in IANA Considerations.

I have specifications for other other link metric types that are also 
useful for wireless links and routing.  I will post them later today, 
but the discussion about the exact format of those metric values should 
not stand in the way of AODVv2.

Comments please?

Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Mon, 18 Apr 2016 18:27:19 +0200

On Mon, Apr 18, 2016 at 6:18 PM, Charlie Perkins
<[email-masked]> wrote:
> I have specifications for other other link metric types that are also useful
> for wireless links and routing.  I will post them later today, but the
> discussion about the exact format of those metric values should not stand in
> the way of AODVv2.
>
> Comments please?

I think it would be good to have at least one "32 bit unsigned
integer" metric value... because you could use the DAT metric and then
just plug it into you path cost calculation if you want.

every OLSRv2 link metric can be expressed with 24 bits, so 32 bits
give you a maximum path length of 255, which is the maximum for an IP
packet anyways.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 18 Apr 2016 16:33:40 +0000

That's discussing metric types and bits. I have two observations.

First, that needs to know where it's going to be used. TLV type extensions of a TLV type?

Second, having a metric size that is variable with type is painful in terms of parsing. If someone adds a new type you need to change code, or at least change a lookup table associated with your code. We made the opposite choice in OLSRv2 - of course we had the advantage of only needing link metrics on the wire. Lots of protocols have made a similar choice that makes type knowledge necessary in a parser that can become outdated. (And several of those designers have been cursed for it.) As ever in such cases, need to be clear about tradeoffs and then decide.

-- 
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: [email-masked]

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Charlie Perkins
Sent: 18 April 2016 17:18
To: Mobile Ad Hoc Networks mailing list
Subject: [manet] Resolution for whether or not to use the RFC 6551 registry for link metrics

----------------------! 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.
--------------------------------------------------------

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

Hello folks,

After extensive discussion with various people, I think there does not exist today a suitable IETF registry for protocol-independent link metrics.  My earlier support for using the RFC 6551 registry was not appropriate because the formats for the metrics defined in that document are not protocol-independent.

In the case of AODVv2, the cure is simple. RFC 6551 was only cited in section 11.6. That section can be easily modified to lose the citation. 
The result is:

Comments please?

Regards,
Charlie P.

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

********************************************************************
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, 18 Apr 2016 16:36:26 +0000

I was about to say correction, then realised I was the one that needed correcting. In an earlier post I said 28 bits, where Henning has here correctly said 24 bits. Doubly embarrassing as I designed that representation (modified from previous, modified from RFC 5497 for times, modified from OLSRv1).

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 18 April 2016 17:27
To: Charlie Perkins
Cc: Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] Resolution for whether or not to use the RFC 6551 registry for link metrics

*** WARNING ***

On Mon, Apr 18, 2016 at 6:18 PM, Charlie Perkins <[email-masked]> wrote:
> but the discussion about the exact format of those metric values 
> should not stand in the way of AODVv2.
>
> Comments please?

I think it would be good to have at least one "32 bit unsigned integer" metric value... because you could use the DAT metric and then just plug it into you path cost calculation if you want.

every OLSRv2 link metric can be expressed with 24 bits, so 32 bits give you a maximum path length of 255, which is the maximum for an IP packet anyways.

Henning Rogge

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 18 Apr 2016 12:11:13 -0700

Hello Henning,

I think that's a good idea, but I'm not sure what metric specification 
to cite for that.  Do you have a suggestion?  Should I just cite RFC 7185?

Regards,
Charlie P.

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 18 Apr 2016 21:13:01 +0200

Hi Charlie,

I think nothing should be in the way of AODVv2 we want the best reactive
protocol for IETF
, we done the proactive so now doing reactive. Therefore, yes we need new
metric format for AODVv2.

AB

---

From: Henning Rogge <[email-masked]>
Date: Mon, 18 Apr 2016 21:13:00 +0200

On Mon, Apr 18, 2016 at 9:11 PM, Charlie Perkins
<[email-masked]> wrote:
> Hello Henning,
>
> I think that's a good idea, but I'm not sure what metric specification to
> cite for that.  Do you have a suggestion?  Should I just cite RFC 7185?

Yes,

I would refer to the OLSRv2 design document and mention that a 32 bit
path metric TLV makes AODV2 be able to use any kind of OLSRv2 link
metric.

Henning Rogge

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 18 Apr 2016 12:35:24 -0700

Hello Abdussalam,

Thanks for your support!

I think that the link metric type table specified in the AODVv2 document 
should remain protocol-independent as much as possible.  I also support 
the OLSRv2 strategy of using additive cost metrics insofar as is possible.

Regards,
Charlie P.

On 4/18/2016 12:13 PM, Abdussalam Baryun wrote:
> Hi Charlie,
>
> I think nothing should be in the way of AODVv2 we want the best 
> reactive protocol for IETF
> , we done the proactive so now doing reactive. Therefore, yes we need 
> new metric format for AODVv2.
>
> AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 18 Apr 2016 21:54:19 +0200

IMO, yes we agreed to use the same formats as general (I only agree if not
affecting performance of protocol), because the WG was looking into the
hybrid networking opportunity, but I don't care about hybrid protocol
performance now, but I look into the one protocol performance first which
is the AODVv2, as I done when reviewed the OLSRv2. Therefore the strategy
better to be first for AODVv2 best efficiency,  then with the AODVv2 hybrid
networking. I don't much care about multiplexing efficiency while having
bad protocol efficiency, so we need to focus on the best ways for the
protocol not the best ways for mixing it with others. However, that is my
opinion a WG participant, but liked to discuss as seen a request.

AB

On Mon, Apr 18, 2016 at 9:35 PM, Charlie Perkins <
[email-masked]> wrote:

> should remain protocol-independent as much as possible.  I also support the
> OLSRv2 strategy of using additive cost metrics insofar as is possible.
>
> Regards,
> Charlie P.
>
>
>

---

From: Henning Rogge <[email-masked]>
Date: Wed, 20 Apr 2016 07:49:59 +0200

> OLSRv2 strategy of using additive cost metrics insofar as is possible.

Then I would suggest to just copy the OLSRv2 strategy.

Define a single PATH_METRIC TLV with a 32 bit unsigned integer inside.
This should work out for most (maybe even all) metrics and makes
AODVv2 and OLSRv2 link/path metric range compatible.

A special deployment that needs to preserve a few more bytes could
work on a (transparent) compression scheme for the message format
later.

Henning

---

From: [email-masked]
Date: Wed, 20 Apr 2016 09:08:17 +0200

There are three key points that I want to reiterate here - and I think that I am in part just reiterating some comments that Chris made earlier:

1) The routing protocol should not be aware of the “specifics” of any metric used, but simply its identity and structure 
This includes both which “kind” (ETT, DAT, taste, flavour, colour …) and I would even argue “how many bits it is long". As long as (i) metrics are additive, and (ii) metrics are carried in a TLV, that is all that is needed:

		A router receives a message with a TLV:
			TLV_TYPE		 	= Path_Metric
			TYPE_EXTENSION	= Path_Metric_Type
			LENGTH				= n octets
			VALUE				= Metric_Value

		The TLV_TYPE allows the router to determine that “this TLV carries a metric”.

		TYPE_EXTENSION allows the router to determine if it can participate in this 
			topology (process/forward the message), or not (drop)

		(LENGTH , VALUE) allows it to allocate appropriate data structures to do the 
			“addition” (additive metrics) and determine the updated VALUE if the message is retransmitted

2) Consequently, the registry for link metrics is the Type Extension registry that is created when allocating the TLV_TYPE = Path_Metric
That registry should, I believe, in a publication of the routing protocol specification *NOT* contain references to specific metric types (ETT, DAT, …). Take a look at how we did (for LINK_METRIC)  in RFC7181 http://tools.ietf.org/html/rfc7181#section-24 and updated in RFC 7722 https://tools.ietf.org/html/rfc7722#section-13.3

The idea is to have a set of “administratively assigned” meanings defined (for administratively determined topology types). 

It may be that in a deployment I will administratively assign one of those to the RFC7799 experimental metric  type. Then, down the line, it may turn out that RFC7799 is a great idea, and a std.track RFC7799bis is proposed and adopted — which then could make a reservation of a LINK_METRIC (or, PATH_METRIC) TLV type for the protocols where it was found useful.

3) a “protocol independent metrics type registry" is actually mechanically a bad idea, and is in any event premature at this stage. 
It may be, for example, that a metric representation works well for a proactive protocol — but doesn’t for a reactive protocol. I would, for example, guess that the representation of “link metrics” in OLSRv2 would not be ideal for path metrics in a reactive protocol. It would be unfortunate if “making a reservation for OLSRv2” in a registry would squat on the type space for a reactive protocol (using TLV Type Extensions, there are only 256 possible …)

Just as it may be that the RFC7799 metric type works great for OLSRv2, but as it is (as far as I know) not tested in reactive protocols would be horrible for a reactive protocol. It would be unfortunate if OLSRv2 making a reservation for that metric type would “squat on” the type space for a reactive protocol.

In conclusion, it would seem reasonable to adopt the approach described in points 1) and 2) for how to deal with metrics, and to push 3) off the table. 
Remember, though, whereas in OLSRv2 the VALUE field formatting is the “exponential format” that Chris has described (because it makes sense, for the reasons Chris also enumerated, for OLSRv2), it may be wise to define the VALUE field as “an unsigned integer field of n octets” for the purposes of a reactive protocol? 

Although that would likely be informed by what the answer to my question in http://mailarchive.ietf.org/arch/msg/manet/gieCZUvocKq-OYKbznHLj-SolzU <https://mailarchive.ietf.org/arch/msg/manet/gieCZUvocKq-OYKbznHLj-SolzU> would be?

Hope to see this reflected in a forthcoming revision of the document?

Best,

Thomas

> On 20 Apr 2016, at 07:49, Henning Rogge <[email-masked]> wrote:
>

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 20 Apr 2016 05:48:26 -0700

Hello Henning,

It is wrong to require all metrics to be 32 bits.  We already have a 
number of examples where 8 bit metrics work well.

Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Wed, 20 Apr 2016 14:53:23 +0200

On Wed, Apr 20, 2016 at 2:48 PM, Charlie Perkins
<[email-masked]> wrote:
> Hello Henning,
>
> It is wrong to require all metrics to be 32 bits.  We already have a number
> of examples where 8 bit metrics work well.

Of course you could say "metric value has variable length", but this
would make a generic AODV2 implementation a pain in the ass.

Ever done 17 byte additions? or 23 byte network-to-host byteorder conversion?

If you want variable length, just keep this in mind (or only allow 1,
2 and 4 byte metric size).

Henning

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 20 Apr 2016 14:01:31 +0000

I've half types and deleted two replies, one agreeing more with Henning than Charlie, and one saying actually you can get the best of both worlds. But halfway through the latter I decided it wasn't the best of both worlds but a compromise.

So on balance, all 32 bits is easier to implement, and avoid pretty much all problems. At a small overhead cost. On the other hand you could write code that is mostly metric type unaware (isolating it to the corner - outside and on the border of the routing protocol) despite having variable metric lengths (all a multiple of 8 bits) because the length is carried in the TLV - the L in fact. You'd rely on that matching your local decision, otherwise fail. (The possibility of fail being one issue.) But I'm far from sold on that.

I thought about an approach that goes "all metric types are 32 bits". But if when I'm constructing my message I notice that all my metric values (per TLV - so possibly just the one) can be sent in 1, 2 or 3 octets then I use that. On reception I expand to 32 bits. I know at least one person here will dislike that, and it has problems with the maximally immutable message approach.

Or in short, nothing is ideal. At this point I'd be very tempted to say get something down, and the easiest something is always 32 bits.

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 20 April 2016 13:53
To: Charlie Perkins
Cc: Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] Resolution for whether or not to use the RFC 6551 registry for link metrics

*** WARNING ***

> number of examples where 8 bit metrics work well.

Of course you could say "metric value has variable length", but this would make a generic AODV2 implementation a pain in the ass.

Henning

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 20 Apr 2016 10:15:56 -0400

On Wed, Apr 20, 2016 at 10:01 AM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

[snip]

> Or in short, nothing is ideal. At this point I'd be very tempted to say
> get something down, and the easiest something is always 32 bits.
>
> [snip]

+1.
Except I'm not "very tempted to say"; I'm just flat-out saying it: "Get
something down, and the easiest something is always 32 bits."
;-) ;-)

Regards,
Stan

---

From: [email-masked]
Date: Wed, 20 Apr 2016 17:05:57 +0200

> On Apr 20, 2016, at 16:15, Stan Ratliff <[email-masked]> wrote:
> 
> 
> On Wed, Apr 20, 2016 at 10:01 AM, Dearlove, Christopher (UK) <[email-masked] <mailto:[email-masked]>> wrote:
> 
> [snip] 
> Except I'm not "very tempted to say"; I'm just flat-out saying

As WG chair, or as document author?

> it: "Get something down, and the easiest something is always 32 bits."
> ;-) ;-)
> 

Disagree. I posted, earlier today and in another thread, a proposal that could be a (sort of) compromise. For sure, if all you need is an octet, then you shouldn’t have to have 4 forced upon you, when there is an alternative.

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 20 Apr 2016 11:15:53 -0400

> As WG chair, or as document author?

We've been through this. I've already explicitly recused myself from char
duties with regard to AODVv2, Therefore, there is no need to do so on each
and every email.

> Disagree. I posted, earlier today and in another thread, a proposal that
> could be a (sort of) compromise. For sure, if all you need is an octet,
> then you shouldn’t have to have 4 forced upon you, when there is an
> alternative.
>

Then I guess there's yet another item on which we disagree.

Stan

---

From: [email-masked]
Date: Wed, 20 Apr 2016 17:35:10 +0200

> On Apr 20, 2016, at 17:15, Stan Ratliff <[email-masked]> wrote:
> 
> 
> 
> On Wed, Apr 20, 2016 at 11:05 AM,  <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Apr 20, 2016, at 16:15, Stan Ratliff <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
> We've been through this. I've already explicitly recused myself from char duties with regard to AODVv2, Therefore, there is no need to do so on each and every email.
>  
> 

Which is why it is important to be very clear what hat is worn.

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 20 Apr 2016 17:39:05 +0200

> duties with regard to AODVv2, Therefore, there is no need to do so on each
nice one :-). Yes we got through this, when I see your email saying you are
a participant I get a feeling that you are not the chair and also not other
positions. I agree any participant does not need to do that, but if he is a
chair speaking he/she needs to write/say that the chair is
speaking/writting.

AB

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 20 Apr 2016 11:45:31 -0400

> Which is why it is important to be very clear what hat is worn.
It *IS* clear.