Subject: [Roll] metrics LC Tickets: battery

From: "Colin O'Flynn" <[email-masked]>
Date: Wed, 6 Oct 2010 10:54:23 +0100

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

---

From: JP Vasseur <[email-masked]>
Date: Mon, 18 Oct 2010 08:56:54 +0200

Hi Colin,

Let's try to close on this last ticket (#84) - See below.

On Oct 6, 2010, at 11:54 AM, Colin O'Flynn wrote:

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

This is indeed the objective and I agree with you that we could come up with more complicated/exhaustive node energy metric in the future (note that there are available flags and the object can carry optional sub-TLVs too). For the time being, I propose to add the following text:

"Note that the estimated percentage of remaining energy indicated in the E-E field may not be useful in the presence of nodes powered by battery or energy scavengers when the amount of energy accumulated by the device significantly differ. Indeed, X% of remaining energy on a node that can store a large amount of energy cannot be easily compared to the same percentage of remaining energy on a node powered by a tiny source of energy. That being said, in networks where nodes have relatively close energy storage, such a percentage of remaining energy is useful. Other documents may define more complex/detailed mechanisms to represent these metric."

Let me know if that addresses your concern.

Thanks.

JP.

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

---

From: "Colin O'Flynn" <[email-masked]>
Date: Mon, 18 Oct 2010 16:49:03 +0100

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

From: JP Vasseur [mailto:[email-masked]] 
Sent: October 18, 2010 7:57 AM
To: Colin O'Flynn
Cc: [email-masked]
Subject: Re: metrics LC Tickets: battery

Hi Colin,

Hello,

This is indeed the objective and I agree with you that we could come up with
more complicated/exhaustive node energy metric in the future (note that
there are available flags and the object can carry optional sub-TLVs too).
For the time being, I propose to add the following text:

"Note that the estimated percentage of remaining energy indicated in the E-E
field may not be useful in the presence of nodes powered by battery or
energy scavengers when the amount of energy accumulated by the device
significantly differ. Indeed, X% of remaining energy on a node that can
store a large amount of energy cannot be easily compared to the same
percentage of remaining energy on a node powered by a tiny source of energy.
That being said, in networks where nodes have relatively close energy
storage, such a percentage of remaining energy is useful. Other documents
may define more complex/detailed mechanisms to represent these metric."

Thanks.

JP.

Some example solutions:

#1)

#2)

#3)

Regards,

  -Colin

---

From: JP Vasseur <[email-masked]>
Date: Mon, 18 Oct 2010 18:18:53 +0200

Thanks for your prompt reply. We'll update the draft accordingly and close the ticket.

Thanks.

JP.

On Oct 18, 2010, at 5:49 PM, Colin O'Flynn wrote:

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