Subject: [eman] Feedback on draft-ietf-eman-requirements-05

From: Daniel Kharitonov <[email-masked]>
Date: Tue, 7 Feb 2012 18:13:17 -0800

Apologies if this has surfaced before as I did not have time to read the full eman discussions archive.
I have two notes regarding the aforementioned draft:

1) Section 3.1 lists the following state "sleep state (not functional, but immediately available)"

This seems to be a contradictory description. If a system is immediately available, it is able to transition to full load instantly, in real time. Typically, a ready state with no load is called "idle state". Henceworth, "sleep state" should mean some sort of a deep power-saving mode that requires a "wake-up" with no requirement for immediate availability. 

It would be good to clarify what the authors meant to say here.

2) Section 5.2 "Power State"

Since the document correctly links reduced power states to tradeoffs in performance, service or capacity, it would be logical to report the characteristics of available states along same lines.

For example, an operator of energy NMS might be interested in knowing that device supports not only power states A, B, C with expected consumption {a,b,c} watts but also operates at {100,50,30} capacity in those with expected in-out transition time not to exceed X/Y seconds.

Merely describing power states in not enough as energy savings in reduced power states must be necessarily weighted against the drawbacks.

--
Daniel Kharitonov
Juniper Networks Inc
1194 N Mathilda Ave
Sunnyvale CA

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Thu, 9 Feb 2012 05:42:08 -0600

Hello Daniel,

Reply inline. 

Thanks
Mouli

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Daniel Kharitonov
Sent: Wednesday, February 08, 2012 7:43 AM
To: [email-masked]
Cc: [email-masked]
Subject: [eman] Feedback on draft-ietf-eman-requirements-05

Apologies if this has surfaced before as I did not have time to read the
full eman discussions archive.
I have two notes regarding the aforementioned draft:

Since the document correctly links reduced power states to tradeoffs in
performance, service or capacity, it would be logical to report the
characteristics of available states along same lines.

For example, an operator of energy NMS might be interested in knowing
that device supports not only power states A, B, C with expected
consumption {a,b,c} watts but also operates at {100,50,30} capacity in
those with expected in-out transition time not to exceed X/Y seconds.

YCM>> Currently from a requirements point of view, for every entity, we
have requirements to report the power state of an entity, (req. 5.2.1), 
YCM>> its power consumption (req. 5.4.1) and statistics for each power
state (req. 5.2.6.)
YCM>> There are notifications when power states changes occur (req
5.2.8) and from the time stamps of notifications, it should be possible
to estimate the transition times. 
YCM>> As of now, we do not have requirements on the transition times
from a power state to another state. 

Merely describing power states in not enough as energy savings in
reduced power states must be necessarily weighted against the drawbacks.

YCM>> The energy management standard provides the data and I would think
the network manager should make the trade-offs from the information ? 

--
Daniel Kharitonov
Juniper Networks Inc
1194 N Mathilda Ave
Sunnyvale CA
_______________________________________________
eman mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/eman

---

From: Ira McDonald <[email-masked]>
Date: Thu, 9 Feb 2012 11:16:51 -0500

Hi Daniel,

Relevant to your questions, you might want to look at our IEEE-ISTO
Printer Working Group candidate standards for Printers and MFDs:

"Power Management Model for Imaging Systems v1.0"
ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspower10-20110214-5106.4.pdf

"PWG Imaging System Power MIB v1.0"
ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.pdf

"PWG-IMAGING-SYSTEM-POWER-MIB" - ASN.1 source
ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.mib

The PowerLog group defines a FIFO list of state transitions
with time stamps.

The PowerTrap group defines a notification to report state
transitions.

The PowerSupport group defines objects about the capabilities
of the device (or component/subunit) in a given state.

The PowerTransition group defines objects for nominal state
transition times between any two supported power states.

The Power[Calendar/Timeout/Event] groups define objects for
configured power transitions for device or component based
on calendar (like IETF Schedule MIB), timeout, or event
triggers.

BTW - This MIB uses the standard DMTF CIM power states,
but allows vendor extension substates (e.g., fine-grained
Suspend substates).

