Subject: [Roll] [roll] routing-metrics #84 (new): Comment received WG Last Call on draft-ietf-roll-routing-metrics-09.txt ---

From: "roll issue tracker" <[email-masked]>
Date: Wed, 06 Oct 2010 16:26:32 -0000

#84: Comment received WG Last Call on draft-ietf-roll-routing-metrics-09.txt ---
-----------------------------+----------------------------------------------
 Reporter:  jpv@…            |       Owner:  pister@…                
     Type:  defect           |      Status:  new                     
 Priority:  major            |   Milestone:                          
Component:  routing-metrics  |     Version:                          
 Severity:  In WG Last Call  |    Keywords:                          
-----------------------------+----------------------------------------------
 Email from Colin O'flynn

 Hello,

 There was no ticket opened for what I still consider an issue (I brought
 this up in LC) about the energy metric.

 The energy metric when used for battery-powered devices only has a
 relative measure of current power being used vs. available energy. Thus
 the energy metric will not differentiate between for example a coin-cell
 battery and a car battery connected to a node. Even if this IS the desired
 result I think it would be useful to clarify this.

 Some example solutions:
 #1)
 Make a note in the document about this, as it is desired that the energy
 metric only reflects the current state of the battery device, and thus the
 energy metric is not used for determining the best route (at least alone).
 I’m not sure exactly the point of the node energy metric in this case as-
 is.

 The throughput metric is used to reflect the available bandwidth, which is
 related to available battery power. Thus a coin-cell battery for example
 only advertises a much smaller available bandwidth. This isn’t foolproof
 as other limitations could be reducing the advertised throughput.

 Future expansions through the use of TLVs could also fix this.

 #2)
 The energy metric has an additional field advertising the battery size.
 This would be of limited use since absolute measures aren’t really
 comparable.

 #3)
 The energy metric has either an additional field indicating the
 incremental cost of adding a route, or only advertises the incremental
 cost of adding a route. This doesn’t need to be very accurate, but even a
 rough estimate would be useful.

 So the metric would have the E-E field, but also have a second E-E field
 indicating the predicted E-E with some certain throughput. So it looks
 like:

 [E –E ] [ Predicted E – E] [Bitrate used in predicting E – E]

 The bitrate used could be a small selecting of available values and not an
 actual decimal number. But it would give you an idea of what sort of
 device you are talking to.

 If you are claiming a device can somewhat accurately calculate the E-E
 value, and/or can calculate the throughput field, there is no way this is
 any more complicated than either of those.

 Regards,

   -Colin

-- 
Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/84>
roll <http://tools.ietf.org/wg/roll/>

---

From: "roll issue tracker" <[email-masked]>
Date: Mon, 18 Oct 2010 16:19:41 -0000

Changes (by jpv@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Answer from Colin:

 Hi JP,

 Alright, if this is the objective I think that text makes it very clear
 and addresses my concern.

 It might be worthwhile mentioning that other metrics can be used for the
 purpose of determining ‘available power’ , so someone reading it can
 immediately refer to that section of the document (e.g. the throughput
 metric). Thus it’s not a total oversight, just that what the person is
 looking to be done with the energy metric should actually be done with a
 different metric.

 However I understand the point of the metrics draft is more to give the
 building blocks & describe each one, whereas the OF would discuss how to
 use them. So I would understand if it wasn’t desirable to reference the
 throughput metric from that point, so whichever makes more sense for the
 authors would be fine.

 Warm Regards,

   -Colin

-- 
-----------------------------+----------------------------------------------
 Reporter:  jpv@…            |        Owner:  pister@…                
     Type:  defect           |       Status:  closed                  
 Priority:  major            |    Milestone:                          
Component:  routing-metrics  |      Version:                          
 Severity:  In WG Last Call  |   Resolution:  fixed                   
 Keywords:                   |  
-----------------------------+----------------------------------------------

Ticket URL: <http://wiki.tools.ietf.org/wg/roll/trac/ticket/84#comment:1>
roll <http://tools.ietf.org/wg/roll/>