Subject: Re: [eman] iana powerstate tc proposal

From: Benoit Claise <[email-masked]>
Date: Tue, 02 Aug 2011 18:15:27 +0200

On 28/07/2011 23:20, Juergen Schoenwaelder wrote:
> On Thu, Jul 28, 2011 at 10:47:40PM +0200, John Parello (jparello) wrote:
>
>> The code (value&  0xff) is not that complex. What I find complex is
>> the following:
>>
>> - I always have to poll two OIDs to retrieve the power state. This
>>    adds runtime verbosity and overhead.
>>
>> [jp] If you define a numeric value to each set then this is an index to a state series subtree so you don't have to poll twice It would be in a the tree. If you keep it the way you have it you have to poll the base number first remember the series and then know to avoid or use that range to find out what is supported. With a seperate power state set number it's implicit in the data.  You just traverse or get the entire table.
> But that particular table design I think you are refering to is
> awkward in the first place since it indexes and thus duplicates
> objects that are really not specific to the set.
Point taken. Will be corrected.
> That said, once
> stored, a single integer is simply self-contained (and you even get a
> meaningful descriptor with typical generic SNMP tools).
I still don't get your argument about two OIDs to retrieve the power state.
         pmPowerEntry OBJECT-TYPE
             SYNTAX          PmPowerEntry
             MAX-ACCESS      not-accessible
             STATUS          current
             DESCRIPTION
                "An entry describes the power usage of a Power Monitor."
             INDEX           { pmPowerIndex, pmPowerStateSetIndex}
             ::= { pmPowerTable  1 }

         PmPowerEntry ::= SEQUENCE {
                 ...
                 pmPowerAdminState               Integer32,
                 pmPowerOperState                 Integer32,

I will be polling pmPowerAdminState.pmPowerIndex.pmPowerStateSetIndex to 
get the value of the pmPowerAdminState
>
>> - I need to implement and enforce atomic sets with two varbinds in
>>    order to change from a value in one power state set to a value in a
>>    different power state set.
>>
>> [jp] If you have an index for the set first you get the same ability
> Well, not completely true. If you have dmtf off and you want to change
> to eman on, how does set look like? I know that you assume magic
> implementation specific translations between the power state sets,
> which I find ugly. Too much magic if our goal is interoperability.
Practically, the ENMS will do a discovery of the possible power states 
within the power state set, with the snmpwalk of:
pmPowerStateTable(2)
           |      +--pmPowerStateEntry(1)
           |      |     [pmPowerIndex,
           |      |      pmPowerStateSet,
           |      |      pmpowerStateIndex]
           |      +-- --- Integer32       pmPowerStateIndex(1)
           |      +-- r-n Interger32      pmPowerStateMaxPower (2)
           |      +-- r-n UnitMultiplier
           |                  pmPowerStatePowerUnitMultiplier (3)
           |      +-- r-n TimeTicks       pmPowerStateTotalTime(4)
           |      +-- r-n Counter64       pmPowerStateEnterCount(5)

Actually, I even envision the ENMS asking a device: do you support THIS 
Power State Set, by doing a snmpwalk on 
pmPowerStateTable.pmPowerStateEntry.pmPowerIndex.pmPowerStateSet

 From there, practically, one ENMS will manager (configure and monitor) 
_a single_ Power State Set for a single monitor. SNMPset of 
pmPowerAdminState.pmPowerIndex.pmPowerStateSetIndex to <value>

If the easy translation was possible between Power State Set/Power 
States, then we would have defined a single Power State Set.

Regards, Benoit (as a contributor)
>> Compared to this, doing (value&  0xff) or (value>>  8) is rather
>> cheap. And in addition, with this this appraoch,
>>
>> - I have _all_ IANA maintained power states defined in a machine
>>    readable format, something that can drive tools and automation.
>>
>> [jp] Having an index to the series first is still machine
>> readable.
> The value is machine readable. There is not machine readable
> definition of the power state definitions themself.
>
>> Also BTW you are limiting power states to 256. There was lengthy
>> discussions on not limiting it. I can see a series with 1000 as
>> percentage increments.
> We have 32 bits to play with. If 8 bits are not enough, we pick
> 16. Gives you ~65000 power states. Still not enough? We are after all
> talking about _states_.
>
> /js
>

---

From: Brad Schoening <[email-masked]>
Date: Wed, 3 Aug 2011 02:01:55 +0000

Hi Juergen,

Just wondering if it would be more relevant to use ECMA states in IANA instead of ieee1621?  ECMA is newer, with the same basic states as 1621 but has additional modes that are relevant to contemporary hardware:

ECMA:

	Off
	Sleep
	WoL Sleep 
	ShortIdle
	LongIdle
	Active

1621:

	Off
	Sleep
	On

http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-383.pdf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Thursday, July 28, 2011 12:45 PM
To: [email-masked]
Subject: [eman] iana powerstate tc proposal

Hi,

here is a proposal for an IANA maintained power state textual convention. There are of course other ways of doing this but I thought a concrete proposal might help the discussion.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 Aug 2011 06:54:49 +0200

On Tue, Aug 02, 2011 at 06:15:27PM +0200, Benoit Claise wrote:

> I will be polling
> pmPowerAdminState.pmPowerIndex.pmPowerStateSetIndex to get the value
> of the pmPowerAdminState

And the NMS will display that the power monitor #1 is in the power
state 42 of the power state set 0x0a. If you store the state, you
actually have to store two values. Yes, you make the set atomic by
putting the set into the INDEX. But that does not address other issues
nor does it lead to simplicity.

> Practically, the ENMS will do a discovery of the possible power
> states within the power state set, with the snmpwalk of:
> pmPowerStateTable(2)

I believe it is counter productive for the goal of interoperability to
have everybody support his own power state set and to make the values
somehow dynamically discoverable. I thought this WG had reached
agreement to have a small set of power states/sets registered with
IANA.

> Actually, I even envision the ENMS asking a device: do you support
> THIS Power State Set, by doing a snmpwalk on
> From there, practically, one ENMS will manager (configure and
> monitor) _a single_ Power State Set for a single monitor. SNMPset of

But your design aims at reporting a certain true state of the device
according to different sets concurrently - so you assume there is a
translation which is implementation dependent, that is every device
can translate as it likes to do it. Not sure how this really helps
with interoperability. (And the same goes to proposals where the power
states are expected to be a series with 1000 as percentage increments
as mentioned previously - this looks to me like a fine grained control
knob and not a power state.)

/js

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 3 Aug 2011 12:26:47 +0200

Hi Brad,

It looks like it would be a good idea to register ECMA states as a separate set at IANA once we have that registry.

Thanks,

    Juergen

Am 03.08.2011 um 04:01 schrieb Brad Schoening:

> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Wed, 3 Aug 2011 07:31:58 -0500

Hi Juergen,

Thanks for the email. 

Agreed on the WG consensus that there should be a parsimonious set of
multiple power state sets registered with IANA. 
In fact, initially, we had even proposed a rigorous threshold for the
IANA registry of power state sets. 

On the MIB design, some of the guiding principles for the Textual
Convention are:

1. It should be possible to register a small number of Power State sets
with IANA registry. 

2. It should be possible to discover the Power State Sets supported by
the device (without involving a trial and error type of method.)

3. Regarding the possible duplication of MIB objects, it was felt that
the standard should allow the power monitor to support multiple power
state sets. 
   The standard should not restrict the power monitor to communicate in
one only power state set. 
   Often, the device may implement one power state set. So, duplication
of MIB objects across multiple power state sets would not be such an
overhead. 

As you had also indicated in your initial email, there are several
approaches to solve this MIB design issue. 
There are pros and cons of every approach.  

Thanks
Mouli

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Juergen Schoenwaelder
Sent: Wednesday, August 03, 2011 10:25 AM
To: Benoit Claise (bclaise)
Cc: [email-masked]
Subject: Re: [eman] iana powerstate tc proposal

/js

---

From: Brad Schoening <[email-masked]>
Date: Wed, 3 Aug 2011 13:17:18 +0000

That works also!

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]] 
Sent: Wednesday, August 03, 2011 6:27 AM
To: Brad Schoening
Cc: Juergen Schoenwaelder; [email-masked]
Subject: Re: [eman] iana powerstate tc proposal

Hi Brad,

Thanks,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 3 Aug 2011 18:33:06 +0200

Dear all,

There is already a long email thread on this issue.

Here is my view on it:
The TC that Juergen S. suggested has two definite advantages:
  - it encodes state series and index in a single value
  - it needs a single IANA registry only

Otherwise, there is no big difference to the other proposal.

The single value for set and state is particularly convenient 
for reading and setting power states.
So, I would agree on such a TC. 

Probably the SYNTAX clause would have to be replaced, 
because numbers for states and sets would be registered at IANA and not in the TC.
We had several comments on the list suggesting that other values might be more appropriate.
But I assume the values in the TC served rather as examples than as proposals
for the final values to be chosen.

Thanks,

    Juergen Q.

would be registered at IANA Am 28.07.2011 um 18:45 schrieb Juergen Schoenwaelder:

> Hi,
> 
> here is a proposal for an IANA maintained power state textual
> convention. There are of course other ways of doing this but I thought
> a concrete proposal might help the discussion.
> 
> /js
> 
> -- 
> <IANA-POWER-STATE-MIB.txt>_______________________________________________
> eman mailing list
> [email-masked]

---

From: Bruce Nordman <[email-masked]>
Date: Wed, 3 Aug 2011 22:21:01 -0700

To be clear, Ecma 383 defines a measurement procedure
to identify power levels at different points in time.  It does
not identify power states that are to be exposed to other
entities.  It also is intended only for personal computers.
I offer this observation as someone involved in 383 development.

By contrast, IEEE 1621 defines power states of devices as
they are to be exposed to other entities (in this case, people).
It is also for any electronic device, not just PCs.

