Subject: Re: [eman] js review of draft-claise-energy-monitoring-mib-07

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Wed, 25 May 2011 03:18:23 -0500

Hi Juergen,

Thanks for your feedback on draft-claise-energy-monitoring-mib-07. 
Please provide us feedback on this updated version
draft-claise-energy-monitoring-mib-08. 

As you have pointed out, POWER-MONITOR-MIB does not require the
implementation of ENERGY-AWARE-MIB. 
The first question is pmPowerIndex and that is determined with or
without the implementation of ENERGY-AWARE-MIB as explained in the
DESCRIPTION clause of this MIB object. 
Secondly, in Section 6, explains the discovery of Power States supported
by a device with / without the implementation of ENERGY-AWARE-MIB. The
use cases, have been moved out
Of this draft.

Changes to pmPowerState now modified to pmPowerOperState and
pmPowerStateEnterReason are not persisted. 

pmEnergyParametersTable is not persisted and all the objects in that
table are read-create objects. Regarding the RowStatus comment, I have
seen MIB designs with RowStatus and 
an explicit StorageType (default - Volatile). There are other examples
of MIBs with Syntax - RowStatus - without StorageType.
http://tools.ietf.org/html/draft-ietf-psamp-mib-06

As you have pointed out, with changes in the MIB design,
pmPowerStateChange notifications are modified now - whenever there are
changes in the following MIB objects - pmPowerStateSeries,
pmPowerStateSeries, pmPowerAdminState, pmPowerOperState,
pmPowerStateEnterReason. 

We do not foresee a need to throttle notifications as of now, unless,
these are notifications are seen as a bottleneck.

Thanks
Mouli

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Juergen Schoenwaelder
Sent: Wednesday, March 30, 2011 2:42 PM
To: [email-masked]
Subject: [eman] js review of draft-claise-energy-monitoring-mib-07

Hi,

here are some review comments for draft-claise-energy-monitoring-mib-07.
I think some of the introductory material is really helpful to
understand
the ENERGY-AWARE-MIB - perhaps that material should be moved to the
other
document.

- It seems POWER-MONITOR-MIB does not require implementation of the
  ENERGY-AWARE-MIB but then it seems all the introductory examples in
  the document assume the ENERGY-AWARE-MIB to be implemented. This is
  kind of confusing, see already my initial comments about moving
  some of this text into the ENERGY-AWARE-MIB document.

- What is the persistency of changes to pmPowerState or
  pmPowerStateEnterReason?

- What is the persistency of pmEnergyParametersTable? Should there
  be a RowStatus column?

- Should the pmPowerStateChange notification also contain the
  pmPowerActualState? Can it be that say pmPowerActualState changes
  without affecting pmPowerManufacturerActualPowerState?  Or can
  pmPowerManufacturerActualPowerState changes without affecting
  pmPowerActualState?

  Right now, the description seems to say the notification is only
  generated if pmPowerManufacturerActualPowerState changes. Can we
  perhaps do away with pmPowerManufacturerActualPowerState? This is
  likely related to the bigger power state discussion...

- How fast can pmPowerStateChange notifications be generated? Is
  there a need to think about a throttling mechanism?

/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/>
_______________________________________________
eman mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/eman

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 25 May 2011 13:46:06 +0200

Hi Mouli, 

You did not answer Juergen's question. How fast can pmPowerStateChange
notifications be generated? How do you assess if they are a bottleneck.
Note that the concern is not that much at the agent, as at the
management application that may connect to hundreds, thousands or more
agents and potentially receive notifications from all or many of these. 

Regards,

Dan 

> Mouli Chandramouli (moulchan)

....

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of

...

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Wed, 25 May 2011 07:03:00 -0500

Hi Dan,

Whenever, the power state of a device changes - there shall be a
notification. 
The underlying assumption is that the time scale of power state change
of devices would be in hours. 

If there are time-of-day based policies for power state change of
devices, there can be synchronization of notifications leading to flash
crowd type of scenario 
at the management station. In that case, there would a need for
throttling the notifications sent to the management application.  There
are some techniques to handle that scenario, I think. 

Thanks
Mouli

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Wednesday, May 25, 2011 5:16 PM
To: Mouli Chandramouli (moulchan); Juergen Schoenwaelder; [email-masked]
Subject: RE: [eman] js review of draft-claise-energy-monitoring-mib-07

Hi Mouli, 

Regards,

Dan 

....

...

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 25 May 2011 14:18:54 +0200

Hi Mouli, 

If the typical rate of change is measured in hours there is no reason of
concern and no need to build in a throtttling mechanism. 

Thanks and Regards,

Dan 

> From: Mouli Chandramouli (moulchan) [mailto:[email-masked]]
> Sent: Wednesday, May 25, 2011 3:03 PM
> To: Romascanu, Dan (Dan); Juergen Schoenwaelder; [email-masked]

---

From: Ira McDonald <[email-masked]>
Date: Wed, 25 May 2011 11:01:14 -0400

Hi,

FWIW - Network printers and multifunction devices typically
go into a low power mode (light sleep) after a few minutes idle.

Then into a lower power mode (deep sleep) after a few more
minutes.

When combined with frequent network print/fax jobs, this
results in power state transitions (and notifications) every
few minutes for each device.

OTOH - Never mind - networks (that are monitoring power)
are fast and we're not talking seconds here.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:[email-masked]
Christmas through April:
  579 Park Place  Saline, MI  48176
  734-944-0094
May to Christmas:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 May 2011 17:53:03 +0200

> are fast and we're not talking seconds here.

Interesting would be situations where network activity causes many
systems to change state simulaneously and even worse causes subsequent
synchronization of the following power state changes.

/js

---

From: "John Parello (jparello)" <[email-masked]>
Date: Wed, 25 May 2011 14:18:34 -0700

One way to mitigate this that I've done with similar implementation is
that the notification is defined as the configured state change. If the
device drops to a lower state on its own as described in the thread no
change is send. Define it as policy change.

That reduces it to measured in hours or days based on policy.

If the other transitions are needed (non -policy change) it's expected
to be hours and worse case minutes so I think we're fine without
explicit throttling and can rely on simple correlation to reduce this
further upstream.

Jp 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Romascanu, Dan (Dan)
Sent: Wednesday, May 25, 2011 5:19 AM
To: Mouli Chandramouli (moulchan); Juergen Schoenwaelder; [email-masked]
Subject: Re: [eman] js review of draft-claise-energy-monitoring-mib-07

Hi Mouli, 

Thanks and Regards,

Dan