Hello Jari,
many thanks for your review comments, much appreciated! I just posted
an updated revision -02 which takes your comments into account, here:
https://datatracker.ietf.org/doc/html/draft-cx-opsawg-green-metrics-02.
Some quick inline replies below. I am cc'ing opsawg, since this is the
WG that will hopefully serve as a landing spot.
--- Alex
On 2/15/2024 6:11 AM, Jari Arkko wrote:
Hi,
I gave a quick read to
https://datatracker.ietf.org/doc/html/draft-cx-opsawg-green-metrics-01 and
had some questions and comments:
Overall, an interesting and useful document.
We furthermore distinguish between primary metrics which are
directly measured, and derived metrics which are computed from
multiple factors.
Question: is there also ”stated” metrics vs. measured metrics, e.g.,
per the manufacturer’s declaration, the (idle) power consumption of
this device is X kWh? Later in S3.1.1 you talk about energy ratings
and data sheets for instance.
<ALEX> This is already alluded to by the discussion of certification.
We expanded that paragraph to make it clearer. ("It should be noted
that just because a metric is stated does not necessarily mean in all
cases that it is accurate or true. Where this can be a concern, they
should ideally be certified.") </ALEX>
implementation of packet classification of Ternary
Content-Addressable Memory (TCAM) and the size of TCAM
These seem a bit specific. In another device it might be something
totally different that’s central to the power consumption, e.g., on
wireless the radios.
<ALEX> True, but it was meant as an example. Expanded on this to
mention the wireless radio. ("Depending on the type of device, there
may also be other factors, such as radios in case of equipment
supporting wireless transmission.") </ALEX>
Generally, the cost of the first bit could be considered very
high, as it requires powering up a device, port, etc.
Perhaps this is a bit too broad statement, given that the costs are
actually dependent also on the speed at which things can be powered up
or down. Entire devices… often takes long. Some link types… can take
long. Others, maybe less so. Some CPUs and other architectures also
have very dynamic sleep state models that can react at a quick pace.
<ALEX> As a general statement, I do think this is true - but you are
correct that there are many dependencies and specifics depend on the
particular case. Expanded the discussion to mention that. ("Of course,
precise numbers vary greatly between different devices and device
architectures, some of which may support dynamic sleep state models
that are able to transition quickly with limited overhead, thus
mitigating some of those effects.") </ALEX>
Current power consumption / kB (or gB)
Some consideration should be given for different tasks and classes of
devices. A Bluetooth transmission != 100-km fiber transmission != WAN
radio to a mobile device.
<ALEX> Sure, but even where the actual values may differ greatly, the
metric itself remains the same. The possibility that you can perform
further differentiation by device component is already discussed in
section 3.1.1. I am not sure what other textual update we would need
here? </ALEX>
An important aspect concerns the device's power source.
Yes. Maybe you could have some discussion of where this information
resides, e.g., it could be that some local information distribution
could make the device aware of this, or is this something that is fed
from separate backend systems to the network management algorithms?
<ALEX> I think there is a risk here of getting sidetracked into a
discussion of technical solutions, as opposed to the metrics
themselves. That being said, I added some text to take your comment
into account: "Even in cases where a power source does not independently
provide such data, it is conceivable to use controllers and/or
management systems to provision certain devices with it to make those
device and the network aware of it to allow network-embedded algorithms
to take such information into account."
3.1.3. Virtualization Considerations
Nice! Liked in particular the CPU power proportionality observation.
3.2. Green Metrics related to Flows
Some discussion related to usefulness of measurements vs. effort and
power consumption needed for a measurement might be in order here. I
guess sampling _some_ flows and not all will be a way to go, but
perhaps that should be stated? Thoughts?
<ALEX> I don't think we need to get into how we would conduct the actual
measurement. However, you are correct that of course the benefit of an
accurate reading of a metric must outweigh the cost of obtaining it.
For this particular item, I think the text does imply that we would not
measure things on a packet-by-packet basis but can be obtained
differently (compute the proportion of flow traffic to overall traffic,
multiple this with the total energy consumption incurred by the device
during that time), hence I don't think the sampling consideration
applies. To make it clearer, I added the following text: "(As with
other metrics, the effort and power consumption needed to measure this
data needs to be taken account. For example in this case, rather than
attempting to perform highly-granular measurements at every instant of
time or every packet, approximations such as attributing the energy
consumption as a share of total traffic over the duration of the flow
will be entirely sufficient.)" </ALEX>
Some of the metrics that are mentioned in this document may be
difficult to assess and verify in practice, such as sustainability
ratings or device power ratings.
Good that this is stated.
*Nits*
Sustainability Tax
Is this a generally used term? Seems there’s some possibility to mix
this with other things, not related to power efficiency…
<ALEX> I added a common that this is meant as a tax in the technical
sense, not in the monetary sense - hope this is clearer now...
Again, many thanks for your comments - much appreciated! </ALEX>
Jari
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
