Subject: [eman] Requirements comments

From: Bruce Nordman <[email-masked]>
Date: Wed, 1 Aug 2012 12:18:05 -0700

Comments on Requirements-08
Bruce Nordman
July 31, 2012

Many thanks to the authors for advancing the draft.

 "Aggregate" or "aggregation" is used to reflect grouping of entities, as
well
as to summation across such a group.  It can also refer to a quantity which
is inherently a summed quantity, such as a measurement of power being
delivered to a collection of devices.  We need a term for each of these
concepts and assure that they are used consistently in all drafts.
I would propose "Collection" for the process of creating a group of
measurements, and "summation" for adding up values across a collection.

An entity as defined here is either a device or a component.  Interfaces are
not mentioned.  I think that some of the references should really apply only
to devices, others to devices or components, some to all three, and some to
either a device or interface.  We need to be specific as to whether an
interface
is included in "entity" (I think it should be) and it may be helpful to
have a
terms that cover other groupings.
  An example where this may be important is that reference is made to
communication with entities.  Can the management system communicate
with a component, or only with an entire device?
  I think a definition of component would also be helpful - something like
"an entity that is a subset of a device".

In the Introduction, the concept of Power Interface has not yet been defined
so that referring to inlets and outlets seems quite appropriate.  However,
once we have the interface notion, then inlet and outlet should only be
used when interface is not suitable, as they are not different concepts, but
only whether the power value is positive or negative.  This applies in
several
places but particularly 5.2.  Along these lines, 5.2.2 and 5.2.3 need to be
combined, since as an interface can change inlet/outlet state dynamically,
the connections are simply to other interfaces.  Also, connections can be
to multiple other interfaces and commonly are (the language implies only
a 1:1 relationship).  For 5.2.5, need only say that power is flowing --
there
is no need to reference the direction.

3.1. I disagree that "full" and "reduced" are different power states -
there is
a continuum of levels within the fully on state - there are three basic
types
of power states in general.

5.1.3,5.1.4.  I don't think these are well enough defined to be included and
would drop both.

The definition of Domain should be imported.  It should be made clear if
a device can be a member of multiple domains or only a single domain.

5.2.6.  "… as well as for entire Powered Entity".  Why include this phrase?
The entity may or may not have a single type, and this is duplicative of
information available elsewhere.

5.3.3.  With the accuracy data available, it seems unnecessary to include
the measurement method.

5.4.6.  Maximum and average both seem ill-defined and not necessary
to include.  (Also, I think "typical" would be a better term than "average"
for this type of usage).

5.5.2.  "Time Interval" seems to imply a specific implementation and seems
to exclude the simple "meter reading" approach (like a vehicle odometer)
so "Time Stamp" or similar term would be more generic.  That is needed
regardless.

5.6.  Shouldn't the text refer to modeling the battery as an individual
component
rather than an entity?

7.5.  If we require to indicate what data are available in reports on other
devices, shouldn't we require the same mechanism for reporting on oneself?

7.6.  This seems problematic - I would remove.  How would a device know
what other devices know?  why should we assume such knowledge is correct?
Wouldn't it be better to simply ask the other device what it knows?

A.2.  This section, on standards of other bodies, is already covered by the
applicability statement, which does this more thoroughly.  Thus, this
section can be removed and the entire appendix be about Existing IETF
standards.

Minor points:
--Does "Power State" need to be capitalized?  I can see the sense for
  Entity and Interface.
--3.3., last sentence.  Add "functional" before "load" to distinguish this
  from electrical load.
--6.2. "outlets" to "interfaces".
--8. "controlling Power State or power supply of others" to "doing that
control".
--8.1.1.  Move "other" after "Powered Entities".
--References: Applicability statement has an incorrect author.

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

---

From: Brad Schoening <[email-masked]>
Date: Wed, 1 Aug 2012 14:30:26 -0500

3.1. I disagree that "full" and "reduced" are different power states - there is
a continuum of levels within the fully on state - there are three basic types
of power states in general.