And this MIB defines explicit light sleep (Standby) and deep
sleep (Suspend) states and their standard behaviors - note that
Bruce Nordman does not like the use of these terms, but all
Printers/MFDs that support power management have always
made this distinction in the their private MIBs and embedded
web servers.

Cheers,
- Ira (editor of the PWG power standards)

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
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]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

---

From: Daniel Kharitonov <[email-masked]>
Date: Thu, 9 Feb 2012 11:29:57 -0800

Hi Ira,

Thanks for the links.

IM> The PowerTransition group defines objects for nominal state
IM> transition times between any two supported power states.

Yes, this is what's relevant because estimate based on timestamps is reactive figure.
If an NMS operator makes a decision about changing the power states, she should at least have idea of nominal tradeoffs before the state is engaged.

> sleep (Suspend) states and their standard behaviors 

I don't think we can cover the entire range of ICT devices merely based on definitions for printers.
In fact, while being strictly non-realtime systems, imaging devices might be merely a subset of the proposed scope of effort.

Generally speaking, an abstract ICT system may have N explicit power states, in each of which certain minimal characteristics (performance, QoS etc) are preserved.
For instance, if a device has states ranked according to {performance, transition time to full capacity} tuple, state {100,0} would be immediately available, 100% operational, while {0, 10s} may correspond to printer's standby and {0,100s) may correspond to printer's "suspend".

Along the same lines, a realtime device may never have {0, XX} states defined but sport a range of {XX, YY} modes suited to various modes of usage.

________________________________________
From: Ira McDonald [[email-masked]]
Sent: Thursday, February 09, 2012 8:16 AM
To: Mouli Chandramouli (moulchan); Ira McDonald
Cc: Daniel Kharitonov; [email-masked]; [email-masked]
Subject: Re: [eman] Feedback on draft-ietf-eman-requirements-05

Hi Daniel,

Cheers,

mailto:[email-masked]<mailto:[email-masked]>

On Thu, Feb 9, 2012 at 6:42 AM, Mouli Chandramouli (moulchan) <[email-masked]<mailto:[email-masked]>> wrote:

Hello Daniel,

Reply inline.

Thanks
Mouli

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
Daniel Kharitonov
Sent: Wednesday, February 08, 2012 7:43 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [eman] Feedback on draft-ietf-eman-requirements-05

--
Daniel Kharitonov
Juniper Networks Inc
1194 N Mathilda Ave
Sunnyvale CA
_______________________________________________
eman mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eman
_______________________________________________
eman mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eman

---

From: Benoit Claise <[email-masked]>
Date: Mon, 13 Feb 2012 10:15:55 +0100

Hi Daniel,

Thanks for your feedback.
See in line.
> For example, an operator of energy NMS might be interested in knowing that device supports not only power states A, B, C with expected consumption {a,b,c} watts but also operates at {100,50,30} cap…
Do you believe that this should be part of the EMAN framework (and 
therefore part of the Enegy Objects)? Or can we assume that this is done 
by the EnNMS?

I mean: let's imagine that we want this functionality in the EMAN 
framework. Taking back your sentence:

      an operator of energy NMS might be interested in knowing that device supports not only power states A, B, C with expected consumption {a,b,c} watts but also operates at {100,50,30} capacity in those with expected in-out transition time not to exceed X/Y seconds.

What is the capacity? QoS? Cpu? Energy consumption? Packets/s for a router?
Basically, it depends: energy object type, device function, parameters 
to optimize, etc...

So shouldn't leave this task to the EnNMS...

Regards, Benoit.

---

From: Daniel Kharitonov <[email-masked]>
Date: Mon, 13 Feb 2012 11:11:14 -0800

Hi Benoit,

Thanks for the reply.

Yes, I believe the parameters of power states should reside in EMAN framework, not in enNMS.

This is because such parameters are specific to hardware and software of the network entity, so it is natural to keep them there, especially in multi-vendor environment.

So far we have practically identified performance (in percent) and time to transition between states as leading modalities.

However, I think we should design EMAN in such way that more parameters can be added if needed to describe multidimensional power states.

Let's construct an example.

An enterprise switch may have two main power states - 100 percent throughput (state 0) and 50 percent throughput (state 1). It may take 10 seconds to change from 0->1 and 20 seconds to 1->0. Since enNMS is not aware of this, a switch must report its capabilities to management.

However, it may also have an option to enable additional power savings based on IEEE 802.3az with various time parameters.

So altogether we may have states 0.0, 0.1, 1.0, 1.1 based on throughput and increasing delay (in ms).

From: Benoit Claise [mailto:[email-masked]]
Sent: Monday, February 13, 2012 01:15 AM
To: Daniel Kharitonov
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [eman] Feedback on draft-ietf-eman-requirements-05

Hi Daniel,

Do you believe that this should be part of the EMAN framework (and therefore part of the Enegy Objects)? Or can we assume that this is done by the EnNMS?

I mean: let's imagine that we want this functionality in the EMAN framework. Taking back your sentence:

What is the capacity? QoS? Cpu? Energy consumption? Packets/s for a router?
Basically, it depends: energy object type, device function, parameters to optimize, etc...

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Fri, 17 Feb 2012 15:30:27 +0100

Hi Daniel,
> This is because such parameters are specific to hardware and software 
> of the network entity, so it is natural to keep them there, especially 
> in multi-vendor environment.
>
> So far we have practically identified performance (in percent) and 
> time to transition between states as leading modalities.
What does the performance mean?
Performance in term of Energy consumption? Throughput? CPU? Services? 
Component in sleep mode? something else?
Basically, it depends how you want to optimize your device. So not as 
simple as simply "performance"

Regards, Benoit.

>
> However, I think we should design EMAN in such way that more 
> parameters can be added if needed to describe multidimensional power 
> states.
>
> An enterprise switch may have two main power states - 100 percent 
> throughput (state 0) and 50 percent throughput (state 1). It may take 
> 10 seconds to change from 0->1 and 20 seconds to 1->0. Since enNMS is 
> not aware of this, a switch must report its capabilities to management.
>
> However, it may also have an option to enable additional power savings 
> based on IEEE 802.3az with various time parameters.
>
> *From*: Benoit Claise [mailto:[email-masked]]
> *Sent*: Monday, February 13, 2012 01:15 AM
> *To*: Daniel Kharitonov
> *Cc*: [email-masked] <[email-masked]>; [email-masked] 
> <[email-masked]>
> *Subject*: Re: [eman] Feedback on draft-ietf-eman-requirements-05
>
> Hi Daniel,
>
> therefore part of the Enegy Objects)? Or can we assume that this is 
> done by the EnNMS?
>

---

From: Daniel Kharitonov <[email-masked]>
Date: Fri, 17 Feb 2012 12:51:31 -0800

Hi Benoit,

> Performance in term of Energy consumption? Throughput? CPU? Services? Component in sleep mode? something else?

For eman purposes, performance equates "useful work" as defined in energy efficiency metrics for this device class, such as ATIS TEER.
This is, indeed, very simple.

Cheers.

________________________________________
From: Benoit Claise [[email-masked]]
Sent: Friday, February 17, 2012 6:30 AM
To: Daniel Kharitonov
Cc: [email-masked]'; [email-masked]'
Subject: Re: [eman] Feedback on draft-ietf-eman-requirements-05

Hi Daniel,

Hi Benoit,

Thanks for the reply.

So far we have practically identified performance (in percent) and time to transition between states as leading modalities.
What does the performance mean?
Performance in term of Energy consumption? Throughput? CPU? Services? Component in sleep mode? something else?
Basically, it depends how you want to optimize your device. So not as simple as simply "performance"

Regards, Benoit.

From: Benoit Claise [mailto:[email-masked]]
Sent: Monday, February 13, 2012 01:15 AM
To: Daniel Kharitonov
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: Re: [eman] Feedback on draft-ietf-eman-requirements-05

Hi Daniel,

Regards, Benoit.