**Session Date/Time:** 16 Feb 2024 15:00 # [EIMPACT](../wg/eimpact.html) ## Summary The EIMPACT session focused on identifying "sustainability hotspots" within the ICT sector, presenting a benchmarking methodology for power consumption in networking devices, sharing practical experiences from the streaming industry regarding energy measurement, and exploring carbon-aware routing. Key discussions centered on the distinction between measurement and assessment, the challenges of obtaining real-world energy data, and potential IETF/IRTF roles in addressing sustainability through protocol design, metrics, and operational practices. The session concluded with a review of potential next steps for the program, emphasizing the need to coordinate efforts across various IETF working groups and identify gaps for future work. ## Key Discussion Points * **Sustainability Hotspots and IETF Role (Ali Maru):** * The ICT sector consumed approximately 4% of global electricity and emitted 1.4% of global GHGs in 2020, with a tendency to increase. * There is no observed direct correlation between data growth rates and electricity/GHG emissions. * User devices account for 57% of ICT GHG emissions (half from manufacturing, half from use phase). Networks contribute 24% (83% in use phase), and data centers/enterprise networks 18% (78% in use phase). Focus on the use phase for networks is critical. * The ICT sector must halve its emissions by 2030 to meet Paris Agreement goals, beyond relying solely on renewable energy transition. * Beyond GHG, sustainability includes land, water, materials use, and biodiversity loss, highlighting the importance of circularity principles. * IETF protocol design decisions can impact sustainability through trade-offs (e.g., performance vs. resource use, hardware readiness vs. sleep modes, complexity). * Proposed systematic actions for IETF/IRTF include assessing deployed technology, prioritizing use-phase emission reduction, handling hardware dependencies for circularity, and for IRTF, focusing on understanding limits and causality in protocol design. * Discussion highlighted the difference between Key Performance Indicators (KPIs) (technology-specific, measurable) and Key Value Indicators (KVIs) (outcome-oriented, assessed). The concept of "step changes" in energy consumption and the difficulty of capturing the overall consequential impact of ICT use (e.g., video conferencing reducing travel emissions) were also discussed. * **Benchmarking Methodology for Power in Networking Devices (Jpe, on behalf of Carlos Roma):** * A new draft, `draft-roma-bmwg-power-benchmarking-methodology`, proposes a methodology to compare Energy Efficiency (EE) of individual networking devices. * The Energy Efficiency Ratio (EER) is defined as throughput forwarded per watt, considering various traffic load levels (e.g., 0%, 30%, 100%) and assigning weights based on device type (e.g., core vs. edge). * Benchmarking should specify device details (interfaces, line cards, traffic parameters) and consider that maximum power does not reflect real-world workload. * Initial tests include throughput, base power, power with traffic, and EER calculation. * Discussion points included incorporating power impact of interface speeds/states, other device parameters (fans, PSUs), transition times between power states, and the need for standardized weights to ensure comparability of results. The potential for a standardized output format (e.g., XML or Yang) for planning tools was also raised. The possibility of benchmarking software power consumption in hackathons was mentioned. * **Practical Experience from Streaming (Dom Robinson):** * Greening of Streaming (GoS) is an initiative addressing sustainability in streaming, focusing on energy (Watts/kWh) rather than just carbon, and promoting efficiency regardless of green energy availability. * Real-world measurements in distribution networks and CDNs suggest that **capacity**, not traffic volume, is the primary driver of energy consumption at scale. Traffic spikes show insignificant energy bumps when scaled across total capacity. * Actionable, real-time energy data from operator networks and CDNs is largely unavailable. * Regulatory bodies are increasingly adopting a problematic linear correlation between gigabytes and carbon, which needs to be challenged. * The distinction between **consequential** (actual reduction in energy demand) and **attributional** (claiming responsibility for emissions) impact is crucial. GoS emphasizes consequential impact. * Challenges include fear of "greenwashing" and "anti-bragging rights" (reluctance to be the first to publicly report emissions). * Recommendations for IETF/IRTF included: * Obtaining granular, actionable data from Telcos and Cloud providers, possibly through regulation (e.g., quarterly kWh purchasing reports). * Using layer models to scope engineering ownership within the IP stack. * Considering specifying how switches and link layer technologies report energy. * Revisiting multicast for energy efficiency, especially for large live events and pre-positioned content, noting the resurgence of Multicast ABR. * Addressing over-provisioning and redundancy in networks (Jevons Paradox) that leads to excessive capacity. * Acknowledging responsibility for consumer equipment energy consumption, as network decisions influence client-side requirements. * Encouraging simple, overlay network measurement using off-the-shelf smart plugs. * Exploring "workload shifting" to move non-time-critical compute (e.g., video transcoding, AI training) to locations with excess renewable energy (e.g., windmills). * **Exploring Carbon-Aware Routing (Saan Sabet):** * Network carbon emissions are significant and often underestimated. The work focuses on Scope 2 emissions (purchased electricity) associated with routers. * Carbon intensity varies significantly by region, day, and season, but is predictable 24-48 hours in advance, allowing for routing optimization. * Proposed metrics include energy-related (typical power, energy rating, dynamic power per unit traffic) and carbon-related (carbon intensity, carbon emissions). * Two approaches were simulated: 1) adjusting link costs based on metrics (impacts dynamic power), and 2) Carbon-Aware Traffic Engineering (CATE), a heuristic that shuts down underutilized, high-carbon links (impacts idle power). * Simulations on BT and GÉANT topologies showed CATE could achieve up to 15% carbon savings (BT) and 9.5-10% (GÉANT), even if it sometimes meant slightly higher *greener* energy consumption. Savings were less for evening (downstreaming) traffic due to short flow durations. * Carbon-aware routing had minimal impact on delay. * Flows tended to shift to greener regions. London and Germany acted as bottlenecks due to high node density. * Higher static-to-dynamic power ratio in routers (e.g., chassis-based) limits carbon savings, suggesting investment in lower static power equipment. * Next steps include agreeing on a set of metrics, establishing the veracity of reported metrics (e.g., carbon intensity APIs), considering inter-domain routing, defining standard reporting formats, and tying electricity/carbon consumption to applications (carbon tracing). * Discussion suggested routing-related working groups (e.g., TVR, IDR) as a potential home for this work and for defining formatting, as well as inviting the presenter to discuss with the RIPE community and consider registering information in Peering DB. ## Next Steps The program chairs outlined several potential next steps, seeking input from the participants: * **Metrics:** * Push metric standardization work through relevant IETF working groups (e.g., BMWG, IDR). * Start with simple, extendable metrics. * Resolve issues regarding data transport mechanisms (e.g., ICMP, integration with existing device/network frameworks). * **Action:** Individuals interested in specific metrics or working groups (e.g., BMWG, IDR) are encouraged to participate and voice their opinions. * **Sustainability Concept Considerations Document:** * Aim for an RFC from the EIMPACT program, focusing on a scoped portion of the discussion rather than a lengthy document. * **Action:** Program chairs to downscope and refine the document for further review, with eventual IAB review for publication. * **Education:** * Broaden the reach of sustainability discussions and presentations (like those in this session) to other IETF communities (e.g., security developers), whose primary focus may not be sustainability. * **Action:** Explore venues and formats for wider educational outreach. * **Benchmarking Methodology:** * The BMWG (Benchmarking Methodology Working Group) is the appropriate venue for `draft-roma-bmwg-power-benchmarking-methodology`. * **Action:** Authors to present the draft at BMWG. Community members to engage in BMWG discussions. * **Carbon-Aware Routing:** * Potential for discussion in IRTF or routing-related IETF working groups for standardization. * **Action:** Presenter encouraged to engage with the RIPE community and routing-related IETF/IRTF groups. * **Open Source:** * More hackathon projects are needed, potentially focusing on tooling for software power measurement. * **Action:** Vlada from RIPE NCC offered their hackathon budget and organizational skills for co-organizing such events. Parties interested in workload shifting/windmill energy projects are encouraged to reach out to Dom Robinson. * **Engagement with Policy Makers:** * Engage with organizations like ISO and IAB to energize sustainability work for the Internet. * **Action:** Program chairs to explore engagement opportunities. * **Venues for Work:** * Identify venues for work items that currently lack a home, potentially leading to new BoFs or Research Groups (RGs) for operational measurements. * **Action:** Maintain a wiki page (or similar mechanism via Data Tracker links) to track EIMPACT-related drafts and updates across different working groups, serving as a coordination point similar to the IOT Directorate. * **Meeting Cadence:** * The group agreed on the value of continued discussions. While an annual hybrid IETF meeting is planned, further interim meetings can be spun up as needed when specific topics are identified. * **Action:** Program chairs to assess the need for future interim meetings or informal gatherings (e.g., at IETF Brisbane) based on emerging topics and community interest.