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

Daniel Kharitonov <dkh@juniper.net> Thu, 09 February 2012 19:31 UTC

Return-Path: <dkh@juniper.net>
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D23121E8042 for <eman@ietfa.amsl.com>; Thu, 9 Feb 2012 11:31:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.524
X-Spam-Level:
X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkwDn8Nec3Wu for <eman@ietfa.amsl.com>; Thu, 9 Feb 2012 11:31:50 -0800 (PST)
Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC8221E8021 for <eman@ietf.org>; Thu, 9 Feb 2012 11:31:49 -0800 (PST)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTzQfI+09vEKndd8dgtsLwXqbt4N+C74X@postini.com; Thu, 09 Feb 2012 11:31:50 PST
Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 9 Feb 2012 11:29:57 -0800
From: Daniel Kharitonov <dkh@juniper.net>
To: Ira McDonald <blueroofmusic@gmail.com>, "Mouli Chandramouli (moulchan)" <moulchan@cisco.com>
Date: Thu, 09 Feb 2012 11:29:57 -0800
Thread-Topic: [eman] Feedback on draft-ietf-eman-requirements-05
Thread-Index: AcznRkHFLOm97g2NQ0m1nkFNNOkQEwAGMK+T
Message-ID: <14803CE6B7CFE0439D9346D27557A82A5967AFEB27@EMBX02-HQ.jnpr.net>
References: <14803CE6B7CFE0439D9346D27557A82A5967AFEB1E@EMBX02-HQ.jnpr.net> <E9B25823FA871E4AA9EDA7B163E5D8A907848F61@XMB-RCD-106.cisco.com>, <CAN40gSvrLuTug3DUJQh=oRwHrbYafrRY8AUztHbRwROCqC4avg@mail.gmail.com>
In-Reply-To: <CAN40gSvrLuTug3DUJQh=oRwHrbYafrRY8AUztHbRwROCqC4avg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-exclaimer-md-config: e4081efb-6d29-443c-8708-750833aec629
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "quittek@neclab.edu" <quittek@neclab.edu>, "eman@ietf.org" <eman@ietf.org>
Subject: Re: [eman] Feedback on draft-ietf-eman-requirements-05
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group <eman.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eman>, <mailto:eman-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/eman>
List-Post: <mailto:eman@ietf.org>
List-Help: <mailto:eman-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eman>, <mailto:eman-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Feb 2012 19:31:51 -0000

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.


> And this MIB defines explicit light sleep (Standby) and deep
> 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 [blueroofmusic@gmail.com]
Sent: Thursday, February 09, 2012 8:16 AM
To: Mouli Chandramouli (moulchan); Ira McDonald
Cc: Daniel Kharitonov; quittek@neclab.edu; eman@ietf.org
Subject: Re: [eman] Feedback on draft-ietf-eman-requirements-05

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:blueroofmusic@gmail.com<mailto:blueroofmusic@gmail.com>
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434



On Thu, Feb 9, 2012 at 6:42 AM, Mouli Chandramouli (moulchan) <moulchan@cisco.com<mailto:moulchan@cisco.com>> wrote:

Hello Daniel,

Reply inline.

Thanks
Mouli

-----Original Message-----
From: eman-bounces@ietf.org<mailto:eman-bounces@ietf.org> [mailto:eman-bounces@ietf.org<mailto:eman-bounces@ietf.org>] On Behalf Of
Daniel Kharitonov
Sent: Wednesday, February 08, 2012 7:43 AM
To: quittek@neclab.edu<mailto:quittek@neclab.edu>
Cc: eman@ietf.org<mailto:eman@ietf.org>
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:


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.

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
eman@ietf.org<mailto:eman@ietf.org>
https://www.ietf.org/mailman/listinfo/eman
_______________________________________________
eman mailing list
eman@ietf.org<mailto:eman@ietf.org>
https://www.ietf.org/mailman/listinfo/eman