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

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 13 May 2009 14:54:43 +0200

Pascal Thubert (pthubert) a écrit :
> 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.

I disagree.  I expect real specification.  Something saying how is the 
energy encoded, at least.

Alex

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