Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 7 Nov 2008 14:52:48 +0100

Hi:

My few cents:

This doc is intended for standard track. As such we should be very careful with what we actually specify. What I think we should be specifying is what the metrics are, what they mean, and if possible an interoperable format for reporting them. How they can be used by a routing protocol could depend on the routing protocol and I expect only guideline, not real specification.

What they mean:
--------------

Be very crisp. What do we count in transmission time, throughput etc... Maybe we need to model a typical radio operation and discuss what is accounted in which metric.

For instance, we are using radios, time spent on CCA counts and the outgoing queueing delay (waiting for the channel to be free) is a good metric on link utilization and capability to add / reserve new traffic. The recent experience in backoff/retries counts. 

If we are using slotted radios (TDM) then the actual time to access the outgoing channel counts. The latency inside the device translates immediately in buffer space that the device will typically lacks.

How they can be used
--------------------

Section 4 and 5 also are really informative. I expect recommendations in chapter 6 but fail to see why we are using uppercase MUST/SHOULD/RECOMMEND terms there; then again this is mostly informative. 

I'd really wish to find some discussions on things like how can a link state protocol manipulate statistical metrics, describing mechanisms such as hysteresis (pro/con), triggered/piggy-backed updates (pro/con) etc... Is that out of scope?

Interoperable formats and operations
------------------------------------

This might be when we really need a standard track as opposed to informative. 

Knowing that a metric exists and what it is is a great step. Providing a interoperable format to exchange it and detailing the aggregation operation is needed as well if we want to standardize anything. We are used to metrics where the representation is a flat number, and the aggregation as simple as the weakest link or the sum over the path. 

But for the data that we are contemplating here things can rapidly get more complex. For instance, for metrics that have a statistical aspect, I trust that we need to exchange information such mean, mode or expected range (+/- X percent) so that we do not need to update as long as we stay within range, that type of thing. 

One advantage of doing that in a separate spec as opposed to each specific routing protocol is to enable redistributing metrics between 2 different routing protocols that would understand this spec but are designed differently for different parts of the network (eg backbone vs. fringe).

Then again is that out of scope?

Pascal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Miguel Sanchez
>Sent: mercredi 29 octobre 2008 11:59
>To: ROLL WG
>Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed
>
>> So we would need your feed-back, bearing in mind that we may want to only keep the metrics that are
>critical to LLNs.
>>
>
>Not sure what is the best way but being able to use remaining-energy
>as a parameter for routing decisions maybe useful (if routing
>contemplates that). Remaining node energy may be added to other
>metrics (delay, traffic, PER, etc).
>
>Cheers,
>
>Miguel Sánchez
>Universidad Politécnica de Valencia, Spain
>_______________________________________________
>Roll mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Hongwei Zhang <[email-masked]>
Date: Fri, 07 Nov 2008 14:52:08 -0500

A minor point:

    It may well be worthwhile to define "packet format" in a way that
    enables us to introduce new metrics/attributes unforeseeable today.
    This is similar to the idea of "extension header" in IPv6.

Hongwei