Bruce, as we have discussed at great length, there are many operational states that are supported by real, deployed systems.   EMAN will be less useful if it willfully ignores these.  This was the motivation behind the proposal to add IANA power states.  I thought we had reached consensus on this, did we not?

Windows Mobile (CE) has "Full on" and "Low on"
http://msdn.microsoft.com/en-us/library/aa932261.aspx

Windows 7 has by default three: "Balanced", "Power saver", "High performance"

http://windows.microsoft.com/en-us/windows-vista/Power-plans-frequently-asked-questions

Regards,

Brad

---

From: Bruce Nordman <[email-masked]>
Date: Wed, 1 Aug 2012 12:37:36 -0700

The section in question in the requirements draft refers to "basic types of
power states".
I fully agree that many devices have a wide range of sub-states so that a
full list of
states for a particular device might be one or might be dozens long.
However, this is about "basic types" which groups these into a much smaller
number.

The Windows 7 items below are not power states, but policies implemented by
a device to manage how to move among power states and otherwise manage
resources.

--Bruce

On Wed, Aug 1, 2012 at 12:30 PM, Brad Schoening <[email-masked]> wrote:

> Bruce, as we have discussed at great length, there are many operational
> states that are supported by real, deployed systems.   EMAN will be less
> useful if it willfully ignores these.  This was the motivation behind the
> proposal to add IANA power states.  I thought we had reached consensus on
> this, did we not?
>
>

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Wed, 1 Aug 2012 21:34:20 +0000

Hello Bruce,

Thanks for your comments. Replies inline.

Mouli

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bruce Nordman
Sent: Thursday, August 02, 2012 12:48 AM
To: eman mailing list
Subject: [eman] Requirements comments

 "Aggregate" or "aggregation" is used to reflect grouping of entities, as well
as to summation across such a group.  It can also refer to a quantity which
is inherently a summed quantity, such as a measurement of power being
delivered to a collection of devices.  We need a term for each of these
concepts and assure that they are used consistently in all drafts.
I would propose "Collection" for the process of creating a group of
measurements, and "summation" for adding up values across a collection.
[ycm] This is much discussed and clarified in the framework.

An entity as defined here is either a device or a component.  Interfaces are
not mentioned.  I think that some of the references should really apply only
to devices, others to devices or components, some to all three, and some to
either a device or interface.  We need to be specific as to whether an interface
is included in "entity" (I think it should be) and it may be helpful to have a
terms that cover other groupings.
  An example where this may be important is that reference is made to
communication with entities.  Can the management system communicate
with a component, or only with an entire device?
[ycm] We are trying to list the physical objects that consume power. Entities and components of entities (of network devices) are defined as in Entity MIB.
[ycm] For e.g. line cards and ports have IP addresses and management system can directly communicate with those component.
[ycm] Does an "interface" as you have defined consume power ?

In the Introduction, the concept of Power Interface has not yet been defined
so that referring to inlets and outlets seems quite appropriate.  However,
once we have the interface notion, then inlet and outlet should only be
used when interface is not suitable, as they are not different concepts, but
only whether the power value is positive or negative.  This applies in several
places but particularly 5.2.  Along these lines, 5.2.2 and 5.2.3 need to be
combined, since as an interface can change inlet/outlet state dynamically,
the connections are simply to other interfaces.  Also, connections can be
to multiple other interfaces and commonly are (the language implies only
a 1:1 relationship).  For 5.2.5, need only say that power is flowing -- there
is no need to reference the direction.
[ycm] actually, I am not sure we need these notions of power inlet and power outlets in the requirements draft.

3.1. I disagree that "full" and "reduced" are different power states - there is
a continuum of levels within the fully on state - there are three basic types
of power states in general.
[ycm] there are several standards, ACPI, DMTF which have much more than 3 power states for devices

5.1.3,5.1.4.  I don't think these are well enough defined to be included and
would drop both.
[ycm] This was discussed exhaustively on the list on the need for these attributes.
 http://www.ietf.org/mail-archive/web/eman/current/msg01230.html
[ycm] power priority is used by other standard such as rfc 3621.

