Subject: Re: [OPSAWG] New Version Notification for draft-quittek-power-mib-01

From: "Juergen Quittek" <[email-masked]>
Date: Thu, 22 Apr 2010 23:18:07 +0200

Dear all,

We have posted an update of the Power MIB modules
(draft-quittek-power-mib). We consider this a first step
towards a merger with draft-claise-energy-monitoring-mib.

Changes from the previous version include

  - adopting the concept proposed with object of PowerUsageCaliber
    from draft-claise-energy-monitoring-mib as object
    energyConsumpMeasurementMethod

  - adopting the emDemandTable of draft-claise-energy-monitoring-mib
    as energyPowerHistoryTable

  - adding the information contained in the pmLevelTable of
    draft-claise-energy-monitoring-mib to the powerStateTable
    (new object powerStateAveragePower and powerStateMaximumPower)

  - adopting the concept of pmPowerUsageAccuracy by adding object
    energyConsumpPowerMaxError and EnergyConsumpEnergyMaxError

  - as a solution for the discussion about the required numbers
    of power levels, we suggest to have them not fixed by an
    enumeration but to be flexible and have each of them defined by
    an entry in the powerStateTable. For this purpose we changed
    the index of this table to a string that contains the name of
    the power state and we added a object for describing properties
    of the state.

For each of these five issues I will post an individual email
describing our proposed solution and remaining issues in detail.

We have not yet adopted the concept of power parent - power child
proposed in draft-claise-energy-monitoring-mib. It is not yet
completely clear to us. We should have a discussion on this concept
on the mailing list.

I look forward to vivid discussions on these issues.

    Juergen

On 22.04.10 22:37  "IETF I-D Submission Tool" <[email-masked]> wrote:

> 
> A new version of I-D, draft-quittek-power-mib-01.txt has been successfully
> submitted by Juergen Quittek and posted to the IETF repository.
> 
> Filename:  draft-quittek-power-mib
> Revision:  01
> Title:   Definiton of Managed Objects for Energy Management
> Creation_date:  2010-04-22
> WG ID:   Independent Submission
> Number_of_pages: 57
> 
> Abstract:
> This memo defines a portion of the Management Information Base (MIB)
> for use with network management protocols in the Internet community.
> In particular, it describes extensions to the Entity MIB to provide
> information about the energy consumption, the power states and
> battery status of managed devices and their components.
>                  
> 
> 
> The IETF Secretariat.
> 
>

---

From: "Juergen Quittek" <[email-masked]>
Date: Fri, 23 Apr 2010 08:16:06 +0200

Dear all,

This is the first of a set of issues of the Power MIB modules.
I will send more in separate emails. I'd be glad to receive
replies on the issues and to have a vivid discussion that
will help us to merge the two drafts we have in this area
(draft-claise-energy-monitoring-mib and draft-quittek-power-mib).

Issue #1: reporting accuracy of measured vaues

For reporting consumed energy or actual electrical power of devices
it is useful to also report the accuracy of the applied measurement
method.
 
Objects of type EntitySensorPrecision (Entity MIB, RFC3433)
do not appear useful for this purpose, because they seem to
indicate the the format of values provided in associated
objects of type EntitySensorValue, but not the accuracy
of a measurement conducted by a sensor.

Draft draft-claise-energy-monitoring-mib-02 proposes using
an object called pmPowerUsageAccuracy for indicating accuracy.
This object indicates the accuracy of a value in hundredths of
percent. This would be feasible, but not a convenient solution.

The problem with this approach is the following.  Accuracy is
typically indicated as maximum error of a reported value in
percent of the maximum value that can be reported by the meter,
see IEC 62053-22 and ANSI C12.20. In draft-claise-energy-
monitoring-mib-02 there is no indication of the maximum
value that can be reported by the meter. The reported percentage
would be useless if it indicated the accuracy in percent of the
maximum value that can be reported by the meter, because this
Value is not necessarily known to anyone.

The only way I see in which object pmPowerUsageAccuracy could be
useful would be that it indicates the accuracy in percent of the
actual reported value of power or energy consumption, respectively.
But this would be quite inconvenient. The MIB implementation
would have to compute the percentage with respect to the actual
power each time it is reported. And users of the MIB module would
read a different value from this object each time they retrieve
its value.

A solution would be to add an object indicating the maximum value
to be reported by the meter. Then the percentage could be given
With respect to this value.

In draft draft-quittek-power-mib-01 we suggest a simpler alternative.
Instead of reproting a percentage value, a maximum error value is
reported by objects of type EnergySensorMaxError. The value of
such an object is the product of the accuracy in percentage and
the maximum value that can be reported by a meter. We defined
textual convention EnergySensorMaxError in a way that it integrates
well with TCs EntitySensorValue, EntitySensorDataScale, and
EntitySensorPrecision from the Entity MIB.

Advantages of this way are
  - only one object needed
  - value of the object is constant for a certain implementation
      - needs to be read only once by a certain management application
      - does not require computation at the MIB implementation each
        time the value is retrieved

Disadvantages
  - The mapping to accuracy classes for measurement instruments cannot
    easily be made, because these classes are defined by percentage values
    (1%, 2%, 5%, etc.) with respect to the maximum value that can be
    reported by a meter. However, so far we have not seen a use case
    for the power MIB modules that requires mapping to this classes
    if the maximum error of a measurement value is known.

Thanks,

    Juergen

---

From: "Juergen Quittek" <[email-masked]>
Date: Fri, 23 Apr 2010 10:26:34 +0200

Issue #2: number of power states

We do not yet have consensus how many power states should be
supported/standardized.

The Entity State MIB module defines (RFC4268) defines three states:
unknown(1), hotStandby(2), coldStandby(3), providingService(4) in
TC EntityStandbyStatus. As the name indicates, the intention of this
TC is not defining power states, but defining standy states. From
a power management point of view "hotStandby(2)" and providingService(4)
may be quite similar.

draft-claise-energy-monitoring-mib-02 defines twelve power states:
mechoff(1), softoff(2), hibernate(3), sleep(4), standby(5), ready(6),
low(7), frugal(8), medium(9), reduced(10), high(11), and full(12).
This may be considered too many???

These twelve states have been derived from the Advanced Configuration
& Power Interface (ACPI). I talked to people from EnergyStar. They
consider the ACPI states as too detailed. They told me that to their
knowledge, several of the ACPI states have not been implemented by
any device, yet.

The discussion whether 3 8 10 12 or 15 power states are the best
choice may become tedious and non-productive. We suggest not fixing
the number of power states in an SMI enumeration, but leave the
number and names of power states up to the developer of a device
or of the MIB module, respectively.

In draft-quittek-power-mib-01 we suppoerted this by indexing the
PowerStateTable by an object of type SnmpAdminString which would
Carry the name given to a power State and by adding another object
of the same type (powerStateDescription) for providing a brief
description of what power reduction measures are applied in this
State.

This would give a lot of flexibility but has the disadvantage
that naming of power states may be very different on different devices.
But having a consistent (fixed) naming would not help much because
it is impossible to give reasonably clear guidelines in a standards
document what a power state "medium" would have to be implemented.
If you have two routers in state "medium", one of them may implement
This by reducing power spent on features A, B, C, and D, while
Another router would implement it by saving power on features A, B,
E, and F.  Bringing then both routers into the "same" state "medium"
May not be a good idea.

The bottom line is that we cannot define power states in a way
that achieves interoperability between different devices.
Thus we don't have to fix them in our standard-to-be but rather
should leave this open to implementers.

This is close to both drafts, we are discussion, because also
draft-claise-energy-monitoring-mib-02 already defines a table
(pmLevelTable) for defining properties of power states.
The only change required for solving this issue would be changing
the index space from a fixed one (defined by an SMI enum) to a
flexible one.  We already did so in draft-quittek-power-mib-01
and also added there objects powerStateAveragePower and
powerStateMaximumPower for reflecting supporting feature
PmLevelMaxUsage in the pmLevelTable.

Thanks,

    Juergen

---

From: Benoit Claise <[email-masked]>
Date: Fri, 23 Apr 2010 12:46:34 +0200

Juergen, dear all,

Thanks for this new version.
As discussed at the last meeting, before the merge, we will also produce 
a new version of our draft.
We're in the process of doing so, please allow a few more working days.
 From these two draft versions, we could start the discussion.

Regards, Benoit.
> On 22.04.10 22:37  "IETF I-D Submission Tool"<[email-masked]>  wrote:
>
>    
>> _______________________________________________
>> OPSAWG mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/opsawg
>>

---

From: "Juergen Quittek" <[email-masked]>
Date: Fri, 23 Apr 2010 14:57:49 +0200

Issue #3: monitoring method

draft-claise-energy-monitoring-mib-02 defines an object called
PowerUsageCaliber that defines how the a reported value on energy
consumption has been obtained.

This object may have one of the following values:
unknown(1), actual(2), trusted(3), predicted(4), presumed(5).
  - actual(2) indicates that the reported value has been obtained
    by directly by measuring it.
  - predicted(4) indicates that reported values on energy
    consumption have been obtained by estimating them based on
    device type, configuration, current load, etc.
  - presumed(5) indicates that the reported value has been
    obtained based on very general assumptions for the kind
    of devices, for example, PC power is 200 W in average.
These three values all indicate different ways of how power
values have been generated.

In contrast, value trusted(3) indicates that the reported value
has been generated at another (trusted) device.

In my view whether a value comes from a trusted source is
orthogonal to which method was used to obtain a value (measured,
estimated, presumed).  Combinations such as trusted-actual,
trusted-estimated, and trusted-presumed should be possible.

However, the trustability and he applied measurement method
are different issues and should be reported in separate objects.

In draft draft-quittek-power-mib-01 we adopted the idea of a
measurement method by adding object energyConsumpMeasurementMethod
that only covers the method but does not report on trustability.
There is no object yet on trustability, because we still need
to better understand this concept.

Allowed values for object energyConsumpMeasurementMethod are
directEnergyMeasurement(1), powerOversampling(2),
powerSampling(3), loadBasedEstimation(4),
deviceBasedEstimation(5), unknown(6)

Values loadBasedEstimation(4) and deviceBasedEstimation(5) are
Equivalent to estimated(4) and presumed(5), respectively, in
draft-claise-energy-monitoring-mib-02.

Values directEnergyMeasurement(1), powerOversampling(2),
powerSampling(3) maps to actual(2) but spreads this
into more fine-grained reporting on the measurement method.
It is arguable that this might be more than needed.
I would particularly appreciate input on this point.

Thanks,

    Juergen

---

From: Mark Ellison <[email-masked]>
Date: Tue, 27 Apr 2010 22:11:00 -0400

Juergen,

I have not studied the Power MIB draft, but after reading several emails WRT
power states, I wonder if a somewhat different approach could been
considered-

Rather than name some number of power states, would it not be more useful to
have a pair of objects- the first to indicate the rated full power
consumption draw of a device (volt amps or whatever is appropriate) and the
second to provide a rating from 1 through 10, with 10 being full power draw
and 1 being minimal power draw (zero would not allow a reply be sent).

This pair of objects could provide both a relative measure for the device,
and a reasonable estimate of the actual power consumed by a device. Further,
the accuracy of the values of this pair of objects could be verified by
external means, for example by monitoring the power drawn at the outlet for
a given device.

Possibly this approach could be considered as an alternative to the named
states?

Regards,

Mark