Subject: Re: [eman] eman requirements: "max/average" to "typical"

From: Juergen Quittek <[email-masked]>
Date: Mon, 1 Oct 2012 11:30:02 +0000

Hi Daniel,

So what is your recommnedation: Only have a "typical" power value for a
power state?

Thanks,
    Juergen

On 29.09.12 04:24, "Daniel Kharitonov" <[email-masked]> wrote:

>
>If I may have one comment on power state in network devices, I would say
>they are neither linear nor can be fully described with maximum and
>average power use.
>
>The needed descriptive strings for power states should be at least
>expressed as changes in operational properties - performance, latency and
>such. A less obvious but critical parameter would the time to transition
>in/out of this state.
>
>Example 1.
>
>A switch consists of interfaces, fabric, lookup engines and power
>supplies. Each group of components may have one or more dimensions of
>power states that can be changed independently.
>
>Note, that the knowledge of own power use for a group of components can
>be incomplete and/or not sum up to a full system.
>
>Example 2.
>
>EnNMS is discovering a device that reports a set of power states along
>with max/average power use. Since device describes neither performance
>targets nor times to transition between them, EnNMS can only make a
>decision based on desired power use in the device. This may lead to
>mismatch between power state and device usability.
>
>________________________________________
>From: [email-masked] on behalf of Juergen Quittek
>Sent: Thursday, September 27, 2012 11:45:14 AM
>To: John Parello (jparello); eman mailing list
>Subject: Re: [eman] eman requirements: "max/average" to "typical"
>
>Hi John,
>
>Thank you for your comment.  This would look like
>
>OLD
>   5.4.6.  Maximum and average power per Power State
>
>   The standard must provide means for retrieving the maximum power and
>   the average power for each supported Power State.  These values may
>   be static.
>
>NEW
>   5.4.6. Maximum and typical power per Power State
>
>   The standard must provide means for retrieving the maximum power and
>   the typical power for each supported Power State.
>
>I don't think we need the sentence on values being static.
>
>
>Who would have a problem with this version?
>
>Thanks,
>    Juergen
>
>
>On 27.09.12 19:14, "John Parello (jparello)" <[email-masked]> wrote:
>
>>HI Juergen,
>>
>>Thanks. I agree that typical is more useful than average but you  threw
>>out max.
>>
>>In our implementations each power state has a maximum value that the
>>device will use for that state. Typical  and average is too lose a term
>>for management.
>>
>>If I have three power states say low, medium, high and the device reports
>>typical power as 10,20, and 30W. I have no way of knowing that if I set
>>the device to low it will not exceed the 10W and run at  30W.
>>
>>We implemented the Max to allow device vendors to give specifics so that
>>the mgt stations can have a hope of controlling the aggregate power. If
>>you loosen the requirement to typical you effectively have no predictable
>>control.
>>
>>Having Max is also in line with the way PoE states are communicated where
>>depending on which PoE spec you implement you give 3 or 5 states and give
>>the maximum at each state.
>>
>>So yes on typical over average but you must have  max as well.
>>
>>Jp
>>
>>
>>
>>
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>>Juergen Quittek
>>Sent: Thursday, September 27, 2012 5:17 AM
>>To: eman mailing list
>>Subject: [eman] eman requirements: "max/average" to "typical"
>>
>>Dear all,
>>
>>Here is an issue from discussing received comments on the eman
>>requirements:
>>
>>The current version asks for means for reporting maximum and average
>>power for each power state.  The comment raised the point that these may
>>not be well defined.  Mouli and I discussed this and came up with the
>>following
>>proposal:
>>
>>OLD
>>   5.4.6.  Maximum and average power per Power State
>>
>>   The standard must provide means for retrieving the maximum power and
>>   the average power for each supported Power State.  These values may
>>   be static.
>>
>>NEW
>>
>>   5.4.6.  Typical power per Power State
>>
>>   The standard must provide means for retrieving the typical power for
>>   each supported Power State.
>>
>>The assumption is that a "typical" power meets more the requirements by
>>an energy management system and would be more useful than a not well
>>defined "average" value.
>>
>>Please give us your opinions on this proposal.
>>
>>Thanks,
>>    Juergen
>>
>>_______________________________________________
>>eman mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/eman
>
>_______________________________________________
>eman mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/eman
>
>

---

From: Daniel Kharitonov <[email-masked]>
Date: Mon, 1 Oct 2012 14:57:44 +0000

My recommendation is to reconsider the concept of "network device power state" as a hierarchy of functional states to be discovered and used by EnNMS.

The difference is that EnNMS should be setting the minimum functional level of device based on the knowledge of current and future network situation, with energy reduction as a consequence.

In the current proposal, the EnNMS is expected to set the target energy consumption with no way to learn how this setting affects the function. This only works if EnNMS already has extensive understanding of a managed network device and somehow knows all functional restrictions of different power states.

________________________________________
From: Juergen Quittek
Sent: Monday, October 01, 2012 4:30:02 AM
To: Daniel Kharitonov; John Parello (jparello); eman mailing list
Subject: Re: [eman] eman requirements: "max/average" to "typical"

Hi Daniel,

Thanks,
    Juergen

---

From: "John Parello (jparello)" <[email-masked]>
Date: Mon, 1 Oct 2012 23:16:57 +0000

HI,

I agree that any state of a device whether they be power state or operational state needs to have some context of what the device does and the consequences of a change.

What we've found in our implementations and deployments that a simple set of context variables (tags and a role) and a maximum power value for state are enough for a user of an EnNMS (and simple heuristics) to get significant power/energy monitoring and control. We have very sophisticate systems built on these basic attributes.

We've found these to be good enough as  first start. We have deployments with significant savings, response to demands, and scripted controls all based on these values (albeit it primitive)

So I encourage the group to start with just simple context values (see framework), typical power, and maximum power. A full modeling of states and consequences would be nice but I've yet to see a description proposed that would suffice significantly  better than the simple model we've deployed.

Jp

-----Original Message-----
From: Daniel Kharitonov [mailto:[email-masked]] 
Sent: Monday, October 01, 2012 7:58 AM
To: Juergen Quittek; John Parello (jparello); eman mailing list
Subject: Re: [eman] eman requirements: "max/average" to "typical"

Hi Daniel,

So what is your recommnedation: Only have a "typical" power value for a power state?

Thanks,
    Juergen

On 29.09.12 04:24, "Daniel Kharitonov" <[email-masked]> wrote:

>
>If I may have one comment on power state in network devices, I would 
>say they are neither linear nor can be fully described with maximum and 
>average power use.
>
>expressed as changes in operational properties - performance, latency 
>and such. A less obvious but critical parameter would the time to 
>transition in/out of this state.
>
>Example 1.
>
>>Thanks. I agree that typical is more useful than average but you  
>>threw out max.
>>
>>device will use for that state. Typical  and average is too lose a 
>>term for management.
>>
>>If I have three power states say low, medium, high and the device 
>>reports typical power as 10,20, and 30W. I have no way of knowing that 
>>if I set the device to low it will not exceed the 10W and run at  30W.
>>
>>We implemented the Max to allow device vendors to give specifics so 
>>that the mgt stations can have a hope of controlling the aggregate 
>>power. If you loosen the requirement to typical you effectively have 
>>no predictable control.
>>
>>Having Max is also in line with the way PoE states are communicated 
>>where depending on which PoE spec you implement you give 3 or 5 states 
>>and give the maximum at each state.
>>
>>From: [email-masked] [mailto:[email-masked]] On Behalf 
>>Of Juergen Quittek
>>power for each power state.  The comment raised the point that these 
>>may not be well defined.  Mouli and I discussed this and came up with 
>>the following
>>proposal:
>>
>>OLD
>>The assumption is that a "typical" power meets more the requirements 
>>by an energy management system and would be more useful than a not 
>>well defined "average" value.
>>

---

From: Daniel Kharitonov <[email-masked]>
Date: Tue, 2 Oct 2012 00:26:20 +0000

John,

I do see how this approach works for a PC or terminal with standartized and well-known hardware.

OTH, I do not see how it works for a generic network device. I will give an example, so please look at it and respond with your implementation.

Let's say we have a simple switch with redundant PS, lookup NPUs and 802.3az ports.

Even in such a trivial case we have a hierarchy of components and their properties - PS units can be selectively turned off for decreased power capacity, NPU elements can be clock gated for lower performance and 802.3az ports can be programmed for longer transit delays.

If we (a vendor) are designing an energy MIB to manage such device, we cannot uniquely assign state S1 to one programming set (PS, NPUs, ports) and S2 to another and call it a day as the number of possible combinations grows at exponential rate.

But let's say we decided to wrap multi-dimensional internal capabilities of a device to just two states, S1 and S2. Let's assume S1 means reduced number of power supplies for total system power @X watts and S2 means S1 plus half performance and twice the latency @Y watts, X>Y.

Now, a 3rd party EnNMS can discover S1 and S2 but will not know the consequences of S1 and S2 unless there is a mechanism to describe the tradeoffs associated with such states. Thus, EnNMS no longer makes educated decisions. It will either keep the device at S0 or will flip to S2 and risk losing the user traffic.

The issue quickly scales with increased device complexity and modularity as we include fabric planes, routing engines,  and more into the picture.

So my suggestion to the group is to modify the draft with a concept of hierarchies of objects and tradeoff/scope description strings.

If that is not possible, we should at least make this draft compatible with EnNMS framework that goes beyond linear ACPI-style states as the latter are not quite useful for independent NMS developers.

________________________________________
From: John Parello (jparello)
Sent: Monday, October 01, 2012 4:16:57 PM
To: Daniel Kharitonov; Juergen Quittek; eman mailing list
Subject: RE: [eman] eman requirements: "max/average" to "typical"

HI,

Jp

-----Original Message-----
From: Daniel Kharitonov [mailto:[email-masked]]
Sent: Monday, October 01, 2012 7:58 AM
To: Juergen Quittek; John Parello (jparello); eman mailing list
Subject: Re: [eman] eman requirements: "max/average" to "typical"

Hi Daniel,

Thanks,
    Juergen

---

From: Bruce Nordman <[email-masked]>
Date: Mon, 1 Oct 2012 20:56:47 -0700

Apart from this discussion, the "typical" as is being proposed rather than
"average"
seems like a good choice.

Daniel--
  I do appreciate that there are contexts that need the sophistication that
you describe, but I think that that sort of management is really about the
functional purpose of the devices in question first, and energy only
secondary.
I think there are real limits to how much we can or should try to do in an
energy-centric context like EMAN.
  I think that a precise definition of "maximum" would be difficult or more
likely impossible to create that would span the full range of products that
EMAN covers.  The text for "nameplate" that we now have that defines it
as a manufacturer rating I think is the best model we have for this.
--Bruce

On Mon, Oct 1, 2012 at 5:26 PM, Daniel Kharitonov <[email-masked]> wrote:

> OTH, I do not see how it works for a generic network device. I will give
> an example, so please look at it and respond with your implementation.
>
> Even in such a trivial case we have a hierarchy of components and their
> properties - PS units can be selectively turned off for decreased power
> capacity, NPU elements can be clock gated for lower performance and 802.3az
> ports can be programmed for longer transit delays.
>
> If we (a vendor) are designing an energy MIB to manage such device, we
> cannot uniquely assign state S1 to one programming set (PS, NPUs, ports)
> and S2 to another and call it a day as the number of possible combinations
> grows at exponential rate.
>
> But let's say we decided to wrap multi-dimensional internal capabilities
> of a device to just two states, S1 and S2. Let's assume S1 means reduced
> number of power supplies for total system power @X watts and S2 means S1
> plus half performance and twice the latency @Y watts, X>Y.
>
> Now, a 3rd party EnNMS can discover S1 and S2 but will not know the
> consequences of S1 and S2 unless there is a mechanism to describe the
> tradeoffs associated with such states. Thus, EnNMS no longer makes educated
> decisions. It will either keep the device at S0 or will flip to S2 and risk
> losing the user traffic.
>
> The issue quickly scales with increased device complexity and modularity
> as we include fabric planes, routing engines,  and more into the picture.
>
> So my suggestion to the group is to modify the draft with a concept of
> hierarchies of objects and tradeoff/scope description strings.
>
> If that is not possible, we should at least make this draft compatible
> with EnNMS framework that goes beyond linear ACPI-style states as the
> latter are not quite useful for independent NMS developers.
>
>
> I agree that any state of a device whether they be power state or
> operational state needs to have some context of what the device does and
> the consequences of a change.
>
> What we've found in our implementations and deployments that a simple set
> of context variables (tags and a role) and a maximum power value for state
> are enough for a user of an EnNMS (and simple heuristics) to get
> significant power/energy monitoring and control. We have very sophisticate
> systems built on these basic attributes.
>
> We've found these to be good enough as  first start. We have deployments
> with significant savings, response to demands, and scripted controls all
> based on these values (albeit it primitive)
>
> So I encourage the group to start with just simple context values (see
> framework), typical power, and maximum power. A full modeling of states and
> consequences would be nice but I've yet to see a description proposed that
> would suffice significantly  better than the simple model we've deployed.
>
> Jp
>
>
>
>
>
> My recommendation is to reconsider the concept of "network device power
> state" as a hierarchy of functional states to be discovered and used by
> EnNMS.
>
> The difference is that EnNMS should be setting the minimum functional
> level of device based on the knowledge of current and future network
> situation, with energy reduction as a consequence.
>
> In the current proposal, the EnNMS is expected to set the target energy
> consumption with no way to learn how this setting affects the function.
> This only works if EnNMS already has extensive understanding of a managed
> network device and somehow knows all functional restrictions of different
> power states.
>
>

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

---

From: "John Parello (jparello)" <[email-masked]>
Date: Wed, 3 Oct 2012 00:06:58 +0000

HI Daniel,

Thanks I'll try and write up a description of how we do that.

First a question. 
What if the decision of what to turn off, curtail, tradeoff is left to the manufacturer and all you advertise is the capability to reduce?

 That means the EnNMS can simply look at your device spec and if it sees a level which says operate at 80% of maximum then the EnNMS can request that. If the device cannot (because of the complexities) then it could ACK or NAK the request?

In a scheme like that the complexity could be hidden from the EnNMS and left to the device to decide with its context and operational knowledge.

Thinking along those lines would that change your scenario?

Jp

-----Original Message-----
From: Daniel Kharitonov [mailto:[email-masked]] 
Sent: Monday, October 01, 2012 5:26 PM
To: John Parello (jparello); Juergen Quittek; eman mailing list
Subject: Re: [eman] eman requirements: "max/average" to "typical"

John,

HI,

Jp

-----Original Message-----
From: Daniel Kharitonov [mailto:[email-masked]]
Sent: Monday, October 01, 2012 7:58 AM
To: Juergen Quittek; John Parello (jparello); eman mailing list
Subject: Re: [eman] eman requirements: "max/average" to "typical"

Hi Daniel,

Thanks,
    Juergen

---

From: Daniel Kharitonov <[email-masked]>
Date: Wed, 3 Oct 2012 00:23:44 +0000

Hi John,

What you are describing is a perfect case of a single-dimensional tradeoff typical for a PC and quite usable.

NMS discovers there is an opportunity to operated at reduced performance level at given savings and requests this from the managed element. The element transitions or NAKs if unable to do so.

Note that even in such a simple case the knowledge of tradeoff is not built into the EnNMS but read off the element itself.

Sent: Tuesday, October 02, 2012 5:06:58 PM

HI Daniel,

First a question.

Jp

-----Original Message-----
From: Daniel Kharitonov [mailto:[email-masked]]
Sent: Monday, October 01, 2012 5:26 PM
To: John Parello (jparello); Juergen Quittek; eman mailing list
Subject: Re: [eman] eman requirements: "max/average" to "typical"

John,

HI,

Jp

-----Original Message-----
From: Daniel Kharitonov [mailto:[email-masked]]
Sent: Monday, October 01, 2012 7:58 AM
To: Juergen Quittek; John Parello (jparello); eman mailing list
Subject: Re: [eman] eman requirements: "max/average" to "typical"

Hi Daniel,

Thanks,
    Juergen