5.2.6.  "... as well as for entire Powered Entity".  Why include this phrase?
The entity may or may not have a single type, and this is duplicative of
information available elsewhere.

5.3.3.  With the accuracy data available, it seems unnecessary to include
the measurement method.
[ycm] I think it is quite useful to know how the measurement is obtained.

5.6.  Shouldn't the text refer to modeling the battery as an individual component
rather than an entity?

A.2.  This section, on standards of other bodies, is already covered by the
applicability statement, which does this more thoroughly.  Thus, this
section can be removed and the entire appendix be about Existing IETF standards.
[ycm] Actually, the text s is complimentary to what Is covered Applicability statement and provides a good motivation why we need a new IETF standards Energy monitoring.

Minor points:
--8. "controlling Power State or power supply of others" to "doing that control".

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

---

From: Brad Schoening <[email-masked]>
Date: Wed, 1 Aug 2012 23:31:33 -0500

Hi Bruce,

The four basic power states came, in large part, from ECMA :

    4.1.4. Ecma SDC (http://tools.ietf.org/html/draft-ietf-eman-applicability-statement-01)

        The Ecma International committee on Smart Data Centre (TC38-TG2
        SDC [Ecma-SDC<http://tools.ietf.org/html/draft-ietf-eman-applicability-statement-01#ref-Ecma-SDC>]) is in the process of defining semantics for
        management of entities in a data center such as servers,
        storage, and network equipment.  It covers energy as one of many
        functional resources or attributes of systems for monitoring and

        control. It only defines messages and properties, and does not
        reference any specific protocol. Its goal is to enable
        interoperability of such protocols as SNMP, BACNET, and HTTP by
        ensuring a common semantic model across them. Four power states
        are defined, Off, Sleep, Idle and Active. The standard does not        include actual energy or power measurements in kWor kWh.

Indeed, a paper you co-authored "Skilled in the Art of Being Idle", 2009 shows the same four power states in Figure 1: "Off, Sleep, Idle, On".  [http://tier.cs.berkeley.edu/docs/nedevschi_nsdi09.pdf]

Re-reading your email, I believe you are probably not critiquing section 5.4 of the Requirements which would allow multiple operational power state levels (or which could be states, polices, etc).

 (http://tools.ietf.org/html/draft-ietf-eman-requirements-08) :

5.4<http://tools.ietf.org/html/draft-ietf-eman-requirements-08#section-5.4>.  Power State

   Many entities have a limited number of discrete Power States.

   There is a need to report the actual Power State of an entity, and
   means for retrieving the list of all supported Power States.

   Different standards bodies have already defined sets of Power States
   for some entities, and others are creating new Power State sets.  In
   this context, it is desirable that the standard support many of these
   power state standards.  In order to support multiple management
   systems possibly using different Power State sets, while
   simultaneously interfacing with a particular entity, the energy
   management standard must provide means for supporting multiple Power
   State sets used simultaneously at an entity.

   Power States have parameters that describe its properties.  It is
   required to have standardized means for reporting some key
   properties, such as average power and maximum power of an entity in a
   certain state.

   There also is a need to report statistics on Power States including
   the time spent and the received and provided energy in a Power State.

Brad Schoening
Engineering | Coraid
Tel: +1 917 304 7190
[email-masked] | www.coraid.com<http://www.coraid.com>
Coraid: Redefining Storage

From: Bruce Nordman <[email-masked]<mailto:[email-masked]>>
Date: Wed, 1 Aug 2012 14:37:36 -0500
To: Brad Schoening <[email-masked]<mailto:[email-masked]>>
Cc: eman mailing list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [eman] Requirements comments

The section in question in the requirements draft refers to "basic types of power states".
I fully agree that many devices have a wide range of sub-states so that a full list of
states for a particular device might be one or might be dozens long.
However, this is about "basic types" which groups these into a much smaller number.

--Bruce

On Wed, Aug 1, 2012 at 12:30 PM, Brad Schoening <[email-masked]<mailto:[email-masked]>> wrote:

Regards,

Brad

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