So, for reporting of power states, and for not being device-specific,
IEEE 1621 seems more appropriate for EMAN.  If one wants
to be PC-specific, and to have more states, then ACPI or DMTF
is a good choice, as our drafts already note.

--Bruce

On Tue, Aug 2, 2011 at 7:01 PM, Brad Schoening <[email-masked]>wrote:

> Hi Juergen,
>
> Just wondering if it would be more relevant to use ECMA states in IANA
> instead of ieee1621?  ECMA is newer, with the same basic states as 1621 but
> has additional modes that are relevant to contemporary hardware:
>
> ECMA:
>
>        Off
>        Sleep
>        WoL Sleep
>        ShortIdle
>        LongIdle
>        Active
>
> 1621:
>
>        Off
>        Sleep
>        On
>
> here is a proposal for an IANA maintained power state textual convention.
> There are of course other ways of doing this but I thought a concrete
> proposal might help the discussion.
>
> /js
>
> --

-- 
*Bruce Nordman*
Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman
[email-masked]
510-486-7089
m: 510-501-7943

---

From: Brad Schoening <[email-masked]>
Date: Thu, 4 Aug 2011 12:06:42 +0000

Hi Bruce,

The reason I see ECMA offering enhanced power states is their notion of Idle vs Active.   For devices such as a printer, toaster, water heater, or industrial equipment, a device can be "on" in the IEEE 1621 model, but consuming minimal energy vs on and actively consuming its rated load.

As far as exposing these states to management entities, it seems reasonable that an energy management system would like to know when it reads the kW if the device is 'Acitve' or 'Idle'  instead of just 'On'.

ECMA section 5.2 defines 'Power modes'.  It cross references these with many ACPI power states ("For products where ACPI standards are applicable, off mode correlates to ACPI system level S5 state").  As you mention, it does also discuss power measurements in each of these modes.
For example,

"5.2.4 The on mode represents the mode the EUT is in when not in the sleep or off modes. The on mode has several sub-modes that include the long idle mode, the short idle mode and the active (work) mode."

The 6 modes in the ECMA model offer a richer, but yet still concise model that can fill the gap between the rudimentary 1621's 3 states and the proposed 12 states in the EMAN model while at the same time harmonizing with those other models.
Finally, while ECMA was targeted at desktop and notebook PC's, their modes seem equally applicable to intelligent devices managed with embedded controllers.

Regards,

Brad

From: Bruce Nordman [mailto:[email-masked]]
Sent: Thursday, August 04, 2011 1:21 AM
To: Brad Schoening
Cc: [email-masked]
Subject: Re: [eman] iana powerstate tc proposal

--Bruce
On Tue, Aug 2, 2011 at 7:01 PM, Brad Schoening <[email-masked]<mailto:[email-masked]>> wrote:
Hi Juergen,

ECMA:

       Off
       Sleep
       WoL Sleep
       ShortIdle
       LongIdle
       Active

1621:

       Off
       Sleep
       On

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Juergen Schoenwaelder
Sent: Thursday, July 28, 2011 12:45 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [eman] iana powerstate tc proposal

Hi,

/js

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587<tel:%2B49%20421%20200%203587>         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103<tel:%2B49%20421%20200%203103>         <http://www.jacobs-university.de/>
_______________________________________________
eman mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eman

--
Bruce Nordman
Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman<http://eetd.lbl.gov/ea/nordman>
[email-masked]
510-486-7089
m: 510-501-7943

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 Aug 2011 20:54:22 +0200

> because numbers for states and sets would be registered at IANA and not in the TC.

IANA would manage the MIB module with TC and this has been working
well for years with other number spaces IANA manages, for example the
interface type TC. IANA does any magic needed once specified. I
actually find it highly useful to have concrete named-numbers
allocated.

> for the final values to be chosen.

Exactly. I blindly copied values from draft-claise-energy-monitoring-mib-09.txt 
from demonstration purposes. The energy management experts need to find out
what suitable power state series are - I am just a MIB guy.

/js

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 5 Aug 2011 09:29:36 +0200

> actually find it highly useful to have concrete named-numbers

I know the procedure.
Yes, that's a clean solution.

Thanks,

    Juergen

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Mon, 15 Aug 2011 13:40:12 -0500

>From my perspective allowing for a given device to support multiple power state sets simultaneously we are improving/enabling increased interoperability by allowing the EnMS interact with the device using it's preferred power state set.  Some EnMS may only support a single power state set, for example, so allowing the device to support multiple power state sets increases the number of EnMS which can interoperate with the device.

Regarding the "magic" mapping between the power states within the various sets supported by a device, the core assumption (perhaps this needs to be made explicit) is that if a device chooses to support multiple power state sets that it must do so in such a way that the device operates in a sensible manner within the individual contexts of each power state set it supports.  It is impossible to define a universally applicable mapping for this but within the context of a given device a sensible mapping may certainly be possible.  If it is, then the device can choose to support that mapping and the various EnMS can safely interact with it using any of the available power state sets.