Re: [recipe] And another new draft revision: Green Networking Metrics

[Alexander L Clemm <[e-mail]>]

Hello Eve,

thank you for your great feedback!  And apologies for the long delay in 
responding.  Please find my responses inline, below.  We will also be 
posting an update to the draft momentarily with your feedback 
incorporated (hence crossposting to opsawg)

Best

--- Alex

On 11/29/2022 11:53 PM, Schooler, Eve M wrote:
> Hi Alex and co-authors,
> Thanks for a very interesting read (https://datatracker.ietf.org/doc/draft-cx-green-metrics/)!
> Here is some informal feedback on the latest version of the draft document.
> Best regards,
> Eve
>
> Eve M. Schooler, PhD
> Principal Engineer & Director
> Intel | CSO & NEX | Emerging IoT Networks
> 2200 Mission College Blvd., Santa Clara, CA, USA  95054
> +1 650.868.7369
> -----
>
> Abstract:
> In the abstract there is reference to "power consumption, energy efficiency and carbon footprint", for both network equipment and services provided over it - would be great to describe the relationship between these three attributes somewhere. In the Intro, language is also used re "environmental sustainability of networks", which may go beyond energy-related metrics.
>
> Section 1. Intro
> - Why cite the Telefonica Consolidated annual report vs Sustainability report?
<AC> The consolidated report includes an extensive section on 
sustainability along with the data.  I am not aware of a separate 
sustainability report (although I am sure it must exist). </AC>
>
> Section 2. Definitions and Acronyms
> - Include kWh
<AC>We have added it (and a few more) </AC>
> Section 3. Energy Metrics
> - For each bullet, give examples of existing metrics.
> - 3rd bullet references energy intensity. Is this a term commonly used? Does it need specific definition
> - Either way, contrast this with carbon intensity.
<AC> The term "energy intensity" has been removed.   We have also added 
further explanation on the relationship between carbon footprint, energy 
consumption, etc </AC>
>
> 3.1.1 Energy consumption Metrics
> - Any thoughts/precedent on how to separate the carbon footprint of a device from the networking aspects of the device?
<AC> I am not sure what you mean here exactly.  Do you mean devices 
performing both compute and networking?  I think in general those would 
be difficult to separate.  I think if we can do a breakdown of the 
device to the component level (cards and ports), that may already be 
plenty. </AC>
> - Are we only gaging router power consumption, or other network HW elements? What about SW? Different parts of the stack?
<AC> The focus is on network HW elements (section 3.1 "Metrics related 
to [networking] equipment").  It is probably difficult to attribute to 
software in itself, although section 3.1.3 talks about the attribution 
to functions realized as software ("Virtualization Considerations").  We 
also added discussion in section 3.1.2 regarding additional factors such 
as ""taxation" for unattributed energy use, for taking into account 
sustainability of energy sources (energy-aware vs pollution-aware), for 
potentially transposing those into CO2 emission factors, etc. </AC>
> - Love the reference to ATIS, which makes me wonder about certification of the numbers associated with the various device elements and the devices overall?
<AC> I totally agree that certification is super important and we 
expanded on that aspect.  </AC>
> - Re "The second set of metrics reflects the actual power being drawn during operation." What about embodied carbon, which for smaller devices such as phones is a dominating factor?
<AC> This is an important point and discussion of this added in the 
section on "Holistic Perspective".  However, due to the myriads of 
factors at play here, we did not add specific metrics, just mention that 
corresponding metrics and discount factors (or pollution factors, 
depending on perspective) could be defined. </AC>
> - Odd to see the terms "kilooctet" and "gigaoctet"; why not simply kB or gB? Yes to pico Joules.
<AC> Fixed it. </AC>
>
> 3.1.2 Other Metrics
> - A common sustainability rating of the power source is carbon intensity. A good publication to read, where carbon intensity is considered, but so is a waste metric to capture environmental impact beyond energy and carbon:
>      + Hossain, Md. Mohaimenul, Georges, Jean-Phillippe, Rondeau, Eric, Divoux, Thierry. Energy, carbon and renewable energy: Candidate metrics for green-aware routing? Sensors, 19(13), Feb 2019.
> - "It may be possible to obtain such a rating from the energy operation...."
>      + I really like that the document includes such a statement. It would be helpful for each of the metrics discussions to include: from whom the measurements for the metric might originate
> - If deployment of the device is outside a Data Center (DC) and actually is in the wild, e.g., an RSU (road side unit), should the device be charged an energy tax for releasing its heat into the atmosphere?
<AC> Thank you for the reference, indeed a great one!  We added some 
related discussion in Section 3.1.2 ("Green Metrics Beyond Energy 
Consumption").  However, we decided to not add the discussion about 
where metrics might originate, as this might be a bit distracting and  
expand the scope. </AC>
>
> 3.1.3 Virtualization Considerations
> - 2nd paragraph seems to imply that DCs because they are more energy efficient should be the target environment of choice. However, in Edge IoT contexts, there may be too much data to be able to migrate a container to a back-end cloud, thus the cloud must stay local. In other words, the choice to process a container locally may have other constraints (data volume, privacy, latency, that prohibit it from being placed in a more PUE-optimal setting).
<AC> Totally agree with you and we made some edits to point out the 
tradeoff. </AC>
> - Orchestration SW, Developers, run-time systems, are all going to want to have insight into how to untangle virtualization and CFP. Perhaps the demand is to insist that HW manufacturers support SW APIs that can extract and export this data upon request. IETF may or may not be the place to define those APIs, but we should help critique them and ensure they support the metadata we need to properly calculate and to properly attribute impact of the network elements (HW/FW/SW).
<AC> Visibility into this data is of course what motivates this work in 
the first place.  I am not sure we need to talk about software APIs here 
although I agree with you that allowing APIs to expose that data (in 
addition to via protocols) makes a lot of sense. </AC>
>
> 3.2 Energy Metrics related to Flows
> - "In its basic incarnation, those metrics reflect the energy consumption at a given device."
>      + There are many hidden devices that are like supporting cast members for each Layer 3 device, making this seem nearly impossible, unless the owners/operators are involved in assessing the supporting infrastructure that enables that device. This is similar to saying services reside in DCs and they consume x% of the overall energy, therefore there is a fair share of a carbon tax that all services must contribute towards cooling.
> - "Amortized energy consumed over the duration of the flow"
>      + Expecting this to help us compute the aforementioned carbon tax that goes unaccounted when we only consider the router itself. Basically, compute a percentage of the total unaccounted for energy usage, to tax the app or flow.
> - "A second set of energy metrics related to flow might aggregate the flow's energy consumption over the entire flow path".
>      + This should be do-able at least if thought of as an approximation or a bound/threshold of some sort
>      + Also, it begs the question if we can/should reserve resources along that path to use lowest carbon-intensity
<AC> We expanded the text that talks about these factors, and the 
possibility of defining additional factors to "weigh" other metrics with 
in order to account for these aspects.  Regarding the reservation of 
resources to minimize carbon intensity: this is a great suggestion; 
however, at  this point we prefer for solutions to stay outside the 
scope - perhaps something we should incorporate into the green 
networking problem statement draft (draft-cx-green-ps). </AC>
>
> 3.3 Energy Metrics related to Paths
> - Need to articulate somewhere how energy usage and carbon footprint relate to each other. It would then be more clear that carbon-intensity is a useful attribute for consideration in these steering decisions, as the carbon-intensity of electricity in Poland is 80x the carbon intensity of electricity in Sweden.
<AC> I think the way to account for this is by the network operator 
having knowledge of their energy mix.  This is information that IMHO 
would need to be provisioned, perhaps to be considered by a controller 
who keeps track of this like for network inventory. Again, this goes 
into solutions and I am not sure how much we should talk about this 
here.  </AC>
>
> 4.1 User perspective
> - A discussion of incentivization could be fruitful here (or at least a discussion of stick vs carrot, tax vs tax break). For instance, have reduce rates for users who have time-elastic data transmissions.
<AC> Added the suggestion to use these metrics to incentivize 
carbon-conscious networking use.  Kept specific solutions / schemes 
outside the scope at this point; clearly there is a lot in that regard 
that can be discussed.  </AC>
>
> 4.2 Holistic perspective
> - See reference cited above for an example of other metrics outside energy/carbon
<AC> Yes, thank you again, great reference. </AC>
>
> 4.3 Sustainable equipment production - really enjoyed reading this section
> - With which other organizations should IETF partner to affect change in the lifecycle of networking devices and systems?
> - What should the IETF as a community demand from HW/FW/SW manufacturers?
>      + For real-time instrumentation
>      + For data sheets on expected energy usages
>      + APIs to access/modify/disseminate carbon-footprint-related data
>      + Published embodied carbon in the manufacturing of networking equipment - i.e., product carbon footprints
>      + Ramp up of Circularity programs - which might look categorically different in developed vs developing nations

<AC> These are good questions for the group.  IMHO, instrumentation will 
be the first step - I would think that therefore definition of YANG data 
models will be one of the next items.  If there are RFCs, customers may 
demand implementation.

Many thanks again for your insightful comments!

</AC>

>
> -----Original Message-----
> Date: Thu, 20 Oct 2022 20:53:30 -0700
> From: Alexander Clemm <[e-mail]>
> To: [e-mail]
> Subject: [recipe] And another new draft revision: Green Networking Metrics
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> As subject line:  FYI, we have just posted a new revision of draft-cx-green-metrics, "Green Networking Metrics", here:
> https://datatracker.ietf.org/doc/draft-cx-green-metrics/
>
> The updates are mostly of a relatively minor nature to provide further editorial quality.
>
> --- Alex (on behalf of coauthors)
>
>
>
> ------------------------------
>
> End of recipe Digest, Vol 12, Issue 1
> *************************************
>