draft-various-eimpact-arch-considerations-00.txt | draft-various-eimpact-arch-considerations.txt | |||
---|---|---|---|---|
Network Working Group M. Welzl | Network Working Group M. Welzl | |||
Internet-Draft University of Oslo | Internet-Draft University of Oslo | |||
Intended status: Informational E. Stephan | Intended status: Informational E. Stephan | |||
Expires: 4 September 2025 Orange | Expires: 8 January 2026 Orange | |||
E. Schooler | E. Schooler | |||
University of Oxford | University of Oxford | |||
S. Rumley | S. Rumley | |||
HES-SO | HES-SO | |||
A. Rezaki | A. Rezaki | |||
Nokia | Nokia | |||
J. Manner | J. Manner | |||
Aalto University | Aalto University | |||
C. Pignataro | C. Pignataro | |||
Blue Fern Consulting | Blue Fern Consulting | |||
skipping to change at page 1, line 33 ¶ | skipping to change at line 32 ¶ | |||
A. Keränen | A. Keränen | |||
Ericsson | Ericsson | |||
H. ElBakoury | H. ElBakoury | |||
L. M. Contreras | L. M. Contreras | |||
Telefonica | Telefonica | |||
A. Clemm | A. Clemm | |||
Independent | Independent | |||
J. Arkko | J. Arkko | |||
Ericsson | Ericsson | |||
3 March 2025 | 7 July 2025 | |||
Architectural Considerations for Environmentally Sustainable Internet | Architectural Considerations for Environmentally Sustainable Internet | |||
Technology | Technology | |||
draft-various-eimpact-arch-considerations-00 | draft-various-eimpact-arch-considerations-latest | |||
Abstract | Abstract | |||
This document discusses protocol and network architecture aspects | This document discusses protocol and network architecture aspects | |||
that may have an impact on the sustainability of network technology. | that may have an impact on the sustainability of network technology. | |||
The focus is on providing guidelines that can be helpful for protocol | The focus is on providing guidelines that can be helpful for protocol | |||
designers and network architects, where such guidelines can be given. | designers and network architects, where such guidelines can be given. | |||
About This Document | About This Document | |||
skipping to change at page 2, line 29 ¶ | skipping to change at line 73 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on 4 September 2025. | This Internet-Draft will expire on 8 January 2026. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2025 IETF Trust and the persons identified as the | Copyright (c) 2025 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
extracted from this document must include Revised BSD License text as | extracted from this document must include Revised BSD License text as | |||
described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction | |||
2. Potential Architectural Aspects . . . . . . . . . . . . . . . 5 | 2. Understanding | |||
2.1. Measurement . . . . . . . . . . . . . . . . . . . . . . . 5 | 2.1. Measurement and Modeling | |||
2.1.1. Motivation . . . . . . . . . . . . . . . . . . . . . 6 | 2.1.1. Motivation | |||
2.1.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 6 | 2.1.2. Analysis | |||
2.1.3. Recommendation . . . . . . . . . . . . . . . . . . . 7 | 2.1.3. Recommendation | |||
3. Actions | ||||
2.2. Modeling . . . . . . . . . . . . . . . . . . . . . . . . 9 | 3.1. Dynamic Scaling | |||
2.2.1. Motivation . . . . . . . . . . . . . . . . . . . . . 9 | 3.1.1. Motivation | |||
2.2.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 9 | 3.1.2. Analysis | |||
2.2.3. Recommendation . . . . . . . . . . . . . . . . . . . 11 | 3.1.3. Recommendation | |||
2.3. Dynamic Scaling . . . . . . . . . . . . . . . . . . . . . 11 | 3.2. Transport | |||
2.3.1. Motivation . . . . . . . . . . . . . . . . . . . . . 12 | 3.2.1. Motivation | |||
2.3.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 13 | 3.2.2. Analysis | |||
2.3.3. Recommendation . . . . . . . . . . . . . . . . . . . 15 | 3.2.3. Recommendation | |||
2.4. Transport . . . . . . . . . . . . . . . . . . . . . . . . 15 | 3.3. Equipment Longevity | |||
2.4.1. Motivation . . . . . . . . . . . . . . . . . . . . . 15 | 3.3.1. Motivation | |||
2.4.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 16 | 3.3.2. Analysis | |||
2.4.3. Recommendation . . . . . . . . . . . . . . . . . . . 17 | 3.3.3. Recommendation | |||
2.5. Equipment Longevity . . . . . . . . . . . . . . . . . . . 17 | 3.4. Encoding | |||
2.5.1. Motivation . . . . . . . . . . . . . . . . . . . . . 17 | 3.4.1. Motivation | |||
2.5.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 18 | 3.4.2. Analysis | |||
2.5.3. Recommendation . . . . . . . . . . . . . . . . . . . 19 | 3.4.3. Recommendation | |||
2.6. Compact encoding . . . . . . . . . . . . . . . . . . . . 19 | 3.5. Sustainable by Design: Data Governance Perspective | |||
2.6.1. Motivation . . . . . . . . . . . . . . . . . . . . . 19 | 3.5.1. Motivation | |||
2.6.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 19 | 3.5.2. Analysis | |||
2.6.3. Recommendation . . . . . . . . . . . . . . . . . . . 20 | 3.5.3. Recommendation | |||
2.7. Sustainable by Design: Data Governance Perspective . . . 20 | 4. Recommendations for Protocol Design | |||
2.7.1. Motivation . . . . . . . . . . . . . . . . . . . . . 20 | 5. Recommendations for Further Work and Research | |||
2.7.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 20 | 6. Security Considerations | |||
2.7.3. Recommendation . . . . . . . . . . . . . . . . . . . 21 | 7. IANA Considerations | |||
3. Recommendations for Further Work and Research . . . . . . . . 21 | 8. Informative References | |||
4. Security Considerations . . . . . . . . . . . . . . . . . . . 22 | Appendix A. Modeling Approaches and Literature | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 | A.1. Customer Attribution | |||
6. Informative References . . . . . . . . . . . . . . . . . . . 22 | A.2. Baselining and Benchmarking | |||
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25 | Acknowledgments | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 | Authors' Addresses | |||
1. Introduction | 1. Introduction | |||
This document discusses protocol and network architecture aspects | ||||
that can have an impact on the environmental sustainability of | ||||
network technology. For brevity, we will use the term sustainability | ||||
in this document to refer to environmental sustainability. We do | ||||
note that sustainability as a term is widely used to refer to | ||||
different notions of sustainability, and the most well-known larger | ||||
definition of sustainability can be seen from the United Nations | ||||
Sustainable Development Goals (UN SDG) [UNSDG]. | ||||
Environmental sustainability is an important consideration in | Environmental sustainability is an important consideration in | |||
networking. Both for ensuring that networking technology can enable | society, and in networking, too. Networking technologies enable | |||
societies to operate in an environmentally sustainable manner and | societies to operate in an environmentally sustainable manner and | |||
that the networks themselves are environmentally sustainable. | thereby have a positive handprint, yet networks themselves must be | |||
environmentally sustainable and attempt to minimise their negative | ||||
footprint. | ||||
This document discusses protocol and network architecture aspects | Fundamentally the question we try to address concerns the resource | |||
that may have an impact on the environmental sustainability of | usage and the lifecycle of network equipment. The less devices are | |||
network technology. For brevity, we will use the term sustainability | built, and energy is used, the less emissions are created. Networks | |||
to refer to environmental sustainability. We do note that | are built with hardware and these in turn use electrical energy to | |||
sustainability as a term is widely used to refer to different notions | run. Eventually, the hardware is decommissioned and some amount of | |||
of sustainability, and the most well-known larger definition of | the materials are recycled. | |||
sustainability can be seen from the United Nations Sustainable | ||||
Development Goals (UN SDG) [UNSDG]. | ||||
Sustainability impact and emissions from networking comes from three | We can divide the lifecycle into three major phases (omitting some | |||
primary categories: hardware manufacturing, direct energy usage and | intermittent steps like shipping of products): | |||
construction work. The last category is out of scope of this | ||||
document because networking has limited means to impact construction | 1. Manufacturing (including the raw material extraction and usage, | |||
work itself. The manufacturing of networking hardware, both for | the embedded chips and electronics, casing, and energy needed for | |||
fixed and wireless networks, is a significant source of emissions, | these operations, etc.), | |||
and recycling of ICT equipment is still limited. Direct energy usage | ||||
of networking and the source of the energy have been the primary | 2. Use phase that is focused on the operational energy use and | |||
concerns, but as the world moves towards greener energy production, | repairing equipment, and | |||
the relative negative impact of the emissions from manufacturing | ||||
becomes more prominent. | 3. End of life that can include both direct recycling of some of the | |||
materials or finding a new life and usage for an old product that | ||||
still functions, after which it is finally recycled. | ||||
Networks also require some amount of physical construction to | ||||
realize, and this construction work also creates emissions. This | ||||
category of emissions is out of scope of this document because the | ||||
Internet community and network engineers have limited means to impact | ||||
construction work itself and the associated industry, but we can | ||||
impact how networks, protocols and hardware are designed, built and | ||||
operated. | ||||
All these phases create harmful emissions, into the ground and in the | ||||
air, that have a negative impact on our environment and people. As | ||||
the type of such emissions vary, they are often standardized as | ||||
carbon dioxide equivalent (CO2e) to allow comparing sources and | ||||
amounts of emissions. When discussing (carbon) emissions in this | ||||
document, we generally refer to CO2e. | ||||
The manufacturing of networking hardware, both for fixed and wireless | ||||
networks, is a significant source of emissions, and recycling of ICT | ||||
equipment is still limited to the casing and some other minor parts. | ||||
Direct energy usage of networking and the source of the energy have | ||||
often been the primary concerns. There are many reports and | ||||
scientific papers discussing carbon emissions of the energy used by | ||||
ICT. As of today, and the foreseeable future, the difference in | ||||
emissions of the electric grid between countries and regions can vary | ||||
significantly. e.g. In the EU, there are 10-fold differences between | ||||
countries, and similar differences exist between US states. On a | ||||
global level, the differences can be over 50-fold. Yet, as the world | ||||
moves towards greener energy production, the relative negative | ||||
impacts related to manufacturing becomes more prominent and the | ||||
importance of equipment longevity grows. | ||||
When good design and architecture can improve the sustainability of | When good design and architecture can improve the sustainability of | |||
networks, they should certainly be applied to designing new protocols | networks, they should certainly be applied to designing new protocols | |||
and building networks. Intuitively, protocol and network | and building networks. Intuitively, protocol and network | |||
architecture choices can have an impact on sustainability. At the | architecture choices can have an impact on sustainability. At the | |||
very least the right design and architecture can make it possible to | very least the right design and architecture can make it possible to | |||
have a positive impact, but of course the architecture alone is not | have a positive impact, but of course the architecture alone is not | |||
enough. The possibilities offered by the architecture need to be | enough. The possibilities offered by the architecture need to be | |||
realized by implementations and practical deployments. | realized by implementations and practical deployments. | |||
To give an example of an architectural aspect that potentially has a | To give an example of an architectural aspect that potentially has a | |||
sustainability impact, enabling the collection of information (e.g., | sustainability impact, enabling the collection of information (e.g., | |||
energy consumption) and then using that information to make smarter | energy consumption) and then using that information to make smarter | |||
decisions is one. For instance, understanding power consumption of | decisions is one. For instance, understanding power consumption of | |||
individual nodes can be valuable input to future purchasing decisions | individual nodes can be valuable input to future purchasing decisions | |||
or development efforts to reduce the power consumption. Yet, as data | or development efforts to reduce the power consumption. Yet, as data | |||
collection is often rather easy, we should not overdo it in such a | collection is often rather easy, it is easy to overdo it in such a | |||
way that it leads to accumulation of dark data (i.e. data that is | way that it leads to accumulation of dark data (i.e. data that is | |||
collected and stored, but never used). All data collection consumes | collected and stored but never used). All data collection consumes | |||
processing power, network resources and storage space, and this can | processing power, network resources and storage space, and this can | |||
in turn increase the emissions from the network. | in turn increase the emissions from the network. | |||
Other architectural examples include making it possible to scale | Other architectural examples include making it possible to scale | |||
resources or resource selection processes performed in a | resources or resource selection processes performed in a | |||
sustainability-aware fashion. The use of communication primitives | sustainability-aware fashion. The use of communication primitives | |||
that maximize utility in a given problem (e.g., using multicast) or | that maximize utility in a given problem (e.g., using multicast) or | |||
the use of technologies that reduce the number or size of messages | the use of technologies that reduce the number or size of messages | |||
needed for a given task (e.g., binary encoding instead of textual) | needed for a given task (e.g., binary encoding instead of textual) | |||
are some further examples. | are some further examples. | |||
Of course, some of these aspects may have a major impact on | Of course, some of these aspects may have a major impact on | |||
sustainability, where others may only have a minor effect. There are | sustainability, where others may only have a minor effect. There are | |||
also tradeoffs, such as side-effects of architectural choices, e.g., | also tradeoffs, such as side-effects of architectural choices, e.g., | |||
dynamic scaling of a router network potentially impacting jitter, or | dynamic scaling of a router network potentially impacts jitter; | |||
putting cellular base stations to sleep and activating them as | putting cellular base stations to sleep and activating them as | |||
capacity needs grow may introduce a delay in matching the needs of | capacity needs grow potentially introduces a delay in matching the | |||
the data flows. | needs of the data flows. | |||
The document is intended to help engineering efforts in the IETF, | The document is intended to help engineering efforts in the IETF, | |||
provide operational guidance in the operator community, as well as to | provide operational guidance in the operator community, as well as to | |||
point to potential research directions in the IRTF. | point to potential research directions in the IRTF. | |||
The scope of the document is advice on Internet and protocol | The scope of the document is advice on Internet and protocol | |||
architecture, such as what architecture or capabilities new protocol | architecture, such as what architecture or capabilities new protocol | |||
designs or features should have, what kind of operational network | designs or features should have, what kind of operational network | |||
architectures should be deployed, and how all of these can be | architectures should be deployed, and how all of these can be | |||
designed to best address sustainability concerns. The focus of this | designed to best address sustainability concerns. | |||
document is to provide actionable design advice to protocol | ||||
designers. This document therefore addresses one aspect in the | The focus of this document is to provide actionable design advice to | |||
architecture question, and does not claim to cover the topic | protocol designers. This document therefore addresses one aspect in | |||
the architecture question and does not claim to cover the topic | ||||
exhaustively. | exhaustively. | |||
This document is also not focused on general issues around | This document is not focused on general issues around environmental | |||
environmental sustainability, except those that pertain to | sustainability, except those that pertain to architecture or | |||
architecture or significant protocol features. | significant protocol features. | |||
It is to be noted that networks themselves are a service, a tool, for | It is to be noted that networks themselves are a service, a tool, for | |||
all the applications and services on the Internet. Networks connect | all the applications and services on the Internet. Networks connect | |||
data, people and services. The increase in networking and size of | data, people and services. The increase in networking and size of | |||
the Internet is driven by these applications and the usage. | the Internet is driven by these applications and the usage. | |||
Therefore the emissions from networking are tied to the applications | Therefore, the emissions from networking are tied to the applications | |||
and the data they consume; with less applications or data, the | and the data they consume; with less applications or data, the | |||
Internet would have less hardware and less energy usage. The goals | Internet would have less hardware and less energy usage. The goals | |||
of this document are not to instruct application and service | of this document are not to instruct application and service | |||
developers to choose what applications are worthwhile or how much | developers to choose what applications are worthwhile or how much | |||
content is sent. There are many forums and parties whose mission is | content is sent. There are many forums and parties whose mission is | |||
to help these developers to implement more sustainable services, such | to help these developers to implement more sustainable services, such | |||
as, the Green Software Foundation, the Green Web Foundation, Greening | as, the Green Software Foundation, the Green Web Foundation, Greening | |||
of Streaming, to name a few. | of Streaming, to name a few. | |||
2. Potential Architectural Aspects | The next two sections present architectural and protocol design | |||
aspects that can have an impact on the sustainability of networking. | ||||
Section 2 discusses those foundations that are required to prepare | ||||
for sustainability improvements, and Section 3 discusses actions that | ||||
can be taken to make the actual improvements. For each topic in | ||||
these sections, we provide an overview, the motivation for why it | ||||
would be important to consider for more sustainable networking, an | ||||
analysis and recommendations for future networking professionals. | ||||
This section presents architectural and protocol design aspects that | Recommendations for protocol designers are discussed throughout the | |||
can have an impact on the sustainability of networking. For each | document and summarized in Section 4. Finally, Section 5 discusses | |||
topic, we provide an overview, the motivation for why it would be | further work that is needed to make further concrete recommendations | |||
important to consider for more sustainable networking, an analysis | for the designers. | |||
and recommendations for future networking professionals. | ||||
2.1. Measurement | 2. Understanding | |||
It is essential to understand the current state of affairs before any | 2.1. Measurement and Modeling | |||
improvements can be made. i.e. Some levels of measurements are | ||||
necessary for starting to improve sustainability. This is | ||||
particularly the case when looking at the systems as a whole in post- | ||||
analysis. As discussed earlier, this level of measurements is useful | ||||
input for further actions, such as deciding what parts of the network | ||||
need to be targeted for further improvement. | ||||
But measurements may also be useful for some dynamic situations where | It is essential to understand the current state of affairs before any | |||
power-saving decisions, for instance, depend on knowing the relative | improvements can be made. Thus, some levels of measurements are | |||
power consumption of different activities, such as when a power-off | necessary for starting to improve sustainability. In some cases | |||
decision involves understanding the relative savings during the | measurements may be complemented by modeling. | |||
shutdown period vs. the power cost of shutdown and startup | ||||
procedures, or the possible need to reconfigure other nodes in the | ||||
network due to the shutdown. | ||||
2.1.1. Motivation | 2.1.1. Motivation | |||
Measurements are a necessary mechanism for both post-analysis and | ||||
potentially for some of the dynamic decisions taken by systems. | ||||
Without measurements of any kind, it is impossible to assess if the | Without measurements of any kind, it is impossible to assess if the | |||
networks are functioning correctly. It is impossible to know if the | networks are functioning correctly. It is impossible to know if the | |||
system is efficient by comparing it against a baseline model. It is | system is efficient by comparing it against a baseline model. It is | |||
also impossible to check that changes aiming at optimizing something | also impossible to check that changes aiming at optimizing something | |||
are indeed valuable. | are indeed valuable. | |||
For instance, while electricity providers can make information about | This is particularly the case when looking at the systems as a whole | |||
power usage available, this is only done at the aggregate level. | in post-analysis. As discussed earlier, some level of measurements | |||
Without per-device data about power usage, there would be limited | is useful input for further actions, such as deciding what parts of | |||
basis for deciding where power is actually consumed and consequently, | the network need to be targeted for further improvement. | |||
what improvements are most useful. | ||||
But measurements may also be useful for some dynamic situations where | ||||
power-saving decisions, for instance, depend on knowing the relative | ||||
power consumption of different activities, such as when a power-off | ||||
decision involves understanding the relative savings during the | ||||
shutdown period vs. the power cost of shutdown and startup | ||||
procedures, or the possible need to reconfigure other nodes in the | ||||
network due to the shutdown. | ||||
At the same time, it is not possible to measure everything. | At the same time, it is not possible to measure everything. | |||
Furthermore, any measurement must be validated. Relevance of | Furthermore, any measurement must be validated. Relevance of | |||
measurements must be periodically assessed, e.g., with comparisons | measurements must be periodically assessed, e.g., with comparisons | |||
between measurements within a network and the aggregate numbers from | between measurements within a network and the aggregate numbers from | |||
the electricity provider. | the electricity provider. | |||
Finally, measurements made in the field must be collected and | Finally, measurements made in the field must be collected and | |||
organized to allow later retrieval. | structured to allow later retrieval. And measurements are | |||
counterproductive if they are endlessly accumulated without being | ||||
consulted. | ||||
2.1.2. Analysis | 2.1.2. Analysis | |||
While the simplest forms of sustainability-related measurements are | This section discusses how measurements relate to the fabrication and | |||
about power, there's clearly room for other measurements and other | usage phases and how efficiency can be measured. | |||
information as well. To begin with, power consumption by itself may | ||||
not be what matters most for sustainability, as the source of the | ||||
power may be equally important in terms of determining the actual | ||||
carbon footprint. | ||||
Secondly, for many classes of devices the embedded carbon aspects or | 2.1.2.1. Measuring impacts of fabrication and usage phases | |||
use of raw materials may be a significant sustainability issue. See | ||||
also Section 2.2. | ||||
Third, power or energy measurements alone are of meager use if the | Network infrastructure generates negative impacts principally during | |||
cause of the consumption is not measured as well. Any power/energy | fabrication and usage phases. Measuring negative impacts related to | |||
measurement should occur alongside other measurements that can be | fabrication falls in the activity of lifecycle analysis (LCA). LCAs | |||
used to determine energy efficiency. Hence a sound measurement | is typically realized per device, either by the equipment vendor | |||
architecture implies that a prior existence of an energy efficiency | itself, or by third-party analysts. LCA involves modeling (see | |||
framework of some kind. | Section 2.1.3.6). The analysis can be done in terms of climate | |||
change (CC) but can be extended to other criteria as abiotic resource | ||||
depletion (ARD), ecotoxicity (ET) or water usage (WU). LCA also | ||||
involves information systems keeping an inventory of the devices | ||||
uses. For many classes of devices, the embedded carbon aspects or | ||||
use of raw materials are significant sustainability issues. As these | ||||
measurements and inventories are external to the network | ||||
architecture, they are considered out of this document scope. | ||||
But when it comes to energy consumption, as noted the aggregate | Measuring negative impacts related to the usage phase falls in the | |||
information is often typically available, and it's not particularly | scope of monitoring. In this phase, the most obvious sustainability- | |||
hard to measure the energy consumption of individual network devices | related measurement is power monitoring to measure the energy | |||
either. Still, there are a number of desirable use cases where the | consumption and estimate the related negative impacts. | |||
measurement situation needs to improve. | ||||
2.1.2.1. Measuring Power Efficiency | 2.1.2.2. Measuring efficiency | |||
When assessing the power consumption (Scope 2) of an IT-organization, | Power (in Watts, that is, in Joule/s) or energy (in Joules) | |||
emission accountants are generally looking for a metric of the | measurements alone are of meager use if the cause of the consumption | |||
delivered value per unit of energy. | is not measured as well. Any power/energy measurement should occur | |||
alongside other measurements that can be used to determine energy | ||||
efficiency. Hence a sound measurement architecture implies the | ||||
existence of an energy efficiency framework of some kind. | ||||
A commonly used method is to equate the delivered value with the | In the context of carbon accounting, emission accountants are | |||
number of bits sent or received, or to the communication capacity | generally looking for a metric of the delivered value per unit of | |||
made available when there's a need for it. The latter is important, | carbon. In networking, the most obvious delivered value is number of | |||
as often communication networks have requirements to be able to send | bits sent or received (traffic), or to the communication capacity | |||
messages when there's a need for it, e.g., for emergency | made available during unit of time. In both case, the unit is the | |||
communications, not that those messages are always being sent. | bit, but the two metrics have very different meanings. In one case, | |||
one spends a Joule to send a bit. In the other case, one spends a | ||||
Joule to offer a bandwidth capacity of 1 bit/s during a second. The | ||||
latter is important, as often communication networks have | ||||
requirements to be able to send messages when there's a need for it, | ||||
e.g., for emergency communications, even when those messages may not | ||||
always be sent. | ||||
The measurement of efficiency is not restricted to energy. Traffic | ||||
or offered bandwidth can be related to the carbon emitted by the | ||||
device traversed by this traffic. This carbon should include the | ||||
part associated with electricity, but also the part associated with | ||||
fabricating the device (pro rata temporis) [LCAandUsage]. | ||||
Sustainable efficiency can also be expressed in water used per | ||||
traffic, for example. | ||||
2.1.3. Recommendation | 2.1.3. Recommendation | |||
Ongoing work at the IETF's GREEN working group is already targeted at | Ongoing work at the IETF's GREEN working group is already targeted at | |||
improving existing energy consumption metrics and frameworks but some | improving existing energy consumption metrics and frameworks but some | |||
further considerations may apply. In order to meet the needs | further considerations may apply. While the Sustainable Internet | |||
discussed above, the following architectural design principles are | Architecture addresses broader lifecycle aspects such as | |||
proposed. | manufacturing, reuse, and recycling—essential to circular economy | |||
goals the GREEN framework provides a foundational model for | ||||
monitoring and optimizing energy consumption across networked devices | ||||
and components. Therefore, extending the measurements defined in the | ||||
Sustainable Internet Architecture to integrate energy related data | ||||
from the GREEN framework, such as power states, consumption patterns, | ||||
and efficiency ratios will enable a more holistic approach to | ||||
environmental impact assessment. Harmonizing these efforts will | ||||
support the development of composite metrics that connect operational | ||||
energy use with manufacturing and end-of-life considerations, | ||||
establishing a coherent basis for sustainable digital infrastructure | ||||
management. | ||||
2.1.3.1. Generality | In order to meet the needs discussed above, the following | |||
architectural design principles are proposed. | ||||
2.1.3.1. Future Proof Metrics | ||||
We recommend that any measurement framework or sustainability-related | We recommend that any measurement framework or sustainability-related | |||
information sharing mechanism be designed to share different types of | information sharing mechanism be designed to share different types of | |||
information and not limited to a single metric such as power | information and not limited to a single metric such as power | |||
consumption. Similarly, the granularity of data collection needs to | consumption. Requirements, units, granularity and collection method | |||
be configurable so that the metrics collected can be as fine-grained | specifications are sure to shift over time. | |||
or as aggregated as needed in order to identify potential areas of | ||||
improvement. | ||||
2.1.3.2. Collect Metrics from Existing Equipment | 2.1.3.2. Plug-in Architecture for Collection and Control | |||
Since the need to deliver on the use cases described is urgent, the | Since the need to deliver on the use cases described is urgent, the | |||
industry has to accomodate the capabilities (and limitations) of | industry has to accommodate the capabilities (and limitations) of | |||
existing equipment in the field for collecting metrics. | existing equipment in the field for collecting metrics. It is | |||
recommended to apply a plug-in architecture with modules that can | ||||
It is recommended to have a plug-in architecture with modules that | work with (read from and control) devices of any kind, including | |||
can work with (read from and control) devices of any kind, including | ||||
traditional networking hardware devices, cooling systems, software | traditional networking hardware devices, cooling systems, software | |||
stacks, and occasionally static datasheets. | stacks, and occasionally static data sheets. | |||
2.1.3.3. Content Declaration for all Collected Metrics | ||||
A warehouse filled with data collected from diverse sources is | 2.1.3.3. Data with Content Declaration | |||
useless without proper labeling. Hence, these is a need to create | ||||
metadata that describes the collected data. (e.g. What are the | ||||
source(s)? What measurement units are used? Precision? What is | ||||
included/excluded in these numbers?) | ||||
The metadata itself must also have a formal description. e.g. Use | To make sense of the collected data, it must be possible to see | |||
YANG for the metadata schema. Keep the metadata attached to the | exactly where all data is coming from, what it means, its precision | |||
dataflow it describes, so that the relation is clear to each | and how it has been processed. The metadata itself must also have a | |||
component that has anything to do with it, including components added | formal description. YANG might be suitable for modeling the metadata | |||
by other organizations at a later point in time. | schema. Keep the metadata attached to the dataflow it describes, so | |||
that the relation is clear even when components are added by other | ||||
organizations at a later point in time. | ||||
2.1.3.4. Collection, Aggregation, Processing, Display, Decisions | 2.1.3.4. Processing Flexibility and Audit Trails | |||
The collected data passes through a pipeline from collection to | The collected data passes through a pipeline from collection to | |||
decisions. By processing we mean steps to reshape the data to match | decisions. By processing we mean steps to reshape the data to match | |||
further aggregation and processing steps, such as unit conversions, | further aggregation and processing steps, such as unit conversions, | |||
sample frequency alignment, filtering, etc. | sample frequency alignment, filtering, etc. | |||
Separate these architectural roles into separate modules in order to | Separate these pipeline stages into separate modules and use | |||
enable reuse, modular development and a transparent, configurable | configuration to construct the pipeline. This gives flexibility, | |||
pipeline. | reuse and enables a full audit trail. It is essential that every | |||
data processing step can be reviewed in an audit situation without | ||||
2.1.3.5. Configurable Pipeline for Reuse and Transparency | looking at code. | |||
Let the pipeline connections between the components be driven by | ||||
configuration rather than hard coded. This enables reconfiguration | ||||
of the processing pipeline over time, and perhaps more importantly, | ||||
transparency into what stages the data pass through, even without | ||||
access to or understanding of the source code of the entire system. | ||||
2.1.3.6. Design Together with the Users | 2.1.3.5. Aligned with Reporting Frameworks | |||
Every system should be designed involving some of its target users. | Ensure that the system output is aligned with the measurement | |||
In order for delivered metrics to be of any value, the target | requirements set forth by relevant legal frameworks, e.g. ESRS | |||
audience needs to be aware of their existence, be able to interpret | (Europe), TCFD and IFRS (US, Japan), BRSR (India), etc. The | |||
them and understand how they can be used in their professional | responsible corporate bodies producing the corporate reports are | |||
context. | unlikely to use any technical collection system that isn't well | |||
aligned. | ||||
There are many target user groups for the information produced. Some | 2.1.3.6. Modeling | |||
examples are network designers/engineers, scientists, operations | ||||
teams and IT-development organizations. One critical group that is | ||||
often overlooked is the sustainability assessment experts. If they | ||||
are not aware, don't understand or don't care about the produced | ||||
sustainability metrics, the value of this work would be greatly | ||||
diminished. | ||||
2.2. Modeling | Where power optimization choices are made, accurate information is | |||
required to decide the right choice. | ||||
The paucity of up-to-date information on equipment and system | The paucity of up-to-date information on equipment and system | |||
parameters, especially power consumption and maximum throughput, | parameters, especially power consumption and maximum throughput, | |||
makes estimating the power consumption and energy efficiency of these | makes estimating the power consumption and energy efficiency of these | |||
systems extremely challenging. In addition the rapid evolution of | systems extremely challenging. In addition, the rapid evolution of | |||
technology and products in ICT makes the estimation quickly outdated | technology and products in ICT makes the estimation quickly outdated | |||
and possibly inaccurate. In almost all cases physical measurement | and possibly inaccurate. In some cases, physical measurements have | |||
has to be replaced by partial measurement and mathematical modeling. | to be replaced by partial measurements and mathematical modeling. | |||
2.2.1. Motivation | ||||
Where power optimization choices are made, accurate information is | ||||
required to decide the right choice. Modeling instead of | ||||
measurements may have to be used in some cases. | ||||
2.2.2. Analysis | 2.1.3.6.1. Power modeling | |||
To date, two approaches to network power modeling are accepted as | To date, two approaches to network power modeling are accepted as | |||
providing a realistic estimate of network power consumption. These | providing a realistic estimate of network power consumption. These | |||
approaches are referred to as "bottom-up" and "top-down". The paper | approaches are referred to as "bottom-up" and "top-down". The paper | |||
[Unifying] surveys both approaches and provide a new approach which | [Unifying] surveys both approaches and provide a new approach which | |||
unifies both of them. The unified approach is used to estimate the | unifies both of them. The unified approach is used to estimate the | |||
power consumption of access, aggregation and core networks. | power consumption of access, aggregation and core networks. | |||
The paper [Modeling] provides a model for IP Routers and the routers | Modeling can also help address attribution aspects, such as those | |||
of other future Internet architectures (FIA) such as SCION and | involved in an effort of an organization to calculate its Scope 3 | |||
NEBULA. They use a generic model which captures the commonalities of | emissions. Modeling can also be used to assist in establishing a | |||
IP router as well as the peculiarities of FIA routers. They conduct | baseline energy consumption, and enable later comparisons to that | |||
a large-scale simulation based on this router model to estimate the | baseline. | |||
power consumption for different network architectures. | ||||
Since routers and other network devices and functions can be | ||||
virtualized, this article (1) provides comprehensive "graphical, | ||||
analytical survey of the literature, over the period 2010–2020, on | ||||
the measurement of power consumption and relevant power models of | ||||
virtual entities as they apply to the telco cloud." This paper A | ||||
Methodology and Testbed to Develop an Energy Model for 5G Virtualized | ||||
RANs IEEE Conference Publication IEEE Xplore got best paper award for | ||||
GreenNet 2024, but I am not sure if we are interested to model 5G | ||||
vRAN. | ||||
There is a plethora of publications on modeling communication | ||||
networks and DC computing. | ||||
2.2.2.1. Customer Attribution | ||||
When organizations assess their Scope 3 emissions, they need to sum | ||||
up their share of emissions from all their suppliers, one of which | ||||
for example, might be a cloud hosting service. In order for the | ||||
supplier to provide an emission share value back to the customer, the | ||||
provider needs to develop a mechanism for attribution. | ||||
A significant challenge in accurately assessing Scope 3 emissions is | ||||
avoiding Double Counting, where the same emission is reported by | ||||
multiple entities. According to the GHG Protocol best practices, it | ||||
is crucial to establish clear guidelines and agreements between | ||||
suppliers and customers to ensure that emissions are attributed | ||||
correctly and not counted multiple times. This requires transparent | ||||
communication and precise emission reporting standards to ensure that | ||||
all parties involved have a consistent understanding of which | ||||
emissions belong to which organization. | ||||
By addressing the Double Counting issue, companies can achieve more | ||||
accurate and reliable Scope 3 emissions assessments, thereby | ||||
contributing to better overall sustainability reporting and | ||||
improvement efforts. | ||||
2.2.2.2. Baselining and Benchmarking | ||||
Establishing a baseline is a fundamental step in the process of | ||||
improving energy efficiency and sustainability of network technology. | ||||
Baselining involves establishing a reference point of typical energy | ||||
usage, which is crucial for identifying inefficiencies and measuring | ||||
improvements over time. In this step, the controller uses only the | ||||
collected data from datasheets and other reliable sources. | ||||
By establishing a baseline and using benchmarking, organizations can | ||||
determine if their networking equipment is performing normally or if | ||||
it is deviating from expected performance. This is the first step in | ||||
identifying and guiding necessary improvements. Benchmarking | ||||
involves collecting performance measurements of networking equipment | ||||
under controlled conditions. This process helps establish | ||||
standardized performance metrics, allowing for comparison against | ||||
baselines collected during regular operational conditions. | ||||
The initial measurement of networking equipment's energy efficiency | ||||
and performance, known as Baselining, should be coordinated with | ||||
vendor specifications and industry standards to understand what is | ||||
considered normal or optimal performance. For example, if the | ||||
baseline indicates that your switches operate at 5 Gbps per watt, | ||||
while vendor specifications suggest 8 Gbps per watt and the industry | ||||
standard is 10 Gbps per watt, actions should be taken to implement | ||||
energy-saving measures and upgrades. Continuously tracking | ||||
subsequent measurements can reveal if efficiency improves towards the | ||||
benchmark of 8-10 Gbps per watt. | ||||
This practice ensures that any improvements can be quantifiably | ||||
tracked over time, providing a clear measure of the effectiveness of | ||||
the implemented changes and guiding further enhancements in network | ||||
sustainability. | ||||
See also [Baseline] and [BenchmarkingFramework]. | ||||
2.2.3. Recommendation | Additional discussion of modeling can be found in Appendix A. | |||
Even though baselining is essential in identifying potential areas of | 3. Actions | |||
improvement and tracking progress, it is still to be determined to | ||||
what extent we need to work on modeling networks and devices in the | ||||
architecture. | ||||
2.3. Dynamic Scaling | 3.1. Dynamic Scaling | |||
Dynamic scaling is the ability to adjust resources according to | Dynamic scaling is the ability to adjust resources according to | |||
demand, and possibly turn some of them off during periods of low | demand and possibly turn some of them off during periods of low | |||
usage. Examples include the set of servers needed for a service, how | usage. Examples include the set of servers needed for a service, how | |||
many duplicate links are needed to carry high-volume traffic, whether | many duplicate links are needed to carry high-volume traffic, whether | |||
one needs all base stations with overlapping coverage areas to be on, | one needs all base stations with overlapping coverage areas to be on, | |||
etc. | etc. | |||
Networks and communications are also critical functions of the modern | Networks and communications are also critical functions of the modern | |||
digital society. The reliability of individual networking links or | digital society. The reliability of individual networking links or | |||
devices cannot always be guaranteed. As a result, various levels and | devices cannot always be guaranteed. As a result, various levels and | |||
forms of resiliency are often needed, for instance through | forms of resiliency are often needed, for instance through | |||
redundancy. Yet, there is a question on how much redundancy is | redundancy. Yet, there is a question on how much redundancy is | |||
needed and how quickly a backup or resource increase can be activated | needed and how quickly a backup or resource increase can be activated | |||
due to increased demand. | due to increased demand. | |||
2.3.1. Motivation | Scaling can be pulled up and down by data consumption variations and | |||
more rarely by power shortage. In such situation dynamic scaling is | ||||
the ability to adjust demand resources according to resources. When | ||||
operating on limited backup energy sources such as batteries or | ||||
generators, the architecture must support graceful adaptation before | ||||
power runs out. In such situations, networks must minimize | ||||
consumption to extend operational time. | ||||
3.1.1. Motivation | ||||
Outside of implementation improvements, dynamic scaling is | Outside of implementation improvements, dynamic scaling is | |||
potentially the most promising method for reducing power consumption | potentially the most promising method for reducing power consumption | |||
related environmental impacts. Scaling can happen on a device-level | related environmental impacts. Scaling can happen on a device-level | |||
(increasing performance as traffic levels grow) or a network segment | (increasing performance as traffic levels grow) or a network segment | |||
level (increasing the number of active links or cellular base | level (increasing the number of active links or cellular base | |||
stations). | stations). | |||
Considering current fixed networking hardware, dynamic scaling might | Considering current fixed networking hardware, dynamic scaling might | |||
not have an impact in situations where there's only a single router | not have an impact in situations where there's only a single router | |||
skipping to change at page 12, line 39 ¶ | skipping to change at line 542 ¶ | |||
hardware can be fully operational at all times and used to serve the | hardware can be fully operational at all times and used to serve the | |||
traffic, while other links may be in hot or cold standby depending on | traffic, while other links may be in hot or cold standby depending on | |||
the use case. | the use case. | |||
Cellular networks are typically built with significant overlap in | Cellular networks are typically built with significant overlap in | |||
coverage areas of multiple base stations. Demand and business | coverage areas of multiple base stations. Demand and business | |||
reasons dictate the design of the coverage, and regulations might | reasons dictate the design of the coverage, and regulations might | |||
dictate how reliable the cellular service should be. There is | dictate how reliable the cellular service should be. There is | |||
extensive work world-wide to optimize the operation of this | extensive work world-wide to optimize the operation of this | |||
overlapping coverage, e.g. by turning down some sites at night time | overlapping coverage, e.g. by turning down some sites at night time | |||
when traffic volumes are low. A cellular basestation site can | when traffic volumes are low. A cellular base station site can | |||
consume anything from a few kWh to ten or more kWh per provider. | consume anything from a few kWh to ten or more kWh per provider. | |||
Modern cellular base stations do implement numerous features to scale | Modern cellular base stations do implement numerous features to scale | |||
the energy consumption. In general, cellular base stations have a | the energy consumption. In general, cellular base stations have a | |||
base energy consumption and traffic-dependent consumption, a somewhat | base energy consumption and traffic-dependent consumption, a somewhat | |||
similar behavior to what we can observe in modern CPUs. | similar behavior to what we can observe in modern CPUs. | |||
On the network level, most large systems have significant amount of | On the network level, most large systems have significant amount of | |||
redundancy and spare capacity. Where such capacity can be turned on | redundancy and spare capacity. Where such capacity can be turned on | |||
or off to match the actual need at a given time, significant | or off to match the actual need at a given time, significant | |||
reductions in power consumption can be achieved. | reductions in power consumption can be achieved. | |||
2.3.2. Analysis | Whereas scaling down under normal conditions seeks to reduce | |||
consumption while maintaining full capabilities, power-constrained | ||||
operations accept degraded performance or functionality. Operating | ||||
in power backup mode introduces a shift in network behavior as it | ||||
differs from network-driven auto scaling: | ||||
* Network, devices and components must reduce power usage, possibly | ||||
sacrificing performance, feature sets, or redundancy. | ||||
* Each network domain (RAN, edge, and core network segments) faces | ||||
its own constraints and policies in power-limited operation. | ||||
3.1.2. Analysis | ||||
Dynamic scaling could be seen as either an alternative or | Dynamic scaling could be seen as either an alternative or | |||
complementary to load stabilization, e.g., via "peak shaving". | complementary to load stabilization, e.g., via "peak shaving". | |||
Perhaps the most realistic angle is that both are likely needed. | Perhaps the most realistic view is that both are likely needed. | |||
The most rudimentary approach to dynamic scaling is just turning some | The most rudimentary approach to dynamic scaling is just turning some | |||
resources off. However this may not be sufficient, and a more | resources off. However this may not be sufficient, and a more | |||
graceful/engineered approach potentially yields better results. | graceful/engineered approach potentially yields better results. | |||
Network architects need to understand the impacts of scaling changes | Network architects need to understand the impacts of scaling changes | |||
on users and traffic. These may include the fate of ongoing | on users and traffic. These may include the fate of ongoing | |||
sessions, latency/jitter, packets in flight, or running processes, | sessions, latency/jitter, packets in flight, or running processes, | |||
attempts to contact resources that are no longer present, and the | attempts to contact resources that are no longer present, and the | |||
time it takes for the network to converge to its new state. | time it takes for the network to converge to its new state. | |||
skipping to change at page 14, line 22 ¶ | skipping to change at line 632 ¶ | |||
[I-D.ietf-tvr-requirements] [I-D.ietf-tvr-schedule-yang] | [I-D.ietf-tvr-requirements] [I-D.ietf-tvr-schedule-yang] | |||
[I-D.ietf-tvr-alto-exposure]. | [I-D.ietf-tvr-alto-exposure]. | |||
* Efficient propagation of changes of new routes, new set of | * Efficient propagation of changes of new routes, new set of | |||
servers, etc. as to reduce the amount of time where state is not | servers, etc. as to reduce the amount of time where state is not | |||
synchronized across the network. The needs for the propagation | synchronized across the network. The needs for the propagation | |||
solution needs to be driven by dynamic scaling and sustainability | solution needs to be driven by dynamic scaling and sustainability | |||
as well as other aspects, such as recovery from failures. | as well as other aspects, such as recovery from failures. | |||
* Build mechanisms to deal with dynamic changes: Plan for dynamic | * Build mechanisms to deal with dynamic changes: Plan for dynamic | |||
set of resources, and not expect to work with a fixed set of | set of resources and not expect to work with a fixed set of | |||
resources. | resources. | |||
* Dynamic scaling requires automation in most cases, e.g., to turn | * Dynamic scaling requires automation in most cases, e.g., to turn | |||
on new service instances. See again | on new service instances. See again | |||
[I-D.pignataro-enviro-sustainability-architecture] for a | [I-D.pignataro-enviro-sustainability-architecture] for a | |||
discussion of automation. | discussion of automation. | |||
* Interaction with the energy grid can enable dynamic load shifting. | * Interaction with the energy grid can enable dynamic load shifting. | |||
For instance, a demand-response technique can be used where the | For instance, a demand-response technique can be used where the | |||
system temporarily reduces its energy usage in response to pricing | system temporarily reduces its energy usage in response to pricing | |||
signals from a smart grid. The proposed demand-response technique | signals from a smart grid. The proposed demand-response technique | |||
involves deferring the load from elastic requests to later time | involves deferring the load from elastic requests to later time | |||
periods in order to reduce the server demand and the current | periods in order to reduce the server demand and the current | |||
energy usage, and hence, energy costs [LoadShifting]. | energy usage, and hence, energy costs [LoadShifting]. | |||
* Energy-aware routing. This generally aims at aggregating traffic | * Energy-aware routing. This generally aims at aggregating traffic | |||
flows over a subset of the network devices and links, allowing | flows over a subset of the network devices and links, allowing | |||
other links and interconnection devices to be switched off. These | other links and interconnection devices to be switched off. These | |||
solutions shall preserve connectivity and QoS, for instance by | solutions shall preserve connectivity and QoS, for instance by | |||
limiting the maximum utilization over any link, or ensuring a | limiting the maximum utilization over any link or ensuring a | |||
minimum level of path diversity. There are also algorithms for | minimum level of path diversity. There are also algorithms for | |||
Green Traffic engineering. For instance [Segment] employs segment | Green Traffic engineering. For instance, [Segment] employs | |||
routing. Experimental analysis results [Experiment] show that the | segment routing. Experimental analysis results [Experiment] show | |||
resource usage for SRv6 could be more than 70% lower than that of | that the resource usage for SRv6 could be more than 70% lower than | |||
the SPF-based forwarding, depending on the network topology. | that of the SPF-based forwarding, depending on the network | |||
topology. | ||||
2.3.3. Recommendation | 3.1.3. Recommendation | |||
The guidelines above need to be considered specifically for each | The guidelines above need to be considered specifically for each | |||
protocol and system design. Further work in detailing this guidance | protocol and system design. Further work in detailing this guidance | |||
would also be useful. | would also be useful. | |||
It is likely that there is increased attention to resiliency in the | It is likely that there is increased attention to resiliency in the | |||
future, given for instance the increased importance of the tasks | future, given for instance the increased importance of the tasks | |||
supported by networks or the potentially increasing frequency of | supported by networks or the potentially increasing frequency of | |||
natural disasters as a result of global warming. | natural disasters as a result of global warming. | |||
2.4. Transport | Scaling steps during power shortage differ from network dynamic | |||
scaling and depend on the network domain and the events: grid | ||||
outages, deployment in remote or mobile environments, extreme weather | ||||
events, or any sort of enforced reductions in power usage like | ||||
monthly battery testing. Nevertheless, there is a gain to have a | ||||
common dynamic scaling approach that includes network-driven scaling | ||||
and power-shortage scaling. | ||||
Transport protocols are the flexible tools that make it possible for | 3.2. Transport | |||
communication flows between parties to adjust themselves to the | ||||
dynamic conditions that exist in the network at any given time: | ||||
available bandwidth, delays, congestion, the ability of a peer to | ||||
send or receive traffic, and so on. Depending on the conditions, an | ||||
individual flow may carry traffic at widely different rates, may | ||||
pause for some time, etc. Various higher-level transport solutions | ||||
may also cache or pre-fetch information. | ||||
This behavior has an effect on sustainability as well, e.g., in what | Transport protocols make it possible for communication flows to | |||
periods the endpoint and network systems are active or when they | adjust themselves to the dynamic conditions that exist in the network | |||
could be in reduced activity or sleep states. | at any given time: available bandwidth, delays, congestion, the | |||
ability of a peer to send or receive traffic, and so on. Depending | ||||
on the conditions, an individual flow may carry traffic at widely | ||||
different rates, may pause for some time, etc. | ||||
Cellular networks and mobile links can scale their energy usage based | This behavior has an effect on sustainability, e.g., in what periods | |||
on load and enter a low-power state when a traffic flow ends. Thus, | the endpoint and network systems are active or when they could be in | |||
in theory, the faster the data is transferred, the faster the device | reduced activity or sleep states. Cellular networks and mobile links | |||
transmission/reception functions can enter a low-power state. | can scale their energy usage based on load and enter a low-power | |||
state when a traffic flow ends. Thus, in theory, the faster the data | ||||
is transferred, the faster the device transmission/reception | ||||
functions can enter a low-power state. | ||||
2.4.1. Motivation | 3.2.1. Motivation | |||
Transport behavior would have a possibility of impacting how much | Transport behavior would have a possibility of impacting how much | |||
downtime or sleep can be had in the communication system, either on | downtime or sleep can be had in the communication system, either on | |||
the end systems or routers or other equipment in between. The | the end systems or routers or other equipment in between. The | |||
savings can be significant, at least in wireless systems. | savings can be significant, at least in wireless systems. | |||
Improvements through transport behavior are only useful if the | Improvements through transport behavior are only useful if the | |||
involved systems have power proportionality. | involved systems have power proportionality. | |||
2.4.2. Analysis | 3.2.2. Analysis | |||
A critical issue is the tradeoff involved in sending traffic. As | Various higher-level transport solutions may also cache or pre-fetch | |||
argued in [NotTradeOff], reducing the amount of time the endpoints | information. For instance, [I-D.irtf-nmrg-green-ps] lifts CDNs as | |||
and the network are active can sometimes help save energy, e.g. in | one example of technology that has reduced energy consumption, by | |||
case the receiver is connected over a WiFi link. Similar logic | moving the needed endpoints closer to each other. | |||
applies for any technology that has a certain degree of energy | ||||
proportionality, e.g. cellular communication. As a result, in | On a given set of endpoints, application behavior can impact | |||
environmental costs. For instance, | ||||
[I-D.pignataro-enviro-sustainability-consid] observes the effect of | ||||
protocol chattiness. Does the protocol rely on periodic updates or | ||||
heartbeat messages? Could such message patterns result in preventing | ||||
links or nodes from going to sleep (absent other communications), and | ||||
in such a case, would an alternative pattern be feasible? | ||||
Transport layer protocol behavior also has an impact. A critical | ||||
issue is the tradeoff involved in sending traffic. As argued in | ||||
[NotTradeOff], reducing the amount of time the endpoints and the | ||||
network are active can sometimes help save energy. As a result, in | ||||
general, delivering information as rapidly as possible would appear | general, delivering information as rapidly as possible would appear | |||
to be desirable. | to be desirable. | |||
On the other hand, bandwidth-intensive applications can influence | On the other hand, would such as rapid transmission impact peak | |||
other applications or users by presenting a significant load on the | traffic, and as such, contribute to a need to dimension networks for | |||
higher traffic volumes? And in this case the need could be only a | ||||
perceived one as a less rapid transmission would not have impacted, | ||||
for instance, a user's ability to view a video if the transmission | ||||
was merely for the buffering of the rest of the video. | ||||
Furthermore, bandwidth-intensive applications can influence other | ||||
applications or users by presenting a significant load on the | ||||
network, and consequently reducing capacity available for others, or | network, and consequently reducing capacity available for others, or | |||
increasing buffering (and with it, latency) across the network path. | increasing buffering (and with it, latency) across the network path. | |||
For an application with intermittent data transfers, such as | For an application with intermittent data transfers, such as | |||
streaming video, this would seem to speak in favor of sustained but | streaming video, this would seem to speak in favor of sustained but | |||
lower-rate delivery instead of transmitting short high-rate bursts | lower-rate delivery instead of transmitting short high-rate bursts | |||
[Sammy]. However, this is in contradiction with the energy-saving | [Sammy]. However, this is in contradiction with the energy-saving | |||
approach above. Thus, the tradeoff is: should data be sent in a way | approach above. Thus, the tradeoff is: should data be sent in a way | |||
that is "friendly" to others (avoiding bad interference), or should | that is "friendly" to others (avoiding bad interference), or should | |||
it save energy by sending fast, increasing the chance for equipment | it save energy by sending fast, increasing the chance for equipment | |||
to enter a "sleep" state? | to enter a "sleep" state? | |||
skipping to change at page 16, line 41 ¶ | skipping to change at line 760 ¶ | |||
expense of other traffic. For non-urgent data transfers, the IETF- | expense of other traffic. For non-urgent data transfers, the IETF- | |||
recommended default approach is the opposite: the LEDBAT congestion | recommended default approach is the opposite: the LEDBAT congestion | |||
control mechanism [RFC6817], which is designed for such use, will | control mechanism [RFC6817], which is designed for such use, will | |||
always "step out of the way" of other traffic, giving it a low rate | always "step out of the way" of other traffic, giving it a low rate | |||
when it competes with any other traffic. Alternatively, if the goal | when it competes with any other traffic. Alternatively, if the goal | |||
is to reduce energy, such traffic could be sent at a high rate, at a | is to reduce energy, such traffic could be sent at a high rate, at a | |||
strategically good moment within a longer time interval; this would | strategically good moment within a longer time interval; this would | |||
give network equipment an opportunity to enter a sleep state in the | give network equipment an opportunity to enter a sleep state in the | |||
remaining time period within the interval. | remaining time period within the interval. | |||
Perhaps the issue is that the transport behavior (as with many other | A hypothesis could be made that transport protocols should take | |||
things) needs to take into account multiple parameters. For example, | energy into account in addition to the many other inputs they decide | |||
it is possible that a balanced transport algorithm would be able to | upon. For example, it is possible that a non-urgent data transfer | |||
send as much as possible as soon as possible, while tracking buffer | would send as much as possible as soon as possible when at least one | |||
growth from transmission delays and scaling back if there's any | of the links along the path is known to be power proportional (e.g., | |||
buffer growth. This remains to be confirmed with experiments, | a cellular link), while tracking buffer growth from transmission | |||
however. | delays to scale back if delay should occur. | |||
Similarly, caching and pre-fetching designs need to take into account | Such ideas remain to be confirmed with experiments, however. | |||
not only the likelihood of having acquired the right content in | ||||
memory, but also the sustainability cost of possibly fetching too | Similarly, caching and pre-fetching designs need to consider not only | |||
much or the timing of those fetching operations. | the likelihood of having acquired the right content in memory, but | |||
also the sustainability cost of possibly fetching too much or the | ||||
timing of those fetching operations. | ||||
In general, information about the impacts of loading or not loading | In general, information about the impacts of loading or not loading | |||
the network with additional traffic, and whether a certain sending | the network with additional traffic, and whether a certain sending | |||
pattern enables power savings through sleep modes, would be | pattern enables power savings through sleep modes, would be | |||
beneficial for the communicating endpoints. Mechanisms for making | beneficial for the communicating endpoints. Mechanisms for making | |||
such information available to the endpoints would be useful. | such information available to the endpoints would be useful. | |||
2.4.3. Recommendation | 3.2.3. Recommendation | |||
The techniques described above have been based on theoretical | As can be seen from the above, there are a number of complex | |||
analysis. There is a need for further simulations and experiments to | tradeoffs merely for transport protocol behavior on a given | |||
confirm what strategies would provide the best end-user and energy | connection. | |||
performance. This may be work that fits within the IRTF SUSTAIN | ||||
research group. | ||||
2.5. Equipment Longevity | This prompts us to give two types of advice. The first type of | |||
advice is for protocol designers: simple models are unlikely to | ||||
guarantee optimal results, but as long as normal precautions such as | ||||
congestion control, monitoring queue build-up, and avoiding | ||||
unnecessary messages are employed, systems will operate reasonably | ||||
well. | ||||
The second type of advice is for further work in the research | ||||
community to better understand what strategies would actually provide | ||||
the best end-user and energy performance, and whether the choice of | ||||
strategy depends on other factors, such as whether sleep modes are | ||||
implemented in network nodes. There is a clear need for simulations | ||||
and experiments to understand this better. This may be work that | ||||
fits within the IRTF SUSTAIN research group. Also, new standards may | ||||
be need if information sharing about the sustainability and sleep | ||||
mode characteristics of network systems is needed for applications to | ||||
make the best transport decisions. | ||||
3.3. Equipment Longevity | ||||
This section discusses the ability to extend the useful life of | This section discusses the ability to extend the useful life of | |||
protocols and/or network equipment in order to amortize the embedded | protocols and/or network equipment in order to amortize the embedded | |||
energy costs over a longer period, even though it may mean that the | energy costs over a longer period, even though it may mean that the | |||
protocols/equipment may not be fully optimized for the present use. | protocols/equipment may not be fully optimized for the present use. | |||
This includes devising tools to inform network administrators and | This includes devising tools to inform network administrators and | |||
their users of the potential benefits of network equipment upgrades, | their users of the potential benefits of network equipment upgrades, | |||
so that they can make better choices on what upgrades are necessary | so that they can make better choices on what upgrades are necessary | |||
and when. | and when. | |||
It should be noted that from an environmental sustainability | It should be noted that from an environmental sustainability | |||
perspective, it may not always be the best choice to upgrade network | perspective, it may not always be the best choice to upgrade network | |||
equipment whenever slightly less power-hungry and "greener" | equipment whenever slightly less power-hungry and "greener" | |||
alternatives become available. The environmental cost of amortizing | alternatives become available. The environmental cost of amortizing | |||
the carbon embedded inside equipment over its lifetime, including the | the carbon embedded inside equipment over its lifetime, including the | |||
carbon associated with the manufacturing of the equipment that is to | carbon associated with the manufacturing of the equipment that is to | |||
be replaced, should be taken into consideration as well. | be replaced, should be taken into consideration as well. | |||
2.5.1. Motivation | 3.3.1. Motivation | |||
Embedded carbon and raw materials can be a significant part of the | Embedded carbon and raw materials can be a significant part of the | |||
overall environmental impact of systems. If this can be improved for | overall environmental impact of systems. If this can be improved for | |||
devices that are manufactured in large quantities, the improvements | devices that are manufactured in large quantities, the improvements | |||
can be significant. | can be significant. | |||
The more the world moves toward low-carbon energy sources, the more | The more the world moves toward low-carbon energy sources, the more | |||
the manufacturing matters in the holistic view. Today there can be | the manufacturing matters in the holistic view. Today there can be | |||
an order of magnitude difference in average emissions for a kWh of | an order of magnitude difference in average emissions for a kWh of | |||
electricity between two countries. Thus, any estimates that seek to | electricity between two countries. Thus, any estimates that seek to | |||
compare the manufacturing and use phase emissions of a network | compare the manufacturing and use phase emissions of a network | |||
equipment would have to be calculated per country or region, and | equipment would have to be calculated per country or region, and | |||
there is no universal standard for the whole planet. | there is no universal standard for the whole planet. | |||
Long equipment lifetimes are only useful if the longer lifetimes can | Long equipment lifetimes are only useful if the longer lifetimes can | |||
be achieved without compromising other aspects of sustainability, | be achieved without compromising other aspects of sustainability, | |||
such as when using a high-end and power-hungry router in place of | such as when using a high-end and power-hungry router in place of | |||
small routers. The exact moment when a hardware change is warranted | small routers. The exact moment when a hardware change is warranted | |||
for sustainability differs between countries and regions. | for sustainability differs between countries and regions. | |||
2.5.2. Analysis | 3.3.2. Analysis | |||
When we engineer protocols and network equipment, we are inclined to | When we engineer protocols and network equipment, we are inclined to | |||
design them in a highly optimized manner for a very specific set of | design them in a highly optimized manner for a very specific set of | |||
requirements, use cases and context. While this is necessary in | requirements, use cases and context. While this is necessary in | |||
certain cases (e.g. constrained nodes with limits on processing | certain cases (e.g. constrained nodes with limits on processing | |||
capacity or long lived battery powered devices), there are certainly | capacity or long-lived battery powered devices), there are certainly | |||
cases where such optimized equipment is not absolutely required. | cases where such optimized equipment is not absolutely required. | |||
Most infrastucture network nodes on the Internet utilize only a | Most infrastructure network nodes on the Internet utilize only a | |||
fraction of their design capacity most of the time. | fraction of their design capacity most of the time. | |||
Designing the equipment with an eye on longevity comes with a set of | Designing the equipment with an eye on longevity comes with a set of | |||
advantages: | advantages: | |||
* It allows the same equipment and protocols be reused in a | * It allows the same equipment and protocols be reused in a | |||
different context in the future. e.g. A core router of today can | different context in the future. e.g. A core router of today can | |||
become an edge router in a near future and an access router in the | become an edge router in a near future and an access router in the | |||
further future if the protocol implementations are adaptable. | further future if the protocol implementations are adaptable. | |||
skipping to change at page 19, line 14 ¶ | skipping to change at line 889 ¶ | |||
Another aspect that can play an important role in extending the | Another aspect that can play an important role in extending the | |||
longevity of equipment concerns software-defined networking, in the | longevity of equipment concerns software-defined networking, in the | |||
sense of designing networking equipment in such a way that new | sense of designing networking equipment in such a way that new | |||
equipment capabilities and features can be introduced via software | equipment capabilities and features can be introduced via software | |||
upgrades as opposed to requiring hardware replacement. This requires | upgrades as opposed to requiring hardware replacement. This requires | |||
system architectures that incorporate the necessary infrastructure to | system architectures that incorporate the necessary infrastructure to | |||
support such upgrades in a secure manner that does not compromise | support such upgrades in a secure manner that does not compromise | |||
equipment integrity. | equipment integrity. | |||
2.5.3. Recommendation | On the other hand, it is very much possible that there could be new | |||
equipment available that is significantly more sustainable in its | ||||
operation. The longevity of the existing equipment and the | ||||
amortization of its embedded sustainability costs, needs to be | ||||
balanced against the potential operational savings to be realized by | ||||
upgrading to newer equipment over the intended lifecycle of the newer | ||||
equipment. | ||||
3.3.3. Recommendation | ||||
The guidelines above should be considered for any new system design. | The guidelines above should be considered for any new system design. | |||
If some aspect of protocol or network equipment design choice could | If some aspect of protocol or network equipment design choice could | |||
be made more generic and flexible without a significant performance | be made more generic and flexible without a significant performance | |||
and sustainability impact, it needs to be studied in further detail. | and sustainability impact, it needs to be studied in further detail. | |||
Specifically, the potential additional sustainability costs due to | Specifically, the potential additional sustainability costs due to | |||
forgoing optimization need to be weighed against the potential | forgoing optimization need to be weighed against the potential | |||
savings in embedded carbon and raw material costs brought about by | savings in embedded carbon and raw material costs brought about by | |||
premature upgrades. There are also cases where equipment upgrades | premature upgrades. | |||
are done to provide better peak performance characteristics (e.g. | ||||
higher advertised speeds towards consumers) and these need to be | ||||
viewed as well with the same tradeoffs in mind. Finally, when | ||||
designing networks it is recommended to consider whether it is | ||||
possible to reuse retiring equipment in a different location or for a | ||||
different function (e.g. move it to lower traffic geographies, core | ||||
routers become edge/access routers etc.) | ||||
2.6. Compact encoding | There are also cases where equipment upgrades are done to provide | |||
better peak performance characteristics (e.g. higher advertised | ||||
speeds towards consumers) and these need to be viewed as well with | ||||
the same tradeoffs in mind. Also, when newer more sustainable | ||||
equipment is available there needs to be a cost benefit analysis made | ||||
to decide whether to keep current equipment running for longer or | ||||
upgrade to realize the benefits of newer equipment even though it | ||||
incurs new embedded costs. | ||||
Finally, when designing networks, it is recommended to consider | ||||
whether it is possible to reuse retiring equipment in a different | ||||
location or for a different function (e.g. move it to lower traffic | ||||
geographies, core routers become edge/access routers etc.) | ||||
3.4. Encoding | ||||
This is about considering the effects encoding methods on | This is about considering the effects encoding methods on | |||
sustainability, such as the use of binary encodings instead of text. | sustainability, such as the use of binary encodings instead of text. | |||
2.6.1. Motivation | 3.4.1. Motivation | |||
Better encoding can obviously reduce the length of messages sent. It | Better encoding can obviously reduce the length of messages sent or | |||
remains a question mark how big overall impact this is, however. It | reduce the amount of computing required for the encoding and decoding | |||
should only be performed if it gives a measurable overall impact. | operations. It remains a question mark how big overall impact this | |||
is, however. It should only be performed if it gives a measurable | ||||
overall impact. | ||||
2.6.2. Analysis | 3.4.2. Analysis | |||
Better encoding methods are clearly beneficial for improving the | Better encoding methods are clearly beneficial for improving the | |||
detailed-level effectiveness of communications. | detailed-level effectiveness of communications. | |||
The main questions are, however: | The main questions are, however: | |||
* Is the effect of this is at a magnitude comparable to the other | * How large are the potential remaining savings in this area, and | |||
things, or if it is just absolutely tiny? Particularly | how do they compare to other things? Particularly considering | |||
considering that much of the traffic on the Internet is video, and | that much of the traffic on the Internet is video, which is | |||
much of that is other content than, e.g., HTTP headers. Moran et | already highly optimized and constantly updated with better | |||
al. argued in their 2022 paper [CBORGreener] [RFC9547] that that | encoding methods. Moran et al. argued in their 2022 paper | |||
for a weather data example from [RFC8428] [RFC9193] there are | [CBORGreener] [RFC9547] that that for a weather data example from | |||
significant savings. However, this needs more research in terms | [RFC8428] [RFC9193] there are significant savings. However, this | |||
of the overall impact across different examples and the general | needs more research in terms of the overall impact across | |||
make up of Internet traffic. | different examples and the general make up of Internet traffic. | |||
* At what layer is the compactness achieved? Are link, IP, or | * At what layer is the compactness achieved? Are link, IP, or | |||
transport layer mechanisms that can compact some of the verbose | transport layer mechanisms that can compact some of the verbose | |||
messaging useful, or should each protocol have optimal compacting? | messaging useful, or should each protocol have optimal compacting? | |||
* Tradeoffs related to compressing (particularly if AI-based | * Tradeoffs related to compute required to do encoding and decoding | |||
computationally expensive methods are used). | operations. These can be relatively heavy operations, | |||
particularly if compression is performed, particularly if AI-based | ||||
computationally expensive methods are used. | ||||
2.6.3. Recommendation | 3.4.3. Recommendation | |||
More research is needed to quantify the likely sources of measurable | More research is needed to quantify the likely sources of measurable | |||
impacts. | impacts. | |||
Of course, new protocols can generally be designed to work with | Of course, new protocols can generally be designed to work with | |||
compact encoding, unless there is a significant reason not to. But | compact encoding, unless there is a significant reason not to. But | |||
efforts to modify existing protocols for the sake of encoding | efforts to modify existing protocols for the sake of encoding | |||
efficiency should be further investigated by the above mentioned | efficiency should be further investigated by the above-mentioned | |||
quantification results. | quantification results. | |||
2.7. Sustainable by Design: Data Governance Perspective | One particular area of interest is the impact of AI-based compression | |||
methods and their computational and energy costs vs. achieved savings | ||||
in communication efficiencies. | ||||
3.5. Sustainable by Design: Data Governance Perspective | ||||
Incorporating sustainability into the design phase of network | Incorporating sustainability into the design phase of network | |||
architecture is critical for ensuring long-term environmental and | architecture is critical for ensuring long-term environmental and | |||
operational benefits. From a Data Governance point of view, | operational benefits. From a Data Governance point of view, | |||
"Sustainable by Design" involves embedding sustainability principles | "Sustainable by Design" involves embedding sustainability principles | |||
and practices into the data management frameworks and processes from | and practices into the data management frameworks and processes from | |||
the outset. | the outset. | |||
2.7.1. Motivation | 3.5.1. Motivation | |||
Data governance plays a pivotal role in shaping how data is | Data governance plays a pivotal role in shaping how data is | |||
collected, stored, processed, and used. By integrating | collected, stored, processed, and used. By integrating | |||
sustainability into these processes, organizations can ensure that | sustainability into these processes, organizations can ensure that | |||
their data practices contribute to environmental goals, such as | their data practices contribute to environmental goals, such as | |||
reducing carbon footprints, optimizing resource usage, and minimizing | reducing carbon footprints, optimizing resource usage, and minimizing | |||
waste. | waste. | |||
2.7.2. Analysis | 3.5.2. Analysis | |||
Key elements of Sustainable by Design in data governance include: | Key elements of Sustainable by Design in data governance include: | |||
* Data Minimization: Collecting only the data that is necessary and | * Data Minimization: Collecting only the data that is necessary and | |||
useful, reducing storage and processing requirements, which in | useful, reducing storage and processing requirements, which in | |||
turn lowers energy consumption. | turn lowers energy consumption. | |||
* Efficient Data Storage Solutions: Implementing energy-efficient | * Efficient Data Storage Solutions: Implementing energy-efficient | |||
data storage technologies and practices that prioritize reduced | data storage technologies and practices that prioritize reduced | |||
power usage and cooling needs. | power usage and cooling needs. | |||
* Lifecycle Management: Ensuring that data is managed throughout its | * Lifecycle Management: Ensuring that data is managed throughout its | |||
lifecycle in a way that minimizes environmental impact, including | lifecycle in a way that minimizes environmental impact, including | |||
secure and sustainable data disposal practices. | secure and sustainable data disposal practices. | |||
* Transparency and Accountability: Establishing clear data | * Transparency and Accountability: Establishing clear data | |||
governance policies that promote transparency in data usage and | governance policies that promote transparency in data usage and | |||
accountability for sustainability objectives. | accountability for sustainability objectives. | |||
2.7.3. Recommendation | 3.5.3. Recommendation | |||
Organizations should adopt data governance frameworks that | Organizations should adopt data governance frameworks that | |||
incorporate sustainability as a core principle. This includes | incorporate sustainability as a core principle. This includes | |||
setting clear sustainability goals, measuring progress towards these | setting clear sustainability goals, measuring progress towards these | |||
goals, and continuously improving data management practices to | goals, and continuously improving data management practices to | |||
enhance sustainability. By doing so, organizations can ensure that | enhance sustainability. By doing so, organizations can ensure that | |||
their data operations are not only effective but also environmentally | their data operations are not only effective but also environmentally | |||
responsible. | responsible. | |||
3. Recommendations for Further Work and Research | There is a protocol designer angle in this as well. Protocol | |||
designers should consider at least the data minimization aspects from | ||||
Section 3.5.2, and may additionally consider providing mechanisms for | ||||
the lifecycle management and transparency aspects. | ||||
Dynamic scaling, i.e., the ability to respond to demand variations | 4. Recommendations for Protocol Design | |||
and resiliency requirements while optimizing energy consumption | ||||
clearly has significant potential for savings. Past and ongoing work | ||||
in various systems and protocols has looked at this, of course, but | ||||
we believe work also remains. Any large scale system likely benefits | ||||
from further analysis, unless already ongoing. Guidance in | ||||
{dynscale} simple, and further work in detailing this guidance would | ||||
also be useful. | ||||
Transport-related optimizations (see {transport}) that enable devices | The recommendations that can be applied by protocol designers and | |||
to consume less power by sleeping more appear to have potential for | architects have been listed in Section 2 and Section 3. | |||
significant savings, but confirming this requires further research. | Specifically: | |||
Such research could be performed in the context of the recently | ||||
chartered SUSTAIN research group. | ||||
More research is needed to quantify the likely sources of measurable | * Measurement and modeling are a necessary foundation to understand | |||
impacts when it comes to efficient protocol message encoding | where environmental impacts are generated, and to quantify any | |||
discussed in {encoding}. Again, this is work that the research group | improvements. The recommendations related to this topic were | |||
could take on. | listed in Section 2.1.3. These are primarily about ensuring that | |||
the measurement frameworks are generic enough to support data | ||||
collection for an evolving set of metrics, and to prepare for the | ||||
possibility that mathematical modeling may have to replace | ||||
measurements in some cases. | ||||
TBD | * Dynamic scaling is the ability to respond to demand variations and | |||
resiliency requirements while optimizing energy consumption | ||||
clearly has significant potential for savings. Recommendations | ||||
related to this were listed in Section 3.1.3. These are about | ||||
some basic techniques for being able to scale systems up and down | ||||
while avoiding negative effects from these operations. | ||||
... | * Transport-related recommendations were listed in Section 3.2. | |||
These are about tradeoffs associated with different transport | ||||
strategies. | ||||
4. Security Considerations | * Longevity-related recommendations were listed in Section 3.3.3. | |||
These are primarily about how equipment can fulfill evolving roles | ||||
over its lifetime, and associated tradeoffs. | ||||
* Encoding-related recommendations were listed in Section 3.4.3. | ||||
These are about the effects of encoding size in protocols, and the | ||||
associated compression computing impacts. | ||||
* Data governance-related recommendations were listed in | ||||
Section 3.5.3. These are primarily about ensuring the right | ||||
amount of data is collected, stored, and processed, in view of the | ||||
effort required to do so. | ||||
5. Recommendations for Further Work and Research | ||||
There are several areas where concrete advice for protocol designers | ||||
could not be given, or additional advice would be useful, but we do | ||||
not understand the situation well enough to give practical advice. | ||||
These include: | ||||
* Past and ongoing work in various systems and protocols has looked | ||||
at dynamic scaling extensively, but we believe work also remains. | ||||
Any large-scale system likely benefits from further analysis, | ||||
unless already ongoing. Guidance in Section 3.1 simple, and | ||||
further work in detailing this guidance would also be useful. | ||||
* Transport-related optimizations (see Section 3.2) that enable | ||||
devices to consume less power by sleeping more appear to have | ||||
potential for significant savings but confirming this requires | ||||
further research. Such research could be performed in the context | ||||
of the recently chartered SUSTAIN research group. | ||||
* More research is needed to quantify the likely sources of | ||||
measurable impacts when it comes to efficient protocol message | ||||
encoding discussed in Section 3.4. Also, the tradeoffs involving | ||||
the use AI-based compression methods deserve further study. | ||||
Again, these are topics that the research group could take on. | ||||
6. Security Considerations | ||||
It is possible that the introduction of features and architectural | It is possible that the introduction of features and architectural | |||
properties to facilitate environmentally sustainable Internet | properties to facilitate environmentally sustainable Internet | |||
technology introduces new attack vectors or other security | technology introduces new attack vectors or other security | |||
ramifications. | ramifications. | |||
For example, the introduction of measurements and metrics for the | For example, the introduction of measurements and metrics for the | |||
purpose of saving energy could be misused for the opposite effect | purpose of saving energy could be misused for the opposite effect | |||
when compromised. For example, measurements might be tampered with | when compromised. For example, measurements might be tampered with | |||
in order to cause an operator to waste energy. Energy measurements, | in order to cause an operator to waste energy. Energy measurements, | |||
skipping to change at page 22, line 31 ¶ | skipping to change at line 1116 ¶ | |||
by allowing to infer usage profiles. They could also be abused to | by allowing to infer usage profiles. They could also be abused to | |||
implement a covert communications channel in which information is | implement a covert communications channel in which information is | |||
leaked via tampered measurement values that are being reported. | leaked via tampered measurement values that are being reported. | |||
Networking features and technology choices may have security | Networking features and technology choices may have security | |||
implications regardless of why they are introduced, including for | implications regardless of why they are introduced, including for | |||
reasons of environmental sustainability. The possibility of this | reasons of environmental sustainability. The possibility of this | |||
needs to be taken into consideration, understood, and communicated to | needs to be taken into consideration, understood, and communicated to | |||
allow for their mitigation. | allow for their mitigation. | |||
5. IANA Considerations | 7. IANA Considerations | |||
This document has no IANA actions. | This document has no IANA actions. | |||
6. Informative References | 8. Informative References | |||
[Baseline] Livieratos, S., Panetsos, S., Fotopoulos, A., and M. | [Baseline] Livieratos, S., Panetsos, S., Fotopoulos, A., and M. | |||
Karagiorgas, "A New Proposed Energy Baseline Model for a | Karagiorgas, "A New Proposed Energy Baseline Model for a | |||
Data Center as a Tool for Energy Efficiency Evaluation", | Data Center as a Tool for Energy Efficiency Evaluation", | |||
International Journal of Power and Energy Research, Vol. | International Journal of Power and Energy Research, Vol. | |||
3, No. 1 , April 2019. | 3, No. 1 , April 2019. | |||
[BenchmarkingFramework] | [BenchmarkingFramework] | |||
Mahadevan, P., Sharma, P., Banerjee, S., and P. | Mahadevan, P., Sharma, P., Banerjee, S., and P. | |||
Ranganathan, "A Power Benchmarking Framework for Network | Ranganathan, "A Power Benchmarking Framework for Network | |||
skipping to change at page 23, line 26 ¶ | skipping to change at line 1155 ¶ | |||
[I-D.cparsk-eimpact-sustainability-considerations] | [I-D.cparsk-eimpact-sustainability-considerations] | |||
Pignataro, C., Rezaki, A., Krishnan, S., ElBakoury, H., | Pignataro, C., Rezaki, A., Krishnan, S., ElBakoury, H., | |||
and A. Clemm, "Sustainability Considerations for | and A. Clemm, "Sustainability Considerations for | |||
Internetworking", Work in Progress, Internet-Draft, draft- | Internetworking", Work in Progress, Internet-Draft, draft- | |||
cparsk-eimpact-sustainability-considerations-07, 24 | cparsk-eimpact-sustainability-considerations-07, 24 | |||
January 2024, <https://datatracker.ietf.org/doc/html/ | January 2024, <https://datatracker.ietf.org/doc/html/ | |||
draft-cparsk-eimpact-sustainability-considerations-07>. | draft-cparsk-eimpact-sustainability-considerations-07>. | |||
[I-D.ietf-tvr-alto-exposure] | [I-D.ietf-tvr-alto-exposure] | |||
Contreras, L. M., "Using ALTO for exposing Time-Variant | Contreras, L. M., "Using off-path mechanisms for exposing | |||
Routing information", Work in Progress, Internet-Draft, | Time-Variant Routing information", Work in Progress, | |||
draft-ietf-tvr-alto-exposure-00, 23 December 2024, | Internet-Draft, draft-ietf-tvr-alto-exposure-02, 5 July | |||
<https://datatracker.ietf.org/doc/html/draft-ietf-tvr- | 2025, <https://datatracker.ietf.org/doc/html/draft-ietf- | |||
alto-exposure-00>. | tvr-alto-exposure-02>. | |||
[I-D.ietf-tvr-requirements] | [I-D.ietf-tvr-requirements] | |||
King, D., Contreras, L. M., Sipos, B., and L. Zhang, "TVR | King, D., Contreras, L. M., Sipos, B., and L. Zhang, "TVR | |||
(Time-Variant Routing) Requirements", Work in Progress, | (Time-Variant Routing) Requirements", Work in Progress, | |||
Internet-Draft, draft-ietf-tvr-requirements-05, 3 March | Internet-Draft, draft-ietf-tvr-requirements-05, 3 March | |||
2025, <https://datatracker.ietf.org/doc/html/draft-ietf- | 2025, <https://datatracker.ietf.org/doc/html/draft-ietf- | |||
tvr-requirements-05>. | tvr-requirements-05>. | |||
[I-D.ietf-tvr-schedule-yang] | [I-D.ietf-tvr-schedule-yang] | |||
Qu, Y., Lindem, A., Kinzie, E., Fedyk, D., and M. | Qu, Y., Lindem, A., Kinzie, E., Fedyk, D., and M. | |||
Blanchet, "YANG Data Model for Scheduled Attributes", Work | Blanchet, "YANG Data Model for Scheduled Attributes", Work | |||
in Progress, Internet-Draft, draft-ietf-tvr-schedule-yang- | in Progress, Internet-Draft, draft-ietf-tvr-schedule-yang- | |||
03, 20 October 2024, | 05, 4 July 2025, <https://datatracker.ietf.org/doc/html/ | |||
<https://datatracker.ietf.org/doc/html/draft-ietf-tvr- | draft-ietf-tvr-schedule-yang-05>. | |||
schedule-yang-03>. | ||||
[I-D.irtf-nmrg-green-ps] | ||||
Clemm, A., Pignataro, C., Westphal, C., Ciavaglia, L., | ||||
Tantsura, J., and M. Odini, "Challenges and Opportunities | ||||
in Management for Green Networking", Work in Progress, | ||||
Internet-Draft, draft-irtf-nmrg-green-ps-06, 15 March | ||||
2025, <https://datatracker.ietf.org/doc/html/draft-irtf- | ||||
nmrg-green-ps-06>. | ||||
[I-D.pignataro-enviro-sustainability-architecture] | [I-D.pignataro-enviro-sustainability-architecture] | |||
Pignataro, C., Rezaki, A., Krishnan, S., Arkko, J., Clemm, | Pignataro, C., Rezaki, A., Krishnan, S., Arkko, J., Clemm, | |||
A., and H. ElBakoury, "Architectural Considerations for | A., ElBakoury, H., and S. Prabhu, "Architectural | |||
Environmental Sustainability", Work in Progress, Internet- | Considerations for Environmental Sustainability", Work in | |||
Draft, draft-pignataro-enviro-sustainability-architecture- | Progress, Internet-Draft, draft-pignataro-enviro- | |||
01, 27 December 2024, | sustainability-architecture-02, 12 May 2025, | |||
<https://datatracker.ietf.org/doc/html/draft-pignataro- | <https://datatracker.ietf.org/doc/html/draft-pignataro- | |||
enviro-sustainability-architecture-01>. | enviro-sustainability-architecture-02>. | |||
[I-D.pignataro-enviro-sustainability-consid] | ||||
Pignataro, C., Rezaki, A., Arkko, J., Clemm, A., | ||||
ElBakoury, H., and S. Prabhu, "Sustainability | ||||
Considerations for Networking Protocols and Applications", | ||||
Work in Progress, Internet-Draft, draft-pignataro-enviro- | ||||
sustainability-consid-02, 12 May 2025, | ||||
<https://datatracker.ietf.org/doc/html/draft-pignataro- | ||||
enviro-sustainability-consid-02>. | ||||
[LCAandUsage] | ||||
Weppe, O., Bekri, D., Guibert, L., Aubet, L., Prévotet, | ||||
J., Pelcat, M., and S. Rumley, "Carbon Topography | ||||
Representation: Improving Impacts of Data Center | ||||
Lifecycle", Proceedings of the 4th Workshop on Sustainable | ||||
Computer Systems (HotCarbon'25) , 2025. | ||||
[LinkAggregation] | [LinkAggregation] | |||
"IEEE Standard for Local and Metropolitan Area Networks-- | "IEEE Standard for Local and Metropolitan Area Networks-- | |||
Link Aggregation", IEEE STD 802.1AX-2020 (Revision of IEEE | Link Aggregation", IEEE STD 802.1AX-2020 (Revision of IEEE | |||
STD 802.1AX-2014): 1–333. doi:10.1109/ | STD 802.1AX-2014): 1–333. doi:10.1109/ | |||
IEEESTD.2020.9105034. ISBN 978-1-5044-6428-4 , May 2020. | IEEESTD.2020.9105034. ISBN 978-1-5044-6428-4 , May 2020. | |||
[LoadShifting] | [LoadShifting] | |||
Mathew, V., Sitaraman, R. K., and P. Shenoy, "Reducing | Mathew, V., Sitaraman, R. K., and P. Shenoy, "Reducing | |||
energy costs in Internet-scale distributed systems using | energy costs in Internet-scale distributed systems using | |||
skipping to change at page 25, line 44 ¶ | skipping to change at line 1283 ¶ | |||
[Unifying] Ishii, K., Kurumida, J., K.-i Sato, Kudoh, T., and S. | [Unifying] Ishii, K., Kurumida, J., K.-i Sato, Kudoh, T., and S. | |||
Namiki, "Unifying Top-Down and Bottom-Up Approaches to | Namiki, "Unifying Top-Down and Bottom-Up Approaches to | |||
Evaluate Network Energy Consumption", In Journal of | Evaluate Network Energy Consumption", In Journal of | |||
Lightwave Technology, vol. 33, no. 21, pp. 4395-4405, doi: | Lightwave Technology, vol. 33, no. 21, pp. 4395-4405, doi: | |||
10.1109/JLT.2015.2469145 , November 2015. | 10.1109/JLT.2015.2469145 , November 2015. | |||
[UNSDG] "United Nations Sustainable Development Goals", | [UNSDG] "United Nations Sustainable Development Goals", | |||
https://unstats.un.org/sdgs , 2017. | https://unstats.un.org/sdgs , 2017. | |||
Appendix A. Modeling Approaches and Literature | ||||
The paper [Modeling] provides a model for IP Routers and the routers | ||||
of other future Internet architectures (FIA) such as SCION and | ||||
NEBULA. They use a generic model which captures the commonalities of | ||||
IP router as well as the peculiarities of FIA routers. They conduct | ||||
a large-scale simulation based on this router model to estimate the | ||||
power consumption for different network architectures. | ||||
Since routers and other network devices and functions can be | ||||
virtualized, this article (1) provides comprehensive "graphical, | ||||
analytical survey of the literature, over the period 2010–2020, on | ||||
the measurement of power consumption and relevant power models of | ||||
virtual entities as they apply to the telco cloud." This paper A | ||||
Methodology and Testbed to Develop an Energy Model for 5G Virtualized | ||||
RANs IEEE Conference Publication IEEE Xplore got best paper award for | ||||
GreenNet 2024, but I am not sure if we are interested to model 5G | ||||
vRAN. | ||||
There is a plethora of publications on modeling communication | ||||
networks and DC computing. | ||||
A.1. Customer Attribution | ||||
When organizations assess their Scope 3 emissions, they need to sum | ||||
up their share of emissions from all their suppliers, one of which | ||||
for example, might be a cloud hosting service. In order for the | ||||
supplier to provide an emission share value back to the customer, the | ||||
provider needs to develop a mechanism for attribution. | ||||
A significant challenge in accurately assessing Scope 3 emissions is | ||||
avoiding Double Counting, where the same emission is reported by | ||||
multiple entities. According to the GHG Protocol best practices, it | ||||
is crucial to establish clear guidelines and agreements between | ||||
suppliers and customers to ensure that emissions are attributed | ||||
correctly and not counted multiple times. This requires transparent | ||||
communication and precise emission reporting standards to ensure that | ||||
all parties involved have a consistent understanding of which | ||||
emissions belong to which organization. | ||||
By addressing the Double Counting issue, companies can achieve more | ||||
accurate and reliable Scope 3 emissions assessments, thereby | ||||
contributing to better overall sustainability reporting and | ||||
improvement efforts. | ||||
A.2. Baselining and Benchmarking | ||||
Establishing a baseline is a fundamental step in the process of | ||||
improving energy efficiency and sustainability of network technology. | ||||
Baselining involves establishing a reference point of typical energy | ||||
usage, which is crucial for identifying inefficiencies and measuring | ||||
improvements over time. In this step, the controller uses only the | ||||
collected data from datasheets and other reliable sources. | ||||
By establishing a baseline and using benchmarking, organizations can | ||||
determine if their networking equipment is performing normally or if | ||||
it is deviating from expected performance. This is the first step in | ||||
identifying and guiding necessary improvements. Benchmarking | ||||
involves collecting performance measurements of networking equipment | ||||
under controlled conditions. This process helps establish | ||||
standardized performance metrics, allowing for comparison against | ||||
baselines collected during regular operational conditions. | ||||
The initial measurement of networking equipment's energy efficiency | ||||
and performance, known as Baselining, should be coordinated with | ||||
vendor specifications and industry standards to understand what is | ||||
considered normal or optimal performance. For example, if the | ||||
baseline indicates that your switches operate at 5 Gbps per watt, | ||||
while vendor specifications suggest 8 Gbps per watt and the industry | ||||
standard is 10 Gbps per watt, actions should be taken to implement | ||||
energy-saving measures and upgrades. Continuously tracking | ||||
subsequent measurements can reveal if efficiency improves towards the | ||||
benchmark of 8-10 Gbps per watt. | ||||
This practice ensures that any improvements can be quantifiably | ||||
tracked over time, providing a clear measure of the effectiveness of | ||||
the implemented changes and guiding further enhancements in network | ||||
sustainability. | ||||
See also [Baseline] and [BenchmarkingFramework]. | ||||
Acknowledgments | Acknowledgments | |||
Everyone on the author section has contributed to the document in | Everyone on the author section has contributed to the document in | |||
significant ways. The author list has been ordered in (reverse) | significant ways. The author list has been ordered in (reverse) | |||
alphabethical order. | alphabethical order. | |||
Parts of this document extensively leverage ideas and text from | Parts of this document extensively leverage ideas and text from | |||
[I-D.cparsk-eimpact-sustainability-considerations] and | [I-D.cparsk-eimpact-sustainability-considerations] and | |||
[I-D.pignataro-enviro-sustainability-architecture] and associated | [I-D.pignataro-enviro-sustainability-architecture] and associated | |||
discussions in the IETF, IRTF, and IAB groups. We acknowledge and | discussions in the IETF, IRTF, and IAB groups. We acknowledge and | |||
End of changes. 107 change blocks. | ||||
409 lines changed or deleted | 620 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |