Subject: Re: [eman] Comments on draft-ietf-eman-requirements-01

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Wed, 6 Apr 2011 07:11:40 -0500

Hi Bill,

Thanks very much for your detailed comments. I would like to address
your point on battery or energy storage devices - in particular, the
point of possible double counting of energy consumption - when power is
drawn from the grid or from back-up power. In my view, it depends on
where is energy measured. Here is an example. 

Power From Grid -------> (Meter 1) ------>  | UPS    |  ------> (Meter
2)------> 10 Racks ----(Meter M) ---> Rack X -----(Meter N) ----->
Servers
                          33.3 KW            0.9 eff             30 KW

Consider 33.3 KW is drawn from the grid. Let us assume that the UPS has
an efficiency of 0.9. The output of UPS is 30 KW used to feed 10 racks,

where each rack consumes 3 KW. Let us assume there are 10 servers in
each rack, each server consuming 300 Watts. 

The 3.3 KW loss @ UPS can be attributed to AC --> DC --> AC conversion
and that is also used to charge the UPS batteries. Consider,  1.3 KW is
the (AC -> DC -> AC) loss and 
2 KW to charge the UPS batteries. Once the UPS batteries are fully
charged, there is only loss due to conversion and the efficiency of the
UPS is much higher, perhaps 0.96. 

The UPS MIB can be used to measure the power loss at UPS (difference
between Meter 1 and Meter 2).  

If we look at the server + its portion of back-up power as a whole, we
can get 300 Watts per server + 20 watts attributed to UPS per server =
320 Watts. 
In contrast, if we consider the server and the backup as independent
quantities 300 Watts * 1000 = 30 KW for feeding the servers and 3.3 KW
for the UPS. 

When the grid power is ON,  Energy monitoring MIB shall provide a
measurement of 300 Watts per server and UPS MIB could provide 3.3 KW. 
When the grid power is OFF, Energy monitoring MIB shall provide a
measurement of 300 Watts per server, and UPS MIB could provide 0 KW. 

Please let me know your thoughts. 

Thanks
Mouli
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mielke, William F (Bill)
Sent: Tuesday, March 29, 2011 1:30 PM
To: eman mailing list
Subject: [eman] Comments on draft-ietf-eman-requirements-01

Below please find my comments on draft-ietf-eman-requirements-01.  I
also have some minor textual formatting or rewording comments which I
will provide to Benoit directly in a separate email.

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: [email-masked]
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein

-------------------------------------------
Comments on draft-ietf-eman-requirements-01
-------------------------------------------

Section 1:

We should clarify what we mean by "building networks" and "home
networks".  For example, do these networks explicitly include or exclude
things like environmental management systems for heating, air
conditioning, lighting control, etc?

Sections 2.4, 2.5, and 2.6:

It occurs to me that sections 2.4, 2.5, and 2.6 are all simply different
examples of the same "energy proxying scenario".  If we want to call
these out as separate and distinct cases perhaps the sections should be
updated to illustrate why they are unique from one another (i.e. for
reasons other than simply the domain to which the proxying has been
applied).

Section 2.8:

I am not certain on how best to address this point but I believe that
the current thinking relative to batteries may be too narrow in scope.
For example, telephone switching offices often employ huge banks of
batteries which are used to power the entire office when the grid is
unavailable.  Another example is many alternative energy sources also
employ batteries as a fundamental storage facility where accumulated
energy can be saved until needs to be supplied to its connected devices.

Both of these examples extend batteries beyond the simple concept of an
on-board battery embedded within a simple device.  Is this a separate
scenario (e.g. for "energy storage devices") or an example of how the
thinking on the battery scenario may need to be broadened?

Section 3.4.4

The current text states "These devices can consume energy when turned
off or to sleep mode, because in these modes they still can charge their
batteries."

>From an energy consumtion point of view this is not technically correct.
Energy which is used to recharge a battery is not technically consumed
(i.e. used up) but is rather merely transferred and stored for later
use.  The stored energy is only consumed when the device is actually
discharging the battery.  So, the proper way to account for the energy
use of a device is:

Energy(Consumed) = Energy(TransferedFromMains) -
Energy(RemainingInBattery)

Thus, when the device is technically "off" but charging the amount of
energy actually consumed by the device remains unchanged, and when the
main power is off and the device is draining the battery only then is
the energy stored in the battery actually consumed (and is reflected in
the decreasing value of Energy(RemainingInBattery).

So I think that we need to be careful in how we define "energy
consumption".

Section 4:

The text states: "However, the overhead of pull model monitoring is
typically higher than for push model monitoring, particularly when large
numbers of values are to be collected, such as time series of power
values."

I would like to better understand why you are asserting this to be true.
The inherent efficiency of a transfer is not a function of which side
initiates the transfer (i.e. push or pull).  So you must be thinking of
something else or I am misunderstanding the point.

Perhaps you are equating "pull mode" with "polling" vs. "push mode" with
"event driven".  To me these are not equivalent statements so perhaps
that is the source of my concern and/or perhaps I am merely splitting
hairs too finely on this distinction.

Consider an example where readings are pushed 1 per minunte vs. pulled 5
at a time every 5 minutes:

Time -->
+----+----+----+----+----+----+----+----+----+----+----+----+----+----+-
---+
| 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 |
15 |
+----+----+----+----+----+----+----+----+----+----+----+----+----+----+-
---+
     |    |    |    |    |    |    |    |    |    |    |    |    |    |
|
     V    V    V    V    V    V    V    V    V    V    V    V    V    V
V
   PU01 PU02 PU03 PU04 PU05 PU06 PU07 PU08 PU09 PU10 PU11 PU12 PU13 PU14
PU15
                         |                        |
|
                         V                        V
V
                       PL01                     PL06
PL11
                       PL02                     PL07
PL12
                       PL03                     PL08
PL13
                       PL04                     PL09
PL14
                       PL05                     PL10
PL15

Where PUnn is a push mode transfer and PLnn is a pull mode transfer.
Whether I push the values 1 at a time or pull them 5 at a time I still
transfer the same number of values.  So it is unclear to me why you are
saying that the push mode approach is inherently more efficient than the
pull mode approach.

In fact, depending on the transfer protocol being used and the size of
the packets involved I could actually argue that the pull mode approach
is more efficient because it will (or at least it could) involve less
network overhead per reading/unit transfered.

The text states "The only exceptions are notifications on power state
changes and high volume time series of energy consumption values."

Until I better understand why you believe this is true I respectfully
disagree that this is a fundamental implication/conclusion.

So there is some confusion which may need to be cleared up here and I
understand that the confusion may be on my part.  Either way some
additional clarification may be needed in the document to justify the
main conclusions stated there.

Section 7.1.2:

The text states "For associating the provided information to specific
components of a device, the ENTITY STATE MIB module makes use of the
means provided by the ENTITY MIB module [RFC4133]. Particularly, it uses
the entPhysicalIndex for identifying entities.".

This is interesting information which seems to be trying to make a
specific point however the point itself has not been articulated and so
it lost.  Add something to explain the implications of these points.

This section seems to be articulating that the existing ENITITY STATE
MIB facilities are insufficient for our larger purpose.  This naturally
implies that something additional needs to be defined but it is unclear
from the existing text whether extending these existing facilities or
defining new ones is the best approach.  Perhaps that decision is left
to later documents?

_______________________________________________
eman mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/eman

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Wed, 6 Apr 2011 07:43:02 -0500

Hi,

Regarding the comment on pull vs push. Here are some comments. 

As a requirements document, there is (and there should be) no
requirement for energy monitoring advocating a pull  or a push model. 

In simple terms, in a pull model, there are two messages,  a request
(SNMP GET) and a response;  whereas in PUSH,  there is only one message
(response) reporting. 

Given the information model, it is up to the implementers to decide to
use PULL or PUSH model. 

Thanks
Mouli

-----Original Message-----

William F. Mielke
Alcatel-Lucent

    - Albert Einstein

Section 1:

Section 2.8:

Section 3.4.4

Section 4:

Time -->

Section 7.1.2: