rfc9845xml2.original.xml | rfc9845.xml | |||
---|---|---|---|---|
<?xml version="1.0"?> | <?xml version='1.0' encoding='UTF-8'?> | |||
<!DOCTYPE rfc [ | <!DOCTYPE rfc [ | |||
<!ENTITY RFC.2481 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RF | <!ENTITY nbsp " "> | |||
C.2481.xml"> | <!ENTITY zwsp "​"> | |||
<!ENTITY RFC.3031 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RF | <!ENTITY nbhy "‑"> | |||
C.3031.xml"> | <!ENTITY wj "⁠"> | |||
<!ENTITY RFC.3095 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RF | ||||
C.3095.xml"> | ||||
<!ENTITY RFC.7950 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RF | ||||
C.7950.xml"> | ||||
<!ENTITY RFC.8402 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RF | ||||
C.8402.xml"> | ||||
<!ENTITY RFC.9330 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RF | ||||
C.9330.xml"> | ||||
]> | ]> | |||
<?rfc comments="yes"?> | <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-i | |||
<?rfc compact="no"?> | rtf-nmrg-green-ps-06" number="9845" updates="" obsoletes="" consensus="true" xml | |||
<?rfc inline="yes"?> | :lang="en" ipr="trust200902" submissionType="IRTF" sortRefs="true" symRefs="true | |||
<?rfc sortrefs="yes"?> | " tocInclude="true" tocDepth="5" version="3"> | |||
<?rfc subcompact="no"?> | ||||
<?rfc symrefs="yes"?> | ||||
<?rfc toc="yes"?> | ||||
<?rfc tocdepth="5"?> | ||||
<?rfc tocindent="yes"?> | ||||
<?rfc tocompact="yes"?> | ||||
<rfc category="info" docName="draft-irtf-nmrg-green-ps-06" ipr="trust200902" | ||||
submissionType="IRTF"> | ||||
<front> | ||||
<title abbrev="Management for Green Networking">Challenges and Opportunities in | ||||
Management for Green Networking</title> | ||||
<author fullname="Alexander Clemm" initials="A." | <front> | |||
surname="Clemm" role="editor"> | <title abbrev="Management for Green Networking">Challenges and Opportunities | |||
<organization>Independent</organization> | in Management for Green Networking</title> | |||
<address> | <seriesInfo name="RFC" value="9845"/> | |||
<author fullname="Alexander Clemm" initials="A." surname="Clemm" role="edito | ||||
r"> | ||||
<organization>Independent</organization> | ||||
<address> | ||||
<postal> | <postal> | |||
<city>Los Gatos, CA</city> | <city>Los Gatos</city><region>CA</region> | |||
<country>US</country> | <country>United States of America</country> | |||
</postal> | </postal> | |||
<phone></phone> | ||||
<email>ludwig@clemm.org</email> | <email>ludwig@clemm.org</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author fullname="Carlos Pignataro" initials="C." surname="Pignataro" role=" editor"> | <author fullname="Carlos Pignataro" initials="C." surname="Pignataro" role=" editor"> | |||
<organization abbrev="NC State University">North Carolina State University </organization> | <organization abbrev="NC State University">North Carolina State University </organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<country>US</country> | <country>United States of America</country> | |||
</postal> | </postal> | |||
<email>cpignata@gmail.com</email> | <email>cpignata@gmail.com</email> | |||
<email>cmpignat@ncsu.edu</email> | <email>cmpignat@ncsu.edu</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author fullname="Cedric Westphal" initials="C" surname="Westphal"> | ||||
<author fullname="Cedric Westphal" initials="C" | <address> | |||
surname="Westphal"> | <email>westphal@ieee.org</email> | |||
<address> | </address> | |||
<email>westphal@ieee.org</email> | </author> | |||
</address> | <author fullname="Laurent Ciavaglia" initials="L" surname="Ciavaglia"> | |||
</author> | <organization>Nokia</organization> | |||
<address> | ||||
<author fullname="Laurent Ciavaglia" initials="L" surname="Ciavaglia"> | ||||
<organization>Nokia</organization> | ||||
<address> | ||||
<email>laurent.ciavaglia@nokia.com</email> | <email>laurent.ciavaglia@nokia.com</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author fullname="Jeff Tantsura" initials="J" surname="Tantsura"> | ||||
<author fullname="Jeff Tantsura" initials="J" surname="Tantsura"> | <organization>Nvidia</organization> | |||
<organization>Nvidia</organization> | <address> | |||
<address> | ||||
<email>jefftant.ietf@gmail.com</email> | <email>jefftant.ietf@gmail.com</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author fullname="Marie-Paule Odini" initials="M-P" surname="Odini"> | ||||
<author fullname="Marie-Paule Odini" initials="M-P" surname="Odini"> | <address> | |||
<address> | ||||
<email>mp.odini@orange.fr</email> | <email>mp.odini@orange.fr</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<date month="August" year="2025"/> | ||||
<date day="16" month="3" year="2025" /> | <workgroup>Network Management</workgroup> | |||
<abstract> | <!-- [rfced] Please insert any keywords (beyond those that appear in | |||
<t> | the title) for use on https://www.rfc-editor.org/search. --> | |||
Reducing humankind's environmental footprint and making technology more envi | ||||
ronmentally sustainable are among the biggest challenges of our age. | ||||
Networks play an important part in this challenge. On one hand, they enable | ||||
applications that help to reduce this footprint. On the other hand, they contri | ||||
bute to this footprint themselves in no insignificant way. Therefore, methods t | ||||
o make networking technology itself "greener" and to manage and operate networks | ||||
in ways that reduce their environmental footprint without impacting their utili | ||||
ty need to be explored. This document outlines a corresponding set of opportuni | ||||
ties, along with associated research challenges, for networking technology in ge | ||||
neral and management technology in particular to become "greener", i.e., more su | ||||
stainable, with reduced greenhouse gas emissions and less negative impact on the | ||||
environment. | ||||
</t> | ||||
<t> | ||||
This document is a product of the Network Management Research Group (NMRG) of | ||||
the Internet Research Task Force (IRTF). This document reflects the consensus | ||||
of the research group. It is not a candidate for any level of Internet Standard | ||||
and is published for informational purposes. | ||||
</t> | ||||
</abstract> | ||||
</front> | <keyword>example</keyword> | |||
<middle> | <abstract> | |||
<section anchor="intro" title="Introduction"> | <t> | |||
Reducing humankind's environmental footprint and making technology more | ||||
environmentally sustainable are among the biggest challenges of our age. | ||||
Networks play an important part in this challenge. On one hand, they | ||||
enable applications that help to reduce this footprint. On the other hand, | ||||
they contribute to this footprint themselves in no insignificant way. | ||||
<!--[rfced] In the abstract, rather than "in no insignificant way", | ||||
we suggest making the sentence more direct. Is this update acceptable? | ||||
<section title="Motivation"> | Original: | |||
<t> | On the other hand, | |||
they contribute to this footprint themselves in no insignificant way. | ||||
Suggested: | ||||
On the other hand, | ||||
they significantly contribute to this footprint themselves. | ||||
--> | ||||
Therefore, methods to make networking technology itself "greener" and to | ||||
manage and operate networks in ways that reduce their environmental | ||||
footprint without impacting their utility need to be explored. This | ||||
document outlines a corresponding set of opportunities, along with | ||||
associated research challenges, for networking technology in general and | ||||
management technology in particular to become "greener", i.e., more | ||||
sustainable, with reduced greenhouse gas emissions and less negative | ||||
impact on the environment. | ||||
</t> | ||||
<t> | ||||
This document is a product of the Network Management Research Group (NMRG) | ||||
of the Internet Research Task Force (IRTF). This document reflects the | ||||
consensus of the research group. It is not a candidate for any level of | ||||
Internet Standard and is published for informational purposes. | ||||
</t> | ||||
</abstract> | ||||
</front> | ||||
<middle> | ||||
<!--[rfced] Several sentences in the original document that were difficult | ||||
to read have been reworded or separated into two sentences. In some cases, | ||||
a "FYI" has been added to call your attention to the edit. In general, please | ||||
review the edited document closely to make sure that the intended meaning | ||||
is intact. In particular, please review Sections 5.3 and 6.1. | ||||
--> | ||||
<section anchor="intro"> | ||||
<name>Introduction</name> | ||||
<section> | ||||
<name>Motivation</name> | ||||
<t> | ||||
Climate change and the need to curb greenhouse gas (GHG) emissions have been rec ognized | Climate change and the need to curb greenhouse gas (GHG) emissions have been rec ognized | |||
by the United Nations and by most governments as one of the big challenges of ou r time. | by the United Nations and by most governments as one of the big challenges of ou r time. | |||
As a result, curbing those emissions is becoming of | As a result, curbing those emissions is becoming | |||
increasing importance for society and for many industries. The networking indus | increasingly important for society and for many industries. The networking indu | |||
try is no | stry is no | |||
exception. | exception. | |||
</t> | </t> | |||
<t>The science behind greenhouse gas emissions and their relationship with clima | <!--[rfced] FYI, both "CO2" and "carbon" were used within the | |||
te change | same sentence; for consistency, the latter instance has been updated. | |||
is complex. However, there is overwhelming scientific consensus pointing towards | Please let us know if you prefer otherwise. | |||
a clear | ||||
Original: | ||||
Notable here is the use of fossil fuels, such as oil, | ||||
which releases CO2 that had long been removed from the earth's | ||||
atmosphere, as opposed to the use of renewable or sustainable fuels | ||||
that do not "add" to the amount of carbon in the atmosphere. | ||||
Current: | ||||
Notable here is the use of fossil fuels, such as oil, | ||||
which releases CO2 that had long been removed from the earth's | ||||
atmosphere, as opposed to the use of renewable or sustainable fuels | ||||
that do not "add" to the amount of CO2 in the atmosphere. | ||||
--> | ||||
<t>The science behind greenhouse gas emissions and their relationship wi | ||||
th climate change | ||||
is complex. However, there is overwhelming scientific consensus pointing toward | ||||
a clear | ||||
correlation between climate change and a rising amount of | correlation between climate change and a rising amount of | |||
greenhouse gases in the atmosphere. | greenhouse gases in the atmosphere. | |||
One greenhouse gas of particular concern, but by no means the only one, is carbo n | One greenhouse gas of particular concern, but by no means the only one, is carbo n | |||
dioxide (CO2). Carbon dioxide is emitted in the process of burning fuels to | dioxide (CO2). Carbon dioxide is emitted in the process of burning fuels to | |||
generate energy that is used, for example, to power electrical devices such as | generate energy that is used, for example, to power electrical devices such as | |||
networking equipment. Notable here is the use of fossil fuels, such as | networking equipment. Notable here is the use of fossil fuels (such as | |||
oil, which releases CO2 that had long been removed from the earth's atmosphere, | oil, which releases CO2 that has long been removed from the earth's atmosphere), | |||
as opposed to the use of renewable or sustainable fuels that do not "add" to the | as opposed to the use of renewable or sustainable fuels that do not "add" to the | |||
amount of carbon in the atmosphere. | amount of CO2 in the atmosphere. | |||
There are additional gases associated with electricity generation, in particular | There are additional gases associated with electricity generation, in particular | |||
Methane (CH4) and Nitrous Oxide (N2O). Although in smaller quantities, they hav | methane (CH4) and nitrous oxide (N2O). Although they exist in smaller quantitie | |||
e an even higher Global Warming Potential (GWP). | s, they have an even higher Global Warming Potential (GWP). | |||
</t> | </t> | |||
<t>Greenhouse gas emissions are in turn correlated with the need to power | <t>Greenhouse gas emissions are in turn correlated with the need to powe r | |||
technology, including networks. Reducing those emissions can be achieved by red ucing the | technology, including networks. Reducing those emissions can be achieved by red ucing the | |||
amount of fossil fuels needed to generate the energy that is needed to power | amount of fossil fuels needed to generate the energy that is needed to power | |||
those networks. | those networks. | |||
This can be achieved by improving the energy mix to include increasing | This can be achieved by improving the energy mix to include increasing | |||
amounts of low-carbon and/or renewable (and hence sustainable) energy sources su ch as wind or solar. | amounts of low-carbon and/or renewable (and hence sustainable) energy sources, s uch as wind or solar. | |||
It can also be achieved | It can also be achieved | |||
by increasing energy savings and improving energy efficiency so that the same ou tcomes | by increasing energy savings and improving energy efficiency so that the same ou tcomes | |||
are achieved while consuming less energy in the first place. | are achieved while consuming less energy in the first place. | |||
</t> | </t> | |||
<t>The amount of greenhouse gases that an activity adds to the atmosphere, such | <t>The amount of greenhouse gases that an activity adds to the atmospher | |||
as CO2 that is emitted in burning fossil fuels to generate the required energy, | e, such as CO2 that is emitted in burning fossil fuels to generate the required | |||
is also | energy, is also | |||
referred to as greenhouse footprint, or carbon footprint (accounting for greenho | referred to as the "greenhouse footprint" or the "carbon footprint" (accounting | |||
uses gases other than CO2 in terms of CO2 equivalents). Reducing this footprint | for greenhouses gases other than CO2 in terms of CO2 equivalents). Reducing thi | |||
to net-zero is hence a major | s footprint to net zero is hence a major | |||
sustainability goal. However, sustainability encompasses also other factors beyo | sustainability goal. However, sustainability encompasses other factors beyond ca | |||
nd carbon, | rbon, | |||
such as sustainable use of other natural resources, the preservation of natural | such as the sustainable use of other natural resources, the preservation of natu | |||
habitats | ral habitats | |||
and biodiversity, and the avoidance of any form of pollution. | and biodiversity, and the avoidance of any form of pollution. | |||
</t> | </t> | |||
<t>In the context of this document, we refer to networking technology that helps to improve its own networking | <t>In the context of this document, we refer to networking technology th at helps to improve its own networking | |||
sustainability as "green". Green, in that sense, includes technology that help s | sustainability as "green". Green, in that sense, includes technology that help s | |||
to lower networking's greenhouse gas emissions including carbon footprint, which turn includes technology that helps to increase efficiency and realize energy s avings as well as facilitating managing networks towards | to lower networking's greenhouse gas emissions including the carbon footprint, w hich in turn includes technology that helps increase efficiency and realize ener gy savings as well as facilitates managing networks toward a | |||
stronger use of renewables. | stronger use of renewables. | |||
</t> | </t> | |||
<t> | <!--[rfced] The phrase "as well as land use" doesn't parse in this | |||
sentence. Is the intended meaning that it minimizes the land area | ||||
that is used? Does the suggested text convey the intended meaning? | ||||
Original: | ||||
IoT applications that | ||||
facilitate automated monitoring and control from remote sites help | ||||
make agriculture more sustainable by minimizing the application of | ||||
resources such as water and fertilizer as well as land use. | ||||
Perhaps: | ||||
IoT applications that facilitate automated monitoring and control from | ||||
remote sites help make agriculture more sustainable by minimizing the | ||||
usage of water, fertilizer, and land area. | ||||
--> | ||||
<t> | ||||
Arguably, networks can already be considered a "green" technology in that networ ks enable many applications that allow users and whole industries to save energy and thus | Arguably, networks can already be considered a "green" technology in that networ ks enable many applications that allow users and whole industries to save energy and thus | |||
become environmentally more sustainable in a significant way. For example, they | become environmentally more sustainable in a significant way. For example, they | |||
allow (at least to an extent) to substitute travel with teleconferencing. They | allow (at least to an extent) to substitute travel with teleconferencing. They | |||
enable many employees to work from home and "telecommute", thus reducing the ne | enable many employees to work from home and telecommute, thus reducing the need | |||
ed for actual commute. IoT applications that facilitate automated monitoring and | for actual commuting. IoT applications that facilitate automated monitoring and | |||
control from remote sites help make agriculture more sustainable by minimizing | control from remote sites help make agriculture more sustainable by minimizing | |||
the application of resources such as water and fertilizer as well as land use. | the usage of water, fertilizer, and land area. Networked smart buildings allow | |||
Networked smart buildings allow for greater energy optimization and sparser use | for greater energy optimization and sparser use of lighting and HVAC (heating, v | |||
of lighting and HVAC (heating, ventilation, air conditioning) than their non-net | entilation, air conditioning) than their non-networked, not-so-smart counterpart | |||
worked not-so-smart counterparts. That said, calculating precise benefits in te | s. That said, calculating precise benefits in terms of net sustainability contr | |||
rms of net sustainability contributions and savings is complex as a holistic pic | ibutions and savings is complex, as a holistic picture involves many effects inc | |||
ture involves many effects, including substituion effects (perhaps saving on emi | luding substitution effects (perhaps saving on emissions caused by travel but in | |||
ssions caused by travel but incurring additional cost associated with additional | curring additional costs associated with additional home office use) as well as | |||
home office use) as well as behavioral changes (perhaps higher number of meetin | behavioral changes (perhaps a higher number of meetings than if travel were invo | |||
gs than if travel were involved). | lved). | |||
</t> | ||||
<t>The IETF has recently initiated a reflection on the energy cost of hosting me | ||||
etings three times a year (see for instance <xref target="IETF-Net0" />). It con | ||||
ducted a study of the carbon emissions of a typical meeting and found out that 9 | ||||
9% of the emissions were due to the air travel. In the same vein, <xref target=" | ||||
Framework" /> compared an in-person with a virtual meeting and found a reduction | ||||
in energy of 66% for a virtual meeting. These findings confirm that networking | ||||
technology can reduce emissions when acting as virtual substitution for physical | ||||
events. | ||||
</t> | ||||
<t> | ||||
That said, networks themselves consume significant amounts of energy. Therefore, | ||||
the networking industry has an important role to play in meeting sustainability | ||||
goals not just by enabling others to reduce their reliance on energy, but by al | ||||
so reducing its own. Future networking advances will increasingly need to focus | ||||
on becoming more energy-efficient and reducing carbon footprint, both for econo | ||||
mic reasons and for reasons of corporate responsibility. This shift has already | ||||
begun, and sustainability is already becoming an important concern for network p | ||||
roviders. In some cases, such as in the context of networked data centers, the a | ||||
bility to procure enough energy becomes a bottleneck prohibiting further growth | ||||
and greater sustainability thus becomes a business necessity. | ||||
</t> | ||||
<t> | ||||
For example, in its annual report, Telefónica reports that in 2021, its network' | ||||
s energy consumption per PB of data amounted to 54MWh <xref target="Telefonica20 | ||||
21"/>. This rate has been dramatically decreasing (a seven-fold factor over six | ||||
years) although gains in efficiency are being offset by simultaneous growth in | ||||
data volume. In the same report, it is stated as an important corporate goal to | ||||
continue on that trajectory and aggressively reduce overall carbon emissions fur | ||||
ther. | ||||
</t> | ||||
</section> | ||||
<section title="Approaching the Problem"> | ||||
<t> | ||||
An often-considered gain in networking sustainability can be made with regards t | ||||
o improving the efficiency with which networks utilize power during their use ph | ||||
ase, reducing the amount of energy that is required to provide communication ser | ||||
vices. However, for a holistic approach other aspects need to be considered as w | ||||
ell. | ||||
</t> | </t> | |||
<t>Environmental footprint is determined not by energy consumption alone. The s ustainability of power sources needs to be considered as well. A deployment tha t includes devices that are less energy-efficient but that are powered by a sust ainable energy source can arguably be considered "greener" than a deployment tha t includes highly efficient device that are powered by Diesel generators. In fa ct, in the same Telefónica report mentioned earlier, extensive reliance on renew able energy sources is emphasized. | <t>The IETF has recently initiated a reflection on the energy cost of ho sting meetings three times a year (see <xref target="IETF-Net0"/>). It conducted a study of the carbon emissions of a typical meeting and found out that 99% of the emissions were due to air travel. In the same vein, <xref target="Framework" /> compared an in-person with a virtual meeting and found a reduction in energy of 66% for a virtual meeting. These findings confirm that networking technology can reduce emissions when acting as a virtual substitution for physical events. | |||
</t> | </t> | |||
<t>Similarly, deployments can take other environmental factors into account that | <t> | |||
affect carbon footprint. For example, deployments in which factors such as the | That said, networks themselves consume significant amounts of energy. Therefore, | |||
need for cooling are reduced, or where excessive heat that is generated by equi | the networking industry has an important role to play in meeting sustainability | |||
pment can be put to productive use, will be considered greener than deployments | goals and not just by enabling others to reduce their reliance on energy but by | |||
where this is not the case. Examples include deployments in cooler natural surro | also reducing its own. Future networking advances will increasingly need to fo | |||
undings (e.g., in colder climates) where that is an option. Likewise, manufactu | cus on becoming more energy efficient and reducing the carbon footprint, for rea | |||
ring and recycling of networking equipment are also part of the sustainability e | sons of both corporate responsibility and economics. This shift has already begu | |||
quation, as the production itself consumes energy and results in a carbon cost e | n, and sustainability is becoming an important concern for network providers. In | |||
mbedded as part of the device itself. Extending the lifetime of equipment may in | some cases, such as in the context of networked data centers, the ability to pr | |||
many cases be preferable over replacing it earlier with equipment that is sligh | ocure enough energy becomes a bottleneck, prohibiting further growth, and greate | |||
tly more energy-efficient but that requires the embedded carbon cost to be amort | r sustainability thus becomes a business necessity. | |||
ized over a much shorter period of time. | ||||
</t> | </t> | |||
<t>Management has an outsized role to play in approaching those problems. To red | <t> | |||
uce the amount of energy used, network providers need to maximize ways in which | For example, in its annual report, Telefónica reports that in 2021, its network' | |||
they make use of scarce resources and eliminate use of resources which are not n | s energy consumption per petabyte (PB) of data amounted to 54 megawatt-hours (MW | |||
eeded. They need to optimize the way in which networks are deployed, which resou | h) <xref target="Telefonica2021"/>. This rate has been dramatically decreasing ( | |||
rces are placed where, how equipment lifecycles and upgrades are being managed - | by a factor of seven over six years), although gains in efficiency are being off | |||
all of which constitute classic operational problems. As best practices, method | set by simultaneous growth in data volume. The same report states that an import | |||
s, and algorithms are developed, they need to be automated to the greatest exten | ant corporate goal is continuing on that trajectory and aggressively reducing ov | |||
t possible and migrated over time into the network and performed on increasingly | erall carbon emissions further. | |||
short time scales, transcending management and control planes. | ||||
</t> | </t> | |||
</section> | </section> | |||
<section title="Structuring the Problem Space"> | <section> | |||
<t> | <name>Approaching the Problem</name> | |||
From a technical perspective, multiple vectors along which networks can be made | ||||
"greener" should be considered: | ||||
<list style="symbols"> | ||||
<t> | ||||
Equipment level:<br /><br />Perhaps the most promising vector for improving netw | ||||
orking sustainability concerns the network equipment itself. | ||||
At the most fundamental level, networks (even softwarized ones) involve applianc | ||||
es, i.e., equipment that relies on electrical power to perform its function. The | ||||
re are two distinct layers with different opportunities for improvement: | ||||
<list style="symbols"> | <!-- [rfced] For clarity, may we update this sentence as follows? | |||
<t>Hardware: Reducing embedded carbon during material extraction and manufac | ||||
turing, improving energy efficiency and reducing energy consumption during oper | ||||
ations, and reuse, repurpose, and recycle motions.</t> | ||||
<t>Software: Improving software energy efficiency, maximizing utilization of | ||||
processing devices, allowing for software to interact with hardware to improve | ||||
sustainability.</t> | ||||
</list> | ||||
Beyond making network appliances merely more energy-efficient, there are other i | Original: | |||
mportant ways in which equipment can help networks become greener. This include | An often-considered gain in networking sustainability can be made | |||
s aspects such as support for port power saving modes or down-speeding of links | with regards to improving the efficiency with which networks utilize | |||
to reduce power consumption for resources that are not fully utilized. To fully | power during their use phase, reducing the amount of energy that is | |||
tap into the potential of such features requires accompanying management functi | required to provide communication services. | |||
onality, for example to determine when it is "safe" to down-speed a link or ente | ||||
r a power saving mode, and manage the network in such a way that conditions to d | ||||
o so are maximized. | ||||
<br /><br /> | Perhaps: | |||
Most importantly from a management perspective, improving sustainability at the | Reducing the amount of energy that is required to provide | |||
equipment level involves providing management instrumentation that allows to pre | communication services and improving the efficiency with which | |||
cisely monitor and manage power usage and doing so at different levels of granul | networks utilize power during that use phase are both often | |||
arity, for example accounting separately for the contributions of CPU, memory, a | considered gains in networking sustainability. | |||
nd different ports. This enables (for example) controller applications to optimi | ||||
ze energy usage across the network and that leverage control loops to assess the | ||||
effectiveness (e.g. in terms of reduction in power use) of measures that are ta | ||||
ken. | ||||
<br /><br /> | Or: | |||
As a side note, the terms "device" and "equipment", as used in the context of th | As often discussed, networking sustainability can be improved | |||
is draft, are used to refer to networking equipment. We are not taking into con | by increasing the efficiency with which networks utilize | |||
sideration end-user devices and endpoints such as mobile phones or computing equ | power during their use phase, reducing the amount of energy that | |||
ipment. | is required to provide communication services. | |||
--> | ||||
<t> | ||||
An often-considered gain in networking sustainability can be made with regards t | ||||
o improving the efficiency with which networks utilize power during their use ph | ||||
ase, reducing the amount of energy that is required to provide communication ser | ||||
vices. However, for a holistic approach, other aspects need to be considered as | ||||
well. | ||||
</t> | </t> | |||
<t> | <t>The environmental footprint is not determined by energy consumption a | |||
Protocol level:<br /><br />Energy-efficiency and greenness are aspects that are | lone. The sustainability of power sources needs to be considered as well. A de | |||
rarely considered when designing network protocols. This suggests that there ma | ployment that includes devices that are less energy efficient but powered by a s | |||
y be plenty of untapped potential. | ustainable energy source can arguably be considered "greener" than a deployment | |||
Some aspects involve designing protocols in ways that reduce the need for redund | that includes highly efficient devices that are powered by diesel generators. I | |||
ant or wasteful transmission of data to allow not only for better network utiliz | n fact, in the same Telefónica report mentioned earlier, extensive reliance on r | |||
ation, but greater goodput per unit of energy being consumed. Techniques might | enewable energy sources is emphasized. | |||
include approaches that reduce the "header tax" incurred by payloads as well as | ||||
methods resulting in the reduction of wasteful retransmissions. Similarly, ther | ||||
e may be cases where chattiness of protocols may be preventing equipment from go | ||||
ing into sleep mode. Designing protocols that reduce chattiness in such scenari | ||||
os, for example, that reduce dependence on periodic updates or heartbeats, may r | ||||
esult in greener outcomes. Likewise, aspects such as restructuring addresses in | ||||
ways that allow to minimize the size of lookup tables and associated memory size | ||||
s and hence energy use can play a role as well. <br /><br /> | ||||
Another role of protocols concerns the enabling of management functionality to i | ||||
mprove energy efficiency at the network level, such as discovery protocols that | ||||
allow for quick adaptation to network components being taken dynamically into an | ||||
d out of service depending on network conditions, as well as protocols that can | ||||
assist with functions such as the collection of energy telemetry data from the n | ||||
etwork. | ||||
</t> | </t> | |||
<t> | ||||
Network level<br /><br />Perhaps the greatest opportunities to realize power sav | <!--[rfced] In general, please review how the terms "green", "greener", | |||
ings exist at the level of the network as whole. Many of these opportunities are | etc., are used in this document and let us know if any updates are | |||
directly related to management functionality. For example, optimizing energy ef | needed. Specifically: | |||
ficiency may involve directing traffic in such a way that it allows for isolatio | ||||
n of equipment that might not be needed at certain moments so that it can be pow | a) Inconsistent usage of quotation marks in the original | |||
ered down or brought into power-saving mode. By the same token, traffic should b | ||||
e directed in a way that requires bringing additional equipment online or out of | "green" 3 instances vs. 5 without quotes | |||
power-saving mode in cases where alternative traffic paths are available for wh | "greener" 7 instances vs. 18 without quotes | |||
ich the incremental energy cost would amount to zero. Likewise, some networking | "greenness" 1 instance vs. 1 without quotes | |||
devices may be rated less "green" and more power-intensive than others or power | ||||
ed by less-sustainable energy sources. Their use might be avoided unless during | We note that "greener" is in quotes in the abstract, then used frequently | |||
periods of peak capacity demands. Generally, incremental carbon emissions can | in the body of the document without quotes. Is there a rationale | |||
be viewed as a cost metric that networks should strive to minimize and consider | for when it is with vs. without quotes? | |||
as part of routing and of network path optimization. | ||||
b) Section 3: "greener" seems redundant with the surrounding text, | ||||
in light of the definition of "green" provided in Section 1.1. | ||||
May it be removed? | ||||
Original: | ||||
for greener, more sustainable, less carbon-intensive networks. | ||||
Perhaps simply: | ||||
for more sustainable, less carbon-intensive networks. | ||||
c) Section 6.2: Will it be clear to the reader what "green billing and | ||||
charging schemes" means? | ||||
--> | ||||
<t>Similarly, deployments can take other environmental factors into acco | ||||
unt that affect the carbon footprint. For example, deployments where the need f | ||||
or cooling is reduced or where excessive heat generated by equipment can be put | ||||
to a productive use will be considered greener than deployments where this is no | ||||
t the case. Examples include deployments in cooler natural surroundings (e.g., i | ||||
n colder climates) where that is an option. Likewise, manufacturing and recycli | ||||
ng networking equipment are also part of the sustainability equation, as the pro | ||||
duction itself consumes energy and results in a carbon cost embedded as part of | ||||
the device itself. Extending the lifetime of equipment may in many cases be pref | ||||
erable over replacing it earlier with equipment that is slightly more energy eff | ||||
icient, but that requires the embedded carbon cost to be amortized over a much s | ||||
horter period of time. | ||||
</t> | </t> | |||
<t> | <!--[rfced] Does "Management" refer to "network management" in the first | |||
Architecture level<br /><br />The current network architecture supports a wide r | sentence of this paragraph? If so, we suggest updating it for clarity. | |||
ange of applications, but does not consider energy efficiency as one of its desi | ||||
gn parameters. One can argue that the most energy efficient shift of the last tw | Original: | |||
o decades has been the deployment of Content Delivery Network overlays: while th | Management has an outsized role to play in approaching those | |||
ese were set up to reduce latency and minimize bandwidth consumption, from a net | problems. | |||
work perspective, retrieving the content from a local cache is also much greener | ||||
. What other architectural shifts can produce energy consumption reduction? | Perhaps: | |||
Network management has an outsized role to play in approaching | ||||
those problems. | ||||
--> | ||||
<!--[rfced] For readability and to avoid the odd phrasing "maximize ways | ||||
in which they eliminate the use of", we suggest rephrasing as follows. | ||||
Original: | ||||
To reduce the amount of energy used, network providers | ||||
need to maximize ways in which they make use of scarce resources and | ||||
eliminate use of resources which are not needed. | ||||
Perhaps: | ||||
To reduce the amount of energy used, network providers | ||||
need to eliminate the use of unneeded resources | ||||
and maximize the use of scarce resources. | ||||
--> | ||||
<t>Management has an outsized role to play in approaching those problems | ||||
. To reduce the amount of energy used, network providers need to maximize ways i | ||||
n which they use scarce resources and eliminate the use of unneeded resources. T | ||||
hey need to optimize the way in which networks are deployed, which resources are | ||||
placed where, and how equipment lifecycles and upgrades are being managed -- al | ||||
l of which constitute classic operational problems. As best practices, methods, | ||||
and algorithms are developed, they need to be automated to the greatest extent p | ||||
ossible, migrated over time into the network, and performed on increasingly shor | ||||
t timescales, transcending management and control planes. | ||||
</t> | </t> | |||
</list> | </section> | |||
<section> | ||||
<name>Structuring the Problem Space</name> | ||||
<t> | ||||
From a technical perspective, multiple vectors along which networks can be made | ||||
"greener" should be considered: | ||||
</t> | </t> | |||
<t> | <ul spacing="normal"> | |||
In this document, we will explore each of those vectors in further detail and at | <li> | |||
tempt to articulate specific challenges that could make a difference when addres | <t>Equipment level:</t> | |||
sed. As our starting point, we borrow some material from a prior paper, <xref t | <t>Perhaps the most promising vector for improving networking | |||
arget="GreenNet22"/>. For this document, this material has been both expanded (f | sustainability concerns the network equipment itself. At the most | |||
or example, in terms of some of the opportunities) and pruned (for example, in t | fundamental level, networks (even softwarized ones) involve | |||
erms of background on prior scholarly work). | appliances, i.e., equipment that relies on electrical power to | |||
perform its function. There are two distinct layers with different | ||||
opportunities for improvement:</t> | ||||
<ul spacing="normal"> | ||||
<!--[rfced] Please clarify "motions" in this text. | ||||
Does it refer to mechanisms, processes, or something else? | ||||
Original: | ||||
- Hardware: Reducing embedded carbon during material extraction | ||||
and manufacturing, improving energy efficiency and reducing | ||||
energy consumption during operations, and reuse, repurpose, and | ||||
recycle motions. | ||||
Perhaps: | ||||
- Hardware: Reducing embedded carbon during material extraction | ||||
and manufacturing; improving energy efficiency and reducing | ||||
energy consumption during operations; and improving mechanisms | ||||
for reusing, repurposing, and recycling hardware. | ||||
--> | ||||
<li> | ||||
<t>Hardware: Reducing embedded carbon during material | ||||
extraction and manufacturing, improving energy efficiency, and | ||||
reducing energy consumption during operations, and reuse, | ||||
repurpose, and recycle motions.</t> | ||||
</li> | ||||
<li> | ||||
<t>Software: Improving software energy efficiency, maximizing | ||||
utilization of processing devices, and allowing for software to | ||||
interact with hardware to improve sustainability.</t> | ||||
</li> | ||||
</ul> | ||||
<t>Beyond making network appliances merely more energy efficient, | ||||
there are other important ways in which equipment can help | ||||
networks become greener. This includes aspects such as supporting | ||||
port power-saving modes or down-speeding links to reduce | ||||
power consumption for resources that are not fully utilized. To | ||||
fully tap into the potential of such features, it requires | ||||
accompanying management functionality, for example, to determine | ||||
when it is "safe" to down-speed a link or to enter a power-saving | ||||
mode, and to maximize the conditions when that action is appropriate | ||||
. | ||||
</t> | ||||
<!--[rfced] FYI, this has been rephrased for clarity. Specifically, | ||||
this removes the redundancy of "management functionality" and | ||||
"manage the network". | ||||
Original: | ||||
To fully tap into the potential of such features requires | ||||
accompanying management functionality, for example to determine | ||||
when it is "safe" to down-speed a link or enter a power saving | ||||
mode, and manage the network in such a way that conditions to do | ||||
so are maximized. | ||||
Current: | ||||
To tap into the potential of such features, it requires accompanying | ||||
management functionality, for example, to determine when it is | ||||
"safe" to down-speed a link or to enter a power-saving mode, and | ||||
to maximize the conditions when that action is appropriate. | ||||
--> | ||||
<t>Most importantly, from a management perspective, improving | ||||
sustainability at the equipment level involves providing | ||||
management instrumentation that allows for precise monitoring and | ||||
managing power usage and doing so at different levels of | ||||
granularity, for example, accounting separately for the | ||||
contributions of CPU, memory, and different ports. This enables | ||||
(for example) controller applications to optimize energy usage | ||||
across the network and to leverage control loops to assess the | ||||
effectiveness (e.g., in terms of reducing power use) of | ||||
the measures that are taken.</t> | ||||
<t>As a side note, the terms "device" and "equipment", as used in | ||||
the context of this document, are used to refer to networking | ||||
equipment. We are not taking into consideration end-user devices | ||||
and endpoints such as mobile phones or computing equipment.</t> | ||||
</li> | ||||
<li> | ||||
<t>Protocol level:</t> | ||||
<t>Energy-efficiency and greenness are aspects that are rarely | ||||
considered when designing network protocols. This suggests that | ||||
there may be plenty of untapped potential. Some aspects involve | ||||
designing protocols in ways that reduce the need for redundant or | ||||
wasteful transmission of data, allowing not only for better network | ||||
utilization but for greater goodput per unit of energy being | ||||
consumed. Techniques might include approaches that reduce the | ||||
"header tax" incurred by payloads as well as methods resulting in | ||||
the reduction of wasteful retransmissions. Similarly, there may | ||||
be cases where chattiness of protocols may be preventing equipment | ||||
from going into sleep mode. Designing protocols that reduce | ||||
chattiness in such scenarios, for example, that reduce dependence | ||||
on periodic updates or heartbeats, may result in greener | ||||
outcomes. Likewise, aspects such as restructuring addresses in | ||||
ways that minimize the size of lookup tables, | ||||
associated memory sizes, and hence energy use, can play a role as | ||||
well.</t> | ||||
<t>Another role of protocols concerns the enabling | ||||
of management functionality to improve energy efficiency at the | ||||
network level, such as discovery protocols that allow for quick | ||||
adaptation to network components being taken dynamically into and | ||||
out of service depending on network conditions, as well as | ||||
protocols that can assist with functions such as the collection of | ||||
energy telemetry data from the network.</t> | ||||
</li> | ||||
<li> | ||||
<t>Network level:</t> | ||||
<!--[rfced] Please review the intended meaning of this sentence. | ||||
Instead of "and", should it be "because"? | ||||
Also, would 'rated less "green"' be more clear with a rephrase? | ||||
Original: | ||||
Likewise, some networking devices may be | ||||
rated less "green" and more power-intensive than others or | ||||
powered by less-sustainable energy sources. | ||||
Perhaps: | ||||
Likewise, some networking devices may be | ||||
given a lower sustainability rating because they are | ||||
more power-intensive or are using less-sustainable energy sources. | ||||
--> | ||||
<t>Perhaps the greatest opportunities to realize power savings | ||||
exist at the level of the network as whole. Many of these | ||||
opportunities are directly related to management | ||||
functionality. For example, optimizing energy efficiency may | ||||
involve directing traffic in such a way that it allows the | ||||
isolation of equipment that might not be needed at certain moments | ||||
so that it can be powered down or brought into power-saving | ||||
mode. By the same token, traffic should be directed in a way that | ||||
requires bringing additional equipment online or out of | ||||
power-saving mode in cases where alternative traffic paths are | ||||
available for which the incremental energy cost would amount to | ||||
zero. Likewise, some networking devices may be rated less "green" | ||||
and more power-intensive than others or may be powered by | ||||
less-sustainable energy sources. Their use might be avoided | ||||
except during periods of peak capacity demands. Generally, | ||||
incremental carbon emissions can be viewed as a cost metric that | ||||
networks should strive to minimize and consider as part of routing | ||||
and network path optimization.</t> | ||||
</li> | ||||
<li> | ||||
<t>Architecture level:</t> | ||||
<t>The current network architecture supports a wide range of | ||||
applications but does not consider energy efficiency as one of | ||||
its design parameters. One can argue that the most energy | ||||
efficient shift of the last two decades has been the deployment of | ||||
Content Delivery Network overlays: while these were set up to | ||||
reduce latency and minimize bandwidth consumption, from a network | ||||
perspective, retrieving the content from a local cache is also | ||||
much greener. What other architectural shifts can produce energy | ||||
consumption reduction?</t> | ||||
</li> | ||||
</ul> | ||||
<t>In this document, we will explore each of those vectors in further de | ||||
tail and attempt to articulate specific challenges that could make a difference | ||||
when addressed. As our starting point, we borrow some material from "Challenges | ||||
and Opportunities in Green Networking" <xref target="GreenNet22"/>. For this do | ||||
cument, this material has been both expanded (for example, in terms of some of t | ||||
he opportunities) and pruned (for example, in terms of background on prior schol | ||||
arly work). | ||||
</t> | </t> | |||
<t> | <t> | |||
This document is a product of the Network Management Research Group (NMRG) of th e Internet Research Task Force (IRTF). This document reflects the consensus of the research group and was discussed and presented multiple times, each time rec eiving positive feedback and no objections. It is not a candidate for any level of Internet Standard and is published for informational purposes. | This document is a product of the Network Management Research Group (NMRG) of th e Internet Research Task Force (IRTF). This document reflects the consensus of the research group and was discussed and presented multiple times, each time rec eiving positive feedback and no objections. It is not a candidate for any level of Internet Standard and is published for informational purposes. | |||
</t> | </t> | |||
</section> | ||||
</section> | ||||
<section> | ||||
<name>Definitions and Acronyms</name> | ||||
<t>Below you find acronyms used in this document: </t> | ||||
<dl newline="false" spacing="normal"> | ||||
<dt>Carbon Footprint:</dt> | ||||
<dd>As used in this document, the amount of carbon emissions | ||||
associated with the use or deployment of technology, usually | ||||
correlated with the amount of energy consumption</dd> | ||||
<dt>CDN:</dt> | ||||
<dd>Content Delivery Network</dd> | ||||
<dt>CPU:</dt> | ||||
<dd>Central Processing Unit (that is, the main processor in a server)</d | ||||
d> | ||||
<dt>DC:</dt> | ||||
<dd>Data Center</dd> | ||||
<dt>FCT:</dt> | ||||
<dd>Flow Completion Time</dd> | ||||
<dt>GHG:</dt> | ||||
<dd>Greenhouse Gas</dd> | ||||
<dt>GPU:</dt> | ||||
<dd>Graphical Processing Unit</dd> | ||||
<dt>HVAC:</dt> | ||||
<dd>Heating, Ventilation, Air Conditioning</dd> | ||||
<dt>ICN:</dt> | ||||
<dd>Information-Centric Network</dd> | ||||
<dt>IGP:</dt> | ||||
<dd>Interior Gateway Protocol</dd> | ||||
<dt>IoT:</dt> | ||||
<dd>Internet of Things</dd> | ||||
</section> | <dt>IPU:</dt> | |||
</section> | <dd>Infrastructure Processing Unit</dd> | |||
<dt>LEED:</dt> | ||||
<dd>Leadership in Energy and Environmental Design (a green building rati | ||||
ng system)</dd> | ||||
<dt>LEO:</dt> | ||||
<dd>Low Earth Orbit</dd> | ||||
<dt>LPM:</dt> | ||||
<dd>Longest Prefix Match (a method to look up prefixes in a forwarding e | ||||
lement)</dd> | ||||
<dt>MPLS:</dt> | ||||
<dd>Multiprotocol Label Switching</dd> | ||||
<dt>MTU:</dt> | ||||
<dd>Maximum Transmission Unit (the largest packet size that can be trans | ||||
mitted over a network)</dd> | ||||
<dt>NIC:</dt> | ||||
<dd>Network Interface Card</dd> | ||||
<dt>QoE:</dt> | ||||
<dd>Quality of Experience</dd> | ||||
<dt>QoS:</dt> | ||||
<dd>Quality of Service</dd> | ||||
<!--[rfced] Regarding "Definitions and Acronyms": | ||||
<section title="Definitions and Acronyms"> | a) Does "IPU" refer to Intel's IPU specifically? | |||
If so, we suggest updating the definition or the usage within the | ||||
document (one instance). Searches for this term outside the | ||||
RFC series (e.g., on dl.acm.org, ieeexplore.ieee.org) give | ||||
results such as "Intel's IPU". | ||||
<t> | Current: | |||
Below you find acronyms used in this draft: | IPU: Infrastructure Processing Unit | |||
<list style="hanging" hangIndent='7'> | ||||
<t hangText="Carbon Footprint:"><br />As used in this document, the amount of ca | b) Regarding the expansion of "QUIC". We were told by the | |||
rbon emissions associated with the use or deployment of technology, usually corr | QUIC WG of the IETF that it is not an acronym. May this entry be | |||
elated with the amount of energy consumption</t> | updated as follows or otherwise? Also, would you like to add | |||
<t hangText="CDN:">Content Delivery Network</t> | RFC 9000 as an informative reference? | |||
<t hangText="CPU:">Central Processing Unit, that is the main processor in a serv | ||||
er</t> | ||||
<t hangText="DC:">Data Center</t> | ||||
<t hangText="FCT:">Flow Completion Time</t> | ||||
<t hangText="GHG:">Greenhouse Gas</t> | ||||
<t hangText="GPU:">Graphical Processing Unit</t> | ||||
<t hangText="HVAC:">Heating, Ventilation, Air Conditioning</t> | ||||
<t hangText="ICN:">Information Centric Network</t> | ||||
<t hangText="IGP:">Interior Gateway Protocol</t> | ||||
<t hangText="IoT:">Internet of Things</t> | ||||
<t hangText="IPU:">Infrastructure Processing Units</t> | ||||
<t hangText="LEED:">Leadership in Energy and Environmental Design, a green build | ||||
ing rating system</t> | ||||
<t hangText="LEO:">Low Earth Orbit</t> | ||||
<t hangText="LPM:">Longest Prefix Match, a method to look up prefixes in a forwa | ||||
rding element</t> | ||||
<t hangText="MPLS:">Multi-Path Label Switchin</t> | ||||
<t hangText="MTU:">Maximum Transmission Unit, the largest packet size that can b | ||||
e transmitted over a network</t> | ||||
<t hangText="NIC:">Network Interface Card</t> | ||||
<t hangText="QoE:">Quality of Experience</t> | ||||
<t hangText="QoS:">Quality of Service</t> | ||||
<t hangText="QUIC:">Quick UDP Internet Connections</t> | ||||
<t hangText="SNIC:">Smart NIC</t> | ||||
<t hangText="SDN:">Software-Defined Networking</t> | ||||
<t hangText="TCP:">Transport Control Protocol</t> | ||||
<t hangText="TE:">Traffic Engineering</t> | ||||
<t hangText="TPU:">Tensor Processing Unit</t> | ||||
<t hangText="WAN:">Wide Area Network</t> | ||||
</list> | Original: | |||
</t> | QUIC: Quick UDP Internet Connections | |||
</section> | ||||
<!-- | Perhaps: | |||
QUIC: the name of a UDP-based, stream-multiplexing, encrypted | ||||
transport protocol. | ||||
c) FYI, we removed SNIC from this list because it is not | ||||
used within this document. There is one instance of "SmartNICs" | ||||
that remains in the document. | ||||
Original: | ||||
SNIC: Smart NIC | ||||
--> | ||||
<dt>QUIC:</dt> | ||||
<dd>Quick UDP Internet Connections</dd> | ||||
<dt>SDN:</dt> | ||||
<dd>Software-Defined Networking</dd> | ||||
<dt>TCP:</dt> | ||||
<dd>Transport Control Protocol</dd> | ||||
<dt>TE:</dt> | ||||
<dd>Traffic Engineering</dd> | ||||
<dt>TPU:</dt> | ||||
<dd>Tensor Processing Unit</dd> | ||||
<dt>WAN:</dt> | ||||
<dd>Wide Area Network</dd> | ||||
</dl> | ||||
</section> | ||||
<!-- | ||||
<section title="The Dynamics of Combining Sustainability and Network Management" > | <section title="The Dynamics of Combining Sustainability and Network Management" > | |||
<t> | <t> | |||
As it was mentioned and will be further explored in detail, improving energy efficiency is a key way to improve sustainability. However, this process and re duction is only meaningful within its larger context. | As it was mentioned and will be further explored in detail, improving energy efficiency is a key way to improve sustainability. However, this process and re duction is only meaningful within its larger context. | |||
</t> | </t> | |||
<t> | <t> | |||
There is a duality and dialectic in this interaction. First, in order to pro vide those hardware and software improvements, research and development need to take place, which bring their own carbon footprint. Further, if the improvement is in a much more energy efficient Chip, CPU, GPU, or piece of hardware, deployi ng the next generation of hardware (material acquisition, manufacturing, supply- chain, transportation) and end-of-lifing the older generation creates and added carbon footprint. Consequently, there are values that maximize sustainability at a global basis, which are neither at both ends: it is not about leaving old har dware and software for overextended periods, and it is also not about replacing and rearchitecting weekly. | There is a duality and dialectic in this interaction. First, in order to pro vide those hardware and software improvements, research and development need to take place, which bring their own carbon footprint. Further, if the improvement is in a much more energy efficient Chip, CPU, GPU, or piece of hardware, deployi ng the next generation of hardware (material acquisition, manufacturing, supply- chain, transportation) and end-of-lifing the older generation creates and added carbon footprint. Consequently, there are values that maximize sustainability at a global basis, which are neither at both ends: it is not about leaving old har dware and software for overextended periods, and it is also not about replacing and rearchitecting weekly. | |||
</t> | </t> | |||
<t> | <t> | |||
Similarly, at the protocol and architectural levels there is an equivalent d uality: what is the "sweet-spot" on which protocols can be improved (for them to be less energy-wastful), and when to use protocol interactions (e.g., extension s) to carry sustainability data and information (i.e., sustainability telemetry and metrics) and to execute actions. | Similarly, at the protocol and architectural levels there is an equivalent d uality: what is the "sweet-spot" on which protocols can be improved (for them to be less energy-wastful), and when to use protocol interactions (e.g., extension s) to carry sustainability data and information (i.e., sustainability telemetry and metrics) and to execute actions. | |||
</t> | </t> | |||
<t> | <t> | |||
Finally, there needs to be given consideration to Jevons paradox, particular ly as the energy efficiency optimization (in hardware as well as in software) ca n bring important operational savings in cost. | Finally, there needs to be given consideration to Jevons paradox, particular ly as the energy efficiency optimization (in hardware as well as in software) ca n bring important operational savings in cost. | |||
</t> | </t> | |||
</section> | </section> | |||
--> | --> | |||
<section title="Network Energy Consumption Characteristics and Implications" anc | <section anchor="sec_implications"> | |||
hor="sec:implications"> | <name>Network Energy Consumption Characteristics and Implications</name> | |||
<t> | <t> | |||
Carbon footprint and, with it, greenhouse gas emissions are determined by severa | The carbon footprint and, with it, greenhouse gas emissions are determined by se | |||
l factors. A main factor is network energy consumption, as the energy consumed c | veral factors. A main factor is network energy consumption, as the energy consum | |||
an be considered a proxy for the burning of fuels required for corresponding pow | ed can be considered a proxy for the burning of fuels required for corresponding | |||
er generation. Network energy consumption by itself does not tell the whole sto | power generation. Network energy consumption by itself does not tell the whole | |||
ry, as it does not take the sustainability of energy sources and energy mix into | story, as it does not take the sustainability of energy sources and the energy | |||
account. Likewise, there are other factors such as hidden carbon cost reflecti | mix into account. Likewise, there are other factors such as the carbon cost exp | |||
ng the carbon footprint expended in manufacturing of networking hardware. Nonet | ended in the manufacturing of networking hardware. Nonetheless, network energy | |||
heless, network energy consumption is an excellent predictor for carbon footprin | consumption is an excellent predictor of a carbon footprint and its reduction, w | |||
t and its reduction key to sustainable solutions. Exploring possibilities to im | hich is key to sustainable solutions. Hence, exploring possibilities to improve | |||
prove energy efficiency is hence a key factor for greener, more sustainable, les | energy efficiency is a key factor for greener, more sustainable, less carbon-in | |||
s carbon-intensive networks. | tensive networks. | |||
</t> | </t> | |||
<t>For this, it is important to understand some of the characteristics of power consumption by networks and which aspects contribute the most. This helps to id entify where the greatest potential not just for power savings but also for sust ainability improvements lies. | <t>It is important to understand some of the characteristics of power cons umption by networks and which aspects contribute the most. This helps to identi fy where the greatest potential is, not just for power savings but also for sust ainability improvements. | |||
</t> | </t> | |||
<t> | <t> | |||
Power is ultimately drawn by devices. Devices are not monoliths but are compose | Power is ultimately drawn by devices. Devices are not monoliths but are compose | |||
d of multiple components. The power consumption of the device can be divided int | d of multiple components. The power consumption of the device can be divided int | |||
o the consumption of the core device - the backplane and CPU, if you will - as w | o the consumption of the core device -- the backplane and CPU, if you will -- as | |||
ell as additional consumption incurred per port and line card. In addition, GP | well as additional consumption incurred per port and line card. In addition, | |||
U and TPU may be used as well in the network and may have different power consum | the GPU and TPU may be used in the network and may have different power consumpt | |||
ption profiles. | ion profiles. | |||
Furthermore, it is important to understand the difference between power consumpt ion when a resource is idling versus when it is under load. This helps to unders tand the incremental cost of additional transmission versus the initial cost of transmission. | Furthermore, it is important to understand the difference between power consumpt ion when a resource is idling versus when it is under load. This helps to unders tand the incremental cost of additional transmission versus the initial cost of transmission. | |||
</t> | </t> | |||
<t> | <t> | |||
In typical networking devices, only roughly half of the energy consumption is as sociated with the data plane <xref target="Bolla2011energy"/>. | In typical networking devices, only roughly half of the energy consumption is as sociated with the data plane <xref target="Bolla2011energy"/>. | |||
An idle base system typically consumes more than half of the energy over the sam e system running at full load <xref target="Chabarek08"/>, <xref target="Cervero 19"/>. | An idle base system typically consumes more than half of the energy that the sam e system would consume when running at full load <xref target="Chabarek08"/> <xr ef target="Cervero15"/>. | |||
Generally, the cost of sending the first bit is very high, as it requires poweri ng up a device, port, etc. | Generally, the cost of sending the first bit is very high, as it requires poweri ng up a device, port, etc. | |||
The incremental energy cost of transmission of additional bits (beyond the first ) is many orders of magnitude lower. Likewise, the incremental cost of increment al CPU and memory needed to process additional packets becomes fairly negligible . | The incremental energy cost of transmission of additional bits (beyond the first ) is many orders of magnitude lower. Likewise, the incremental cost of the incre mental CPU and memory needed to process additional packets becomes fairly neglig ible. | |||
</t> | </t> | |||
<t> This means that a device's energy consumption does not increase linearly wit h the volume of forwarded traffic. Instead, it resembles more of a step functio n in which energy consumption stays roughly the same up to a certain volume of t raffic, followed by a sudden jump when additional resources need to be procured to support a higher volume of traffic. | <t> This means that a device's energy consumption does not increase linear ly with the volume of forwarded traffic. Instead, it resembles a step function in which energy consumption stays roughly the same up to a certain volume of tra ffic, followed by a sudden jump when additional resources need to be procured to support a higher volume of traffic. | |||
</t> | </t> | |||
<t> | <t> | |||
By the same token, it is generally more energy-efficient to transmit a large vol | By the same token, it is generally more energy efficient to transmit a large vol | |||
ume of data in one burst (and subsequently turning off or down-speeding the inte | ume of data in one burst (and subsequently turn off or down-speed the interface | |||
rface when idling) than to continuously transmit at a lower rate. In that sense | when idling) than to continuously transmit at a lower rate. In that sense, it ca | |||
it can be the duration of the transmission that dominates the energy consumption | n be the duration of the transmission that dominates the energy consumption -- n | |||
, not the actual data rate. | ot the actual data rate. | |||
</t> | </t> | |||
<t> | <t> | |||
The implications on green networking from an energy-savings standpoint are signi ficant. | The implications on green networking from an energy-savings standpoint are signi ficant. | |||
Of utmost importance are schemes that allow for "peak shaving": networks are typ ically dimensioned for periods of peak demand and usage, yet any excess capacity during periods of non-peak usage does not result in corresponding energy saving s. Peak shaving techniques that allow to reduce peak traffic spikes and thus wa ste during non-peak periods may result in outsize sustainability gains. Peak sh aving could be accomplished by techniques such as spreading spikes out over geog raphies (e.g. routing traffic across more costly but less utilized routes) or ov er time (e.g. postponing and buffering non-urgent traffic). | Of utmost importance are schemes that allow for "peak shaving": networks are typ ically dimensioned for periods of peak demand and usage, yet any excess capacity during periods of non-peak usage does not result in corresponding energy saving s. Peak shaving techniques that reduce peak traffic spikes and waste during non -peak periods may result in outsize sustainability gains. Peak shaving could be accomplished by techniques such as spreading spikes out over geographies (e.g., routing traffic across more costly but less utilized routes) or over time (e.g. , postponing and buffering non-urgent traffic). | |||
</t> | </t> | |||
<t>Likewise, large gains can be made whenever network resources can effectively be taken offline for at least some of the time, managing networks in a way that enables resources to be removed from service so they can be powered down (or put into a more energy-saving state, such as when down-speeding ports) while not ne eded. Of course, any such methods need to take into account the overhead of tak ing resources offline and bringing them back online. This typically takes some amount of time, requiring accurate predictive capabilities to avoid situations i n which network resources are not available at times when they would be needed. In addition, there is additional overhead such as synchronization of state to b e accounted for. | <t>Likewise, large gains can be made whenever network resources can effect ively be taken offline for at least some of the time, managing networks in a way that enables resources to be removed from service so they can be powered down ( or put into a more energy-saving state, such as when down-speeding ports) while not needed. Of course, any such methods need to take into account the overhead of taking resources offline and bringing them back online. This typically takes some amount of time, requiring accurate predictive capabilities to avoid situat ions in which network resources are not available at times when they would be ne eded. In addition, there is additional overhead, such as synchronization of sta te, to be accounted for. | |||
</t> | </t> | |||
<t> | <t> | |||
At the same time, any non-idle resources should be utilized to the greatest exte | At the same time, any non-idle resources should be utilized to the greatest exte | |||
nt possible as the incremental energy cost is negligible. Of course, this needs | nt possible, as the incremental energy cost is negligible. Of course, this needs | |||
to occur while still taking other operational goals into consideration, such as | to occur while still taking other operational goals into consideration, such as | |||
protection against failures (allowing for readily available redundancy and spare | protection against failures (allowing for readily available redundancy and spar | |||
capacity in case of failure) and load balancing (for increased operational robu | e capacity in case of failure) and load balancing (for increased operational rob | |||
stness). | ustness). | |||
As data transmission needs tend to fluctuate wildly and occur in bursts, any opt | As data transmission needs tend to fluctuate wildly and occur in bursts, any opt | |||
imization schemes need to be highly adaptable and allow for control loops at ver | imization schemes need to be highly adaptable and allow control loops at very fa | |||
y fast time scales. | st time scales. | |||
</t> | </t> | |||
<t> | <t> | |||
Similarly, for applications where this is possible, it may be desirable to repla | Similarly, for applications where this is possible, it may be desirable to repla | |||
ce continuous traffic at low data rates with traffic that is sent in burst at hi | ce continuous traffic at low data rates with traffic that is sent in bursts at h | |||
gh data rates in order to potentially maximize the time during which resources c | igh data rates in order to potentially maximize the time during which resources | |||
an be idled. | can be idled. | |||
</t> | </t> | |||
<!--[rfced] For readability, may this sentence be rephrased as follows? | ||||
Specifically, we suggest rephrasing "emphasis needs to be given to technology" | ||||
and making the sentence into shorter ones. | ||||
<t> | Original: | |||
As a result, emphasis needs to be given to technology that allows for example to | As a result, emphasis needs to be given to technology that allows for | |||
(at the device level) exercise very efficient and rapid discovery, monitoring, | example to (at the device level) exercise very efficient and rapid | |||
and control of networking resources so that they can be dynamically be taken off | discovery, monitoring, and control of networking resources so that | |||
line or back into service, without (at the network level) requiring extensive co | they can be dynamically be taken offline or back into service, | |||
nvergence of state across the network or recalculation of routes and other optim | without (at the network level) requiring extensive convergence of | |||
ization problems, and (at the network equipment level) support rapid power cycle | state across the network or recalculation of routes and other | |||
and initialization schemes. There may be some lessons that can be applied here | optimization problems, and (at the network equipment level) support | |||
from IoT, | rapid power cycle and initialization schemes. | |||
which has long had to contend with power-constrained end devices that need to sp | ||||
end much of their time in power saving states to conserve battery. | ||||
</t> | ||||
</section> | ||||
<section title="Challenges and Opportunities - Equipment Level" anchor="sec:devi | Perhaps: | |||
ce"> | As a result, we should prioritize technology that efficiently | |||
discovers, monitors, and controls networking resources at the device | ||||
level. This allows devices to be dynamically taken offline or brought | ||||
back online without extensive network-level state convergence, route | ||||
recalculation, or other complex optimizations. At the network equipment | ||||
level, it should also support rapid power cycling and initialization. | ||||
Or: | ||||
Technology that has the following characteristics should be prioritized: | ||||
* At the device level, it does efficient and rapid discovery, monitoring, | ||||
and control of networking resources so they can be dynamically taken | ||||
offline or online. | ||||
* At the network level, it does not require extensive convergence of | ||||
state across the network or recalculation of routes and other | ||||
optimization problems. | ||||
* At the network equipment level, it supports rapid power cycle and | ||||
initialization schemes. | ||||
--> | ||||
<t> | <t> | |||
As a result, emphasis needs to be given to technology that allows, for example, | ||||
(at the device level) very efficient and rapid discovery, monitoring, and contro | ||||
l of networking resources so that they can be dynamically taken offline or broug | ||||
ht back in service without (at the network level) requiring an extensive converg | ||||
ence of state across the network or a recalculation of routes and other optimiza | ||||
tion problems, and (at the network equipment level) support rapid power cycle an | ||||
d initialization schemes. There may be some lessons that can be applied here fr | ||||
om IoT, | ||||
which has long had to contend with power-constrained end devices that need to sp | ||||
end much of their time in power-saving states to conserve battery. | ||||
</t> | ||||
</section> | ||||
<section anchor="sec_device"> | ||||
<name>Challenges and Opportunities - Equipment Level</name> | ||||
<t> | ||||
We are categorizing challenges and opportunities to improve sustainability at th e network equipment level along the following lines: | We are categorizing challenges and opportunities to improve sustainability at th e network equipment level along the following lines: | |||
<list style="symbols"> | ||||
<t>Hardware and manufacturing. Related opportunities are arguably among the most | ||||
obvious and perhaps "largest". However, solutions here lie largely outside the | ||||
scope of networking researchers. </t> | ||||
<t>Visibility and instrumentation. Instrumenting equipment to provide visibility | ||||
into how they consume energy is key to management solutions and control loops t | ||||
o facilitate optimization schemes. </t> | ||||
</list> | ||||
</t> | </t> | |||
<section title="Hardware and Manufacturing"> | <ul spacing="normal"> | |||
<t> | <li> | |||
<t>Hardware and manufacturing: Related opportunities are arguably amon | ||||
g the most obvious and perhaps "largest". However, solutions here lie largely ou | ||||
tside the scope of networking researchers. </t> | ||||
</li> | ||||
<li> | ||||
<t>Visibility and instrumentation: Instrumenting equipment to provide | ||||
visibility into how they consume energy is key to management solutions and contr | ||||
ol loops to facilitate optimization schemes. </t> | ||||
</li> | ||||
</ul> | ||||
<section anchor="sec_hw_and_man"> | ||||
<name>Hardware and Manufacturing</name> | ||||
<t> | ||||
<!--[rfced] Please clarify the phrase "eco-friendly to deploy"; | ||||
could a more precise term than "eco-friendly" be used in this context? | ||||
Perhaps the most obvious opportunities to make networking technology more energy | Original: | |||
efficient exist at the equipment level. After all, networking involves physica | Making such equipment more power efficient, have it dissipate less | |||
l equipment to receive and transmit data. Making such equipment more power effi | heat to consume less energy and reduce the need for cooling, making | |||
cient, have it dissipate less heat to consume less energy and reduce the need fo | it eco-friendly to deploy, sourcing sustainable materials and | |||
r cooling, making it eco-friendly to deploy, sourcing sustainable materials and | facilitating recycling of equipment at the end of its lifecycle all | |||
facilitating recycling of equipment at the end of its lifecycle all contribute t | contribute to making networks greener. | |||
o making networks greener. More specific and unique to networking are schemes t | --> | |||
o reduce energy usage of transmission technology from wireless (antennas) to opt | Perhaps the most obvious opportunities to make networking technology more energy | |||
ical (lasers). | efficient exist at the equipment level. After all, networking involves physica | |||
l equipment to receive and transmit data. Making such equipment more power effi | ||||
cient, having it dissipate less heat to consume less energy and reduce the need | ||||
for cooling, making it eco-friendly to deploy, sourcing sustainable materials, a | ||||
nd facilitating the recycling of equipment at the end of its lifecycle -- all co | ||||
ntribute to making networks greener. | ||||
Reducing the energy usage of transmission technology, from wireless (antennas) t | ||||
o optical (lasers), is a strategy that is unique to networking. | ||||
</t> | </t> | |||
<t>One critical aspect of the energy cost of networking is the cost to manufactu re and deploy the networking equipment. In addition, even the development proces s itself comes with its own carbon footprint. This is outside of the scope of t his document: we only consider the energy cost of running the network that appli es during the operational part of the equipment's lifecycle. However, a holistic approach would include into this the embedded energy that is included in the ne tworking equipment. As part of this, aspects such as the impact of deploying new protocols on the rate of obsolescence of existing equipment should be considere d. For instance, incremental approaches that do not require to replace equipment right away - or even extend the lifetime of deployed equipment - would have a l ower energy footprint. This is one important benefit also of technologies such as Software-Defined Networking and Network Function Virtualization, as they may allow support of new networking features through software updates without requir ing hardware replacements. | <t>One critical aspect of the energy cost of networking is the cost to m anufacture and deploy the networking equipment. In addition, even the developmen t process itself comes with its own carbon footprint. This is outside of the sc ope of this document: we only consider the energy cost of running the network du ring the operational part of the equipment's lifecycle. However, a holistic appr oach would include the embedded energy that is included in the networking equipm ent. As part of this, aspects such as the impact of deploying new protocols on t he rate of obsolescence of existing equipment should be considered. For instance , incremental approaches that do not require replacing equipment right away -- o r even that extend the lifetime of deployed equipment -- would have a lower ener gy footprint. This is one important benefit also of technologies such as Softwa re-Defined Networking and network function virtualization, as they may allow sup port for new networking features through software updates without requiring hard ware replacements. | |||
</t> | </t> | |||
<t>An attempt to compute not only the energy of running a network, but also the energy embedded into manufacturing the equipment is described in <xref target="E mergy"/> . This is denoted by "emergy", a portmanteau for embedded energy. Likew ise, an approach to recycling equipment and a proof of concept using old cell ph ones recycled into a "junkyard" data center are described in <xref target="Junky ard"/>. | <t><xref target="Emergy"/> describes an attempt to compute not only the energy of running a network but also the energy embedded into manufacturing the equipment. This is denoted by "emergy", a portmanteau for embedded energy. Likew ise, <xref target="Junkyard"/> describes an approach to recycling equipment and a proof of concept using old mobile phones recycled into a "junkyard" data cente r. | |||
</t> | </t> | |||
<t>One trade-off to consider at this level is the selection of a platform that c an be hardware-optimized for energy efficiency vs a platform that is versatile a nd can run multiple functions. For instance, a switch could run on an efficient hardware platform, or run as a software module (container) over some multi-purpo se platform. While the first one is operationally more energy efficient, it may have a higher embedded energy from a smaller scale, less efficient production pr ocess, as well as a shorter shelf life once new functions need to be added to th e platform. | <t>One trade-off to consider at this level is the selection of a platfor m that can be hardware-optimized for energy efficiency versus a platform that is versatile and can run multiple functions. For instance, a switch could run on a n efficient hardware platform or run as a software module (container) over some multipurpose platform. While the first one is operationally more energy efficien t, it may have a higher embedded energy from a smaller scale, a less efficient p roduction process, as well as a shorter shelf life once new functions need to be added to the platform. | |||
</t> | </t> | |||
</section> | </section> | |||
<section title="Visibility and Instrumentation" anchor="sec:instrum"> | <section anchor="sec_instrum"> | |||
<t> | <name>Visibility and Instrumentation</name> | |||
Beyond "first-order" opportunities as outlined in the previous subsection, netwo | <t> | |||
rk equipment just as importantly plays an important role to enable and support g | Beyond "first-order" opportunities, as outlined in <xref target="sec_hw_and_man" | |||
reen networking at other levels. Of prime importance is the equipment's ability | />, network equipment just as importantly plays a role in enabling and supportin | |||
to provide visibility to management and control plane into its current energy us | g green networking at other levels. Of prime importance is the equipment's abili | |||
age. Such visibility enables control loops for energy optimization schemes, allo | ty to provide visibility to the management and control planes into its current e | |||
wing applications to obtain feedback regarding the energy implications of their | nergy usage. Such visibility enables control loops for energy optimization schem | |||
actions, from setting up paths across the network that require the least increme | es, allowing applications to obtain feedback regarding the energy implications o | |||
ntal amount of energy to quantifying metrics related to energy cost used to opti | f their actions, from setting up paths across the network that require the least | |||
mize forwarding decisions. Absent an actual measurement of energy usage (and unt | incremental amount of energy to quantifying metrics related to energy cost to o | |||
il such measurement is put in place), the network equipment could advertise some | ptimize forwarding decisions. Absent an actual measurement of energy usage (and | |||
proxy of its power consumption (say, a labelling scheme as silver, gold, platin | until such measurement is put in place), the network equipment could advertise s | |||
um similar to the LEED sustainability metric in building codes or the Energy Sta | ome proxy of its power consumption. For example, it could use a labeling scheme | |||
r label in home appliances; or a description of the type of the device as using | of silver, gold, or platinum similar to the LEED sustainability metric in buildi | |||
CPU vs GPU vs TPU processors with different power profiles). | ng codes, or the Energy Star label in home appliances, or a description of the t | |||
ype of the device as using CPU vs. GPU vs. TPU processors with different power p | ||||
rofiles. | ||||
</t> | </t> | |||
<t> | <t> | |||
One prerequisite to such schemes is to have proper instrumentation in place that | One prerequisite to such schemes is to have proper instrumentation in place that | |||
allows to monitor current power consumption at the level of networking devices | allows for monitoring current power consumption at the level of networking devi | |||
as a whole, line cards, and individual ports. Such instrumentation should also | ces as a whole, line cards, and individual ports. Such instrumentation should a | |||
allow to assess the energy efficiency and carbon footprint of the device as a wh | lso allow for assessing the energy efficiency and carbon footprint of the device | |||
ole. In addition, it will be desirable to relate this power consumption to data | as a whole. In addition, it will be desirable to relate this power consumption | |||
rates as well as to current traffic, for example, to indicate current energy con | to data rates and to current traffic, for example, to indicate current energy co | |||
sumption relative to interface speeds, as well as for incremental energy consump | nsumption relative to interface speeds, as well as for incremental energy consum | |||
tion that is expected for incremental traffic (to aid control schemes that aim t | ption that is expected for incremental traffic (to aid control schemes that aim | |||
o "shave" power off current services or to minimize the incremental use of power | to "shave" power off current services or to minimize the incremental use of powe | |||
for additional traffic). This is an area where the current state of the art is | r for additional traffic). This is an area where the current state of the art i | |||
sorely lacking and standardization lags behind. For example, as of today, stan | s sorely lacking, and standardization lags behind. For example, as of today, st | |||
dardized YANG data models <xref target="RFC7950"/> for network energy consumptio | andardized YANG data models <xref target="RFC7950"/> for network energy consumpt | |||
n that can be used in conjunction with management and control protocols have yet | ion that can be used in conjunction with management and control protocols have y | |||
to be defined. | et to be defined. | |||
</t> | </t> | |||
<t>To remedy this situation, efforts to define sets of green networking metrics <xref target="I.D.draft-cx-green-green-metrics"/> as well as YANG data models th at include objects that provide visibility into power measurements (e.g. <xref t arget="I.D.draft-li-green-power"/>) are getting underway. Agreed sets of metric s and corresponding data models will provide the basis for further steps, beginn ing with their implementation as part of management and control instrumentation. | <t>To remedy this situation, efforts to define sets of green networking metrics <xref target="I-D.cx-green-green-metrics"/> as well as YANG data models that include objects that provide visibility into power measurements (e.g., <xre f target="I-D.li-green-power"/>) were underway in 2024. Agreed sets of metrics and corresponding data models will provide the basis for further steps, beginnin g with their implementation as part of management and control instrumentation. | |||
</t> | </t> | |||
<t> | <t> | |||
Instrumentation should also take into account the possibility of virtualization, | Instrumentation should also take into account the possibility of virtualization, | |||
introducing layers of indirection to assess the actual energy usage. For exampl | introducing layers of indirection to assess the actual energy usage. For exampl | |||
e, virtualized networking functions could be hosted on containers or virtual mac | e, virtualized networking functions could be hosted on containers or virtual mac | |||
hines which are hosted on a CPU in a data center instead of a regular network ap | hines that are hosted on a CPU in a data center instead of a regular network app | |||
pliance such as a router or a switch, leading to very different power consumptio | liance such as a router or a switch, leading to very different power consumption | |||
n characteristics. For example, a data center CPU could be more power efficient | characteristics. For example, a data center CPU's power consumption could be mo | |||
and consume power more proportionally to actual CPU load. Instrumentation needs | re efficient and more proportional to actual CPU load. Instrumentation needs to | |||
to reflect these facts and facilitate attributing power consumption in a correct | reflect these facts and facilitate attributing power consumption in a correct ma | |||
manner. | nner. | |||
</t> | </t> | |||
<t> | <t> | |||
Beyond monitoring and providing visibility into power consumption, control knobs | Beyond monitoring and providing visibility into power consumption, control knobs | |||
are needed to configure energy saving policies. For instance, power saving mode | are needed to configure energy-saving policies. For instance, power-saving mode | |||
s are common in endpoints (such as mobile phones or notebook computers) but sore | s are common in endpoints (such as mobile phones or notebook computers) but sore | |||
ly lacking in networking equipment. | ly lacking in networking equipment. | |||
</t> | </t> | |||
<t> | <t> | |||
The following summarizes some challenges and opportunities in this space that ca n provide the basis for advances in greener networking: | The following summarizes some challenges and opportunities in this space that ca n provide the basis for advances in greener networking: | |||
<list style="symbols"> | ||||
<t>Basic equipment categorization as "energy-efficient" (or not) as a fir | ||||
st step to identify immediate potential improvements, akin to the EnergyStar pro | ||||
gram from the US's Environmental Protection Agency. </t> | ||||
<t>Equipment instrumentation advances for improved energy-awareness; definit | ||||
ion and standardization of granular management information.</t> | ||||
<t>Virtualized energy and carbon metrics and assessment of their effectivene | ||||
ss in solutions that optimize carbon footprint also in virtualized environments | ||||
(including SDN, network slicing, network function virtualization, etc.). </t> | ||||
<t>Certification and compliance assessment methods that ensure that green in | ||||
strumentation cannot be manipulated to give false and misleading data.</t> | ||||
<t>Methods that allow to account for energy mix powering equipment, to facil | ||||
itate solutions that optimize carbon footprint and minimize pollution beyond mer | ||||
e energy efficiency <xref target="Hossain2019"/>.</t> | ||||
</list> | ||||
</t> | </t> | |||
</section> | <ul spacing="normal"> | |||
</section> | <li> | |||
<section title="Challenges and Opportunities - Protocol Level" anchor="sec:proto | <t>Basic equipment categorization as "energy efficient" (or not) as | |||
col"> | a first step to identify immediate potential improvements, akin to the Energy St | |||
<t> | ar program from the US's Environmental Protection Agency. </t> | |||
There are several opportunities to improve network sustainability at the protoco | </li> | |||
l level. We characterize them along several categories. The first and arguably | <li> | |||
most impactful category concerns protocols that enable carbon footprint optimiza | <t>Equipment instrumentation advances for improved energy awareness; | |||
tion schemes at the network level and management towards those goals. Other cate | definition and standardization of granular management information.</t> | |||
gories concern protocols designed to optimize data transmission rates under ener | </li> | |||
gy considerations, protocols designed to reduce the volume of data to be transmi | <li> | |||
tted, and protocol aspects related to network addressing schemes. While those ca | <t>Virtualized energy and carbon metrics and assessment of their eff | |||
tegories may be less impactful, even areas with smaller gains should not be left | ectiveness in solutions that optimize carbon footprints in virtualized environme | |||
unexplored. | nts (including SDN, network slicing, network function virtualization, etc.). </t | |||
> | ||||
</li> | ||||
<li> | ||||
<t>Certification and compliance assessment methods that ensure that | ||||
green instrumentation cannot be manipulated to give false and misleading data.</ | ||||
t> | ||||
</li> | ||||
<li> | ||||
<!--[rfced] FYI, "energy mix powering equipment" has been | ||||
updated as follows. Please review whether it conveys the intended | ||||
meaning. | ||||
Original: | ||||
* Methods that allow to account for energy mix powering equipment, | ||||
to facilitate solutions that optimize carbon footprint and | ||||
minimize pollution beyond mere energy efficiency [Hossain2019]. | ||||
Current: | ||||
* Methods that account for equipment that powers an energy mix, to | ||||
facilitate solutions that optimize carbon footprint and minimize | ||||
pollution beyond mere energy efficiency [Hossain2019]. | ||||
--> | ||||
<t>Methods that account for equipment that powers an energy mix, to | ||||
facilitate solutions that optimize carbon footprint and minimize pollution beyon | ||||
d mere energy efficiency <xref target="Hossain2019"/>.</t> | ||||
</li> | ||||
</ul> | ||||
</section> | ||||
</section> | ||||
<section anchor="sec_protocol"> | ||||
<name>Challenges and Opportunities - Protocol Level</name> | ||||
<t> | ||||
There are several opportunities to improve network sustainability at the protoco | ||||
l level, which can be categorized as follows. The first and arguably most impact | ||||
ful category concerns protocols that enable carbon footprint optimization scheme | ||||
s at the network level and management towards those goals. Other categories conc | ||||
ern protocols designed to optimize data transmission rates under energy consider | ||||
ations, protocols designed to reduce the volume of data to be transmitted, and p | ||||
rotocol aspects related to network addressing schemes. While those categories ma | ||||
y be less impactful, even areas with smaller gains should be explored. | ||||
</t> | </t> | |||
<t> | <t> | |||
There is also substantial work in the area of IoT, which has had to contend with | There is also substantial work in the area of IoT, which has had to contend with | |||
energy-constrained devices for a long time. Much of that work was motivated not | energy-constrained devices for a long time. Much of that work was motivated not | |||
by sustainability concerns but practical concerns such as battery life. However , | by sustainability concerns but practical concerns such as battery life. However , | |||
many aspects appear to also apply in the context of sustainability, such as redu cing | many aspects appear to also apply in the context of sustainability, such as redu cing | |||
chattiness to allow IoT equipment to go into low-power mode. Accordingly, there is | chattiness to allow IoT equipment to go into low-power mode. Accordingly, there is | |||
opportunity to extend IoT work to more generalized scenarios. The | an opportunity to extend IoT work to more generalized scenarios. The | |||
use of power-constrained protocols into the wider Internet happens | use of power-constrained protocols in the wider Internet happens | |||
regularly. For instance, ARM-based chipsets initially designed for | regularly. For instance, ARM-based chipsets initially designed for | |||
energy-efficiency in battery-operated mobile devices have been | energy efficiency in battery-operated mobile devices have been | |||
embraced in data centers for a similar trajectory. | embraced in data centers for a similar trajectory. | |||
</t> | </t> | |||
<section title="Protocol Enablers for Carbon Optimization Mechanisms" anchor="Ne | <section anchor="NetworkEnergySaving"> | |||
tworkEnergySaving"> | <name>Protocol Enablers for Carbon Optimization Mechanisms</name> | |||
<t> | <t> | |||
As will be discussed in <xref target="sec:network"/>, energy-aware and pollution | As discussed in <xref target="sec_network"/>, energy-aware and pollution-aware s | |||
-aware schemes can help improve network sustainability but require awareness of | chemes can help improve network sustainability but require awareness of related | |||
related data. To facilitate such schemes, protocols are needed that are able to | data. To facilitate such schemes, protocols are needed that are able to discove | |||
discover what links are available along with their energy efficiency. For insta | r what links are available along with their energy efficiency. For instance, lin | |||
nce, links may be turned off in order to save energy and turned back on based up | ks may be turned off in order to save energy and turned back on based upon the e | |||
on the elasticity of the demand. Protocols should be devised to discover when th | lasticity of the demand. Protocols should be devised to discover when this happe | |||
is happens, and to have a view of the topology that is consistent with frequent | ns and to have a dynamic view of the topology that keeps up with frequent update | |||
topology updates due to power cycling of the network resources. | s due to power cycling of the network resources. | |||
</t> | </t> | |||
<t> | <t> | |||
Also, protocols are required to quickly converge onto an energy-efficient path o | Also, protocols are required to quickly converge onto an energy-efficient path o | |||
nce a new topology is created by turning links on/off. Current routing protocols | nce a new topology is created by turning links on/off. Current routing protocols | |||
may provide for fast recovery in the case of failure. However, failures are hop | may provide for fast recovery in the case of failure. However, failures are hop | |||
efully relatively rare events, while we expect an energy efficient network to ag | efully relatively rare events, while we expect an energy-efficient network to ag | |||
gressively try to turn off links. There may be synergies with time-variant rout | gressively try to turn off links. There may be synergies with Time-Variant Rout | |||
ing <xref target="I.D.draft-ietf-tvr-requirements"/> that can be explored, in wh | ing <xref target="I-D.ietf-tvr-requirements"/> that can be explored, in which th | |||
ich topology varies over time with nodes and links turned on or off according to | e topology varies over time with nodes and links turned on or off according to a | |||
a schedule. There may even be overlaps in use cases, for example in cases where | schedule. There may be overlaps in use cases, for example, when regular changes | |||
regular changes in the energy mix (and hence carbon footprint) of some nodes oc | in the energy mix (and hence carbon footprint) of some nodes occur that coincid | |||
cur that coincide with the time of day (such as switching from solar to fossil f | e with the time of day (such as switching from solar to fossil fuels at night). | |||
uels at night). | ||||
</t> | </t> | |||
<t> | <t> | |||
Some mechanism is needed to present to the management layer a view of the networ | Some mechanism is needed to present to the management layer a view of the networ | |||
k that identifies opportunities to turn resources off (routers/links) while stil | k that identifies opportunities to turn off resources (e.g., routers or links) w | |||
l providing an acceptable level of Quality of Experience (QoE) to the users. Thi | hile still providing an acceptable level of Quality of Experience (QoE) to the u | |||
s gets more complex as the level of QoE shifts from the current Best Effort deli | sers. This gets more complex as the level of QoE shifts from the current best-ef | |||
very model to more sophisticated mechanisms with, for instance, latency, bandwid | fort delivery model to more sophisticated mechanisms with, for instance, latency | |||
th or reliability guarantees. | , bandwidth, or reliability guarantees. | |||
</t> | </t> | |||
<t>Similarly, schemes might be devised in which links across paths with a favora ble energy mix are preferred over other paths. This implies that the discovery o f topology should be able support corresponding parameters. More generally spea king, any mechanism that provides applications with network visibility is a cand idate for scrutinization as to whether it should be extended to provide support for sustainability-related parameters. | <t>Similarly, schemes might be devised in which links across paths with a favorable energy mix are preferred over other paths. This implies that the dis covery of topology should be able support corresponding parameters. More genera lly speaking, any mechanism that provides applications with network visibility i s a candidate for scrutinization as to whether it should be extended to provide support for sustainability-related parameters. | |||
</t> | </t> | |||
<t> | <t> | |||
The following summarizes some challenges and opportunities in this space that ca n provide the basis for advances in greener networking: | The following summarizes some challenges and opportunities in this space that ca n provide the basis for advances in greener networking: | |||
<list style="symbols"> | ||||
<t>Protocol advances to enable rapidly taking down, bring back online, and d | ||||
iscover availability and power saving status of networking resources while minim | ||||
izing the need for reconvergence and propagation of state.</t> | ||||
<t>An assessment of which protocols could be extended with energy- and susta | ||||
inability-related parameters in ways that would enable "greener" networking solu | ||||
tions, and exploration of those solutions. </t> | ||||
</list> | ||||
</t> | </t> | |||
<!-- CW: QoS, QoE and then EoS Energy of Service? --> | <ul spacing="normal"> | |||
<li> | ||||
<t>Protocol advances to enable rapidly taking down, bringing back on | ||||
line, and discovering availability and power-saving status of networking resourc | ||||
es while minimizing the need for reconvergence and propagation of state.</t> | ||||
</li> | ||||
<li> | ||||
<t>An assessment of which protocols could be extended with energy- a | ||||
nd sustainability-related parameters in ways that would enable "greener" network | ||||
ing solutions, and an exploration of those solutions. </t> | ||||
</li> | ||||
</ul> | ||||
<!-- CW: QoS, QoE and then EoS Energy of Service? --> | ||||
</section> | </section> | |||
<!-- End of Enabling Energy Saving Mechanisms subsection--> | <!-- End of Enabling Energy Saving Mechanisms subsection--> | |||
<section title="Protocol Optimization" anchor="TrafficAdaptation"> | <!--[rfced] FYI, we updated these terms as follows, based on their | |||
<t> | usage in other documents (including on ieeexplore.ieee.org and | |||
The second category involves designing protocols in such a way that the rate of | dl.acm.org). Please review. Also, we removed "(MLU)" because | |||
transmission is chosen to maximize energy efficiency. For example, Traffic Engi | the acronym is not used within this document. | |||
neering (TE) can be manipulated to impact the rate adaptation mechanism <xref ta | ||||
rget="Ren2018jordan"/>. By choosing where to send the traffic, TE can artificial | Original: | |||
ly congest links so as to trigger rate adaptation and therefore reduce the total | Maximal Link Utilization (MLU) | |||
amount of traffic. Most TE systems attempt to minimize Maximal Link Utilization | minimal link utilization | |||
(MLU) but energy saving mechanisms could decide to do the opposite (maximize mi | ||||
nimal link utilization) and attempt to turn off some resources to save power. | Current: | |||
Maximum Link Utilization | ||||
Minimum Link Utilization | ||||
--> | ||||
<section anchor="TrafficAdaptation"> | ||||
<name>Protocol Optimization</name> | ||||
<t> | ||||
The second category involves designing protocols in such a way that the rate of | ||||
transmission is chosen to maximize energy efficiency. For example, Traffic Engi | ||||
neering (TE) can be manipulated to impact the rate adaptation mechanism <xref ta | ||||
rget="Ren2018jordan"/>. By choosing where to send the traffic, TE can artificial | ||||
ly congest links so as to trigger rate adaptation and therefore reduce the total | ||||
amount of traffic. Most TE systems attempt to minimize Maximum Link Utilization | ||||
but energy-saving mechanisms could decide to do the opposite (i.e., maximize Mi | ||||
nimum Link Utilization) and attempt to turn off some resources to save power. | ||||
</t> | </t> | |||
<t>Another example is to set up the proper rate of transmission to minimize the | <!--[rfced] FYI, we updated "in the limit" to "in an extreme case" | |||
flow completion time (FCT) so as to enable opportunities to turn off links. In a | here. Please let us know if that is not the intended meaning. | |||
wireless context, <xref target="TradeOff" /> studies how setting the proper ini | ||||
tial value for the congestion window can reduce the FCT and therefore allow the | Current: | |||
equipment to go faster into a low-energy mode. By sending the data faster, the e | This should be done | |||
nergy cost can be significantly reduced. This is a simple proof of concept, but | carefully: in an extreme case, a high rate of transmission over a | |||
protocols that allow for turning links into a low-power mode by transmitting the | short period of time may create bursts that the network would need to | |||
data over shorter periods could be designed for other types of networks beyond | accommodate, with all attendant complications of bursty traffic. | |||
Wi-Fi access. This should be done carefully: in the limit, a high rate of transm | --> | |||
ission over a short period of time may create bursts that the network would need | <t>Another example is to set up the proper rate of transmission to minim | |||
to accommodate, with all attendant complications of bursty traffic. We conjectu | ize the flow completion time (FCT) so as to enable opportunities to turn off lin | |||
re there is a sweet spot between trying to complete flows faster while controlli | ks. In a wireless context, <xref target="TradeOff"/> studies how setting the pro | |||
ng for burstiness in the network. It is probably advisable to attempt to send tr | per initial value for the congestion window can reduce the FCT and therefore all | |||
affic paced yet in bulk rather than spread out over multiple round trips. This i | ow the equipment to go faster into a low-energy mode. By sending the data faster | |||
s an area of worthwhile exploration. | , the energy cost can be significantly reduced. This is a simple proof of concep | |||
t, but protocols that allow for turning links into a low-power mode by transmitt | ||||
ing the data over shorter periods could be designed for other types of networks | ||||
beyond Wi-Fi access. This should be done carefully: in an extreme case, a high r | ||||
ate of transmission over a short period of time may create bursts that the netwo | ||||
rk would need to accommodate, with all attendant complications of bursty traffic | ||||
. We conjecture there is a sweet spot between trying to complete flows faster wh | ||||
ile controlling for burstiness in the network. It is probably advisable to attem | ||||
pt to send traffic paced yet in bulk rather than spread out over multiple round | ||||
trips. This is an area of worthwhile exploration. | ||||
</t> | </t> | |||
<t> | <t> | |||
The following summarizes some challenges and opportunities in this space that ca n provide the basis for advances in greener networking: | The following summarizes some challenges and opportunities in this space that ca n provide the basis for advances in greener networking: | |||
<list style="symbols"> | ||||
<t>Protocol advances that allow greater control over traffic pacing to accou | ||||
nt for fluctuations in carbon cost, i.e., control knobs to "bulk up" transmissio | ||||
n over short periods or to smoothen it out over longer periods. </t> | ||||
<t>Protocol advances that allow to optimize link utilization according to di | ||||
fferent goals and strategies (including maximizing minimal link utilization vs m | ||||
inimizing maximal link utilization, etc.)</t> | ||||
<t>Assessments of the carbon impact of such strategies.</t> | ||||
</list> | ||||
</t> | </t> | |||
<!-- CW: most transport protocols attempt to find the operating point where traf | <ul spacing="normal"> | |||
fic is sent without dropping packet. TCPs seesaw mechanism is rather crude for t | <li> | |||
his purpose. New protocols such as BBR should be more efficient in that respect. | <t>Protocol advances that allow greater control over traffic pacing | |||
I feel this section can be beefed up a bit. Also we can circle back to your poi | to account for fluctuations in carbon cost, i.e., control knobs to "bulk up" tra | |||
nt in the intro that bursty transmission of traffic is more energy efficient. Th | nsmission over short periods or to smooth it out over longer periods. </t> | |||
is is true at the edge only, I would assume, since bursts are multiplexed in the | </li> | |||
core. That said: having some burst when there are few flows, and then some more | <li> | |||
fluid behavior when there are many could be suggested. For instance, having som | <t>Protocol advances for optimizing link utilization according to di | |||
e "energy gateway" that buffers the burst from the domain with few flows and the | fferent goals and strategies (including maximizing Minimal Link Utilization vs. | |||
n transmit them to the domain with more flows, and back on the other end of the | minimizing Maximal Link Utilization, etc.)</t> | |||
connection --> | </li> | |||
<li> | ||||
<t>Assessments of the carbon impact of such strategies.</t> | ||||
</li> | ||||
</ul> | ||||
<!-- CW: most transport protocols attempt to find the operating point wh | ||||
ere traffic is sent without dropping packet. TCPs seesaw mechanism is rather cru | ||||
de for this purpose. New protocols such as BBR should be more efficient in that | ||||
respect. I feel this section can be beefed up a bit. Also we can circle back to | ||||
your point in the intro that bursty transmission of traffic is more energy effic | ||||
ient. This is true at the edge only, I would assume, since bursts are multiplexe | ||||
d in the core. That said: having some burst when there are few flows, and then s | ||||
ome more fluid behavior when there are many could be suggested. For instance, ha | ||||
ving some "energy gateway" that buffers the burst from the domain with few flows | ||||
and then transmit them to the domain with more flows, and back on the other end | ||||
of the connection --> | ||||
</section> | </section> | |||
<section title="Data Volume Reduction" anchor="DataVolume"> | <section anchor="DataVolume"> | |||
<t> | <name>Data Volume Reduction</name> | |||
The first category involves designing protocols in such a way that they reduce t | <!--[rfced] For the ease of the reader, would you like to | |||
he volume of data that needs to be transmitted for any given purpose. Loosely sp | add a definition for "Shannon limit"? For example, perhaps | |||
eaking, by reducing this volume, more traffic can be served by the same amount o | it's referring to [Shannon] as referenced in RFC 6386. | |||
f networking infrastructure, hence reducing overall energy consumption. Possibil | ||||
ities here include protocols that avoid unnecessary retransmissions. At the app | Original: | |||
lication layer, protocols may also use coding mechanisms that encode information | At the application layer, protocols may also use | |||
close to the Shannon limit. Currently, most of the traffic over the Internet c | coding mechanisms that encode information close to the Shannon limit. | |||
onsists of video streaming and encoders for video are already quite efficient an | --> | |||
d keep improving all the time, resulting in energy savings as one of many advant | ||||
ages (of course being offset by increasingly higher resolution). However, it is | <!--[rfced] FYI, we updated this sentence as follows to clarify | |||
not clear that the extra work to achieve higher compression ratios for the paylo | "(of course being offset by increasingly higher resolution)"; please | |||
ads results in a net energy gain: what is saved over the network may be offset b | review. Is it accurate the savings are offset by the energy demands of | |||
y the compression/decompression effort. Further research on this aspect is neces | increasingly higher resolution? | |||
sary. | ||||
Original: | ||||
Currently, most of the traffic over the Internet consists of video | ||||
streaming and encoders for video are already quite efficient and keep | ||||
improving all the time, resulting in energy savings as one of many | ||||
advantages (of course being offset by increasingly higher | ||||
resolution). | ||||
Current: | ||||
Currently, most of the traffic over the Internet consists of video | ||||
streaming, and video encoders are already quite efficient and keep | ||||
improving all the time. This results in energy savings as one of | ||||
many advantages, although of course the savings are offset by | ||||
increasingly higher resolution. | ||||
--> | ||||
<t> | ||||
The third category involves designing protocols in such a way that they reduce t | ||||
he volume of data that needs to be transmitted for any given purpose. Loosely sp | ||||
eaking, by reducing this volume, more traffic can be served by the same amount o | ||||
f networking infrastructure, hence reducing overall energy consumption. Possibil | ||||
ities here include protocols that avoid unnecessary retransmissions. At the app | ||||
lication layer, protocols may also use coding mechanisms that encode information | ||||
close to the Shannon limit. Currently, most of the traffic over the Internet c | ||||
onsists of video streaming, and video encoders are already quite efficient and k | ||||
eep improving all the time. This results in energy savings as one of many advant | ||||
ages, although of course the savings are offset by increasingly higher resolutio | ||||
n. It is not clear that the extra work to achieve higher compression ratios for | ||||
the payloads results in a net energy gain: what is saved over the network may be | ||||
offset by the compression/decompression effort. Further research on this aspect | ||||
is necessary. | ||||
</t> | </t> | |||
<t>At the transport protocol layer, TCP and to some extent QUIC react to congest ion by dropping packets. This is a highly energy inefficient method to signal co ngestion, since the network has to wait one RTT to be aware that the congestion has occurred, and since the effort to transmit the packet from the source up unt il it is dropped ends up being wasted. This calls for new transport protocols t hat react to congestion without dropping packets. ECN <xref target="RFC2481"/> i s a possible solution, however, it is not widely deployed. DC-TCP <xref target=" Alizadeh2010DCTCP"/> is tuned for Data Centers, L4S is an attempt to port simila r functionality to the Internet <xref target="RFC9330"/>. Qualitative Communicat ion <xref target="QUAL"/> <xref target="Westphal2021qualitative"/> allows the no des to react to congestion by dropping only some of the data in the packet, ther eby only partially wasting the resource consumed by transmitted the packet up to this point. Novel transport protocols for the WAN can ensure that no energy is wasted transmitting packets that will be eventually dropped. | <t>At the transport protocol layer, TCP and to some extent QUIC react to congestion by dropping packets. This is an extremely energy inefficient method to signal congestion because (a) the network has to wait one RTT to be aware tha t the congestion has occurred, and (b) the effort to transmit the packet from th e source up until it is dropped ends up being wasted. This calls for new transp ort protocols that react to congestion without dropping packets. ECN <xref targe t="RFC2481"/> is a possible solution, however, it is not widely deployed. DCTCP <xref target="Alizadeh2010DCTCP"/> is tuned for data centers; Low Latency, Low L oss, and Scalable Throughput (L4S) is an attempt to port similar functionality t o the Internet <xref target="RFC9330"/>. Qualitative Communication <xref target= "QUAL"/> <xref target="Westphal2021qualitative"/> allows the nodes to react to c ongestion by dropping only some of the data in the packet, thereby only partiall y wasting the resource consumed by transmitted the packet up to that point. Nov el transport protocols for the WAN can ensure that no energy is wasted transmitt ing packets that will be eventually dropped. | |||
</t> | </t> | |||
<t>Another solution to reduce the bandwidth of network protocols by reducing the ir header tax, for example applying header compression. An example in IETF is <x ref target="RFC3095"/>. Again, reducing protocol header size saves energy to for ward packets, but at the cost of maintaining a state for compression/decompressi on, plus computing these operations. The gain from such protocol optimization fu rther depends on the application and whether it sends packets with large payload s close to the MTU (the header tax and any savings here are very limited), or wh ether it sends packets with very small payload size (making the header tax more pronounced and savings more significant). | <t>Another solution to reduce the bandwidth of network protocols is by r educing their header tax, for example, by applying header compression. An exampl e in IETF is RObust Header Compression (ROHC) <xref target="RFC3095"/>. Again, r educing protocol header size saves energy to forward packets, but at the cost of maintaining a state for compression/decompression, plus computing these operati ons. The gain from such protocol optimization further depends on the application and whether it sends packets with (a) large payloads close to the MTU, thus lim iting the header tax and any savings, or (b) very small payload size, thus incre asing the header tax and the savings. | |||
</t> | </t> | |||
<t> | <t> | |||
An alternative to reducing the amount of protocol data is to design routing prot | An alternative to reducing the amount of protocol data is to design routing prot | |||
ocols that are more efficient to process at each node. For instance, path-based | ocols that are more efficient to process at each node. For instance, path-based | |||
forwarding/labels such as MPLS <xref target="RFC3031"/> facilitate the next hop | forwarding/labels such as MPLS <xref target="RFC3031"/> facilitate the next hop | |||
look-up, thereby reducing the energy consumption. It is unclear if some state at | lookup, thereby reducing the energy consumption. It is unclear if some state at | |||
router to speed up look up is more energy efficient that "no state + lookup" th | router to speed up lookup is more energy efficient than "no state + lookup", whi | |||
at is more computationally intensive. Other methods to speed up a next-hop looku | ch is more computationally intensive. Other methods to speed up a next-hop looku | |||
p include geographic routing (e.g., <xref target="Herzen2011PIE"/>). Some networ | p include geographic routing (e.g., <xref target="Herzen2011PIE"/>). Some networ | |||
k protocols could be designed to reduce the next hop look-up computation at a ro | k protocols could be designed to reduce the next hop lookup computation at a rou | |||
uter. It is unclear if Longest Prefix Match (LPM) is efficient from an energy p | ter. It is unclear whether Longest Prefix Match (LPM) is energy efficient or a | |||
oint of view or if constitutes a significant energy burden for the operation of | significant energy burden for router operation. | |||
a router. | ||||
</t> | </t> | |||
<t>Beyond the volume of data itself, another consideration is the number of mess ages and chattiness of the protocol. Some protocols rely on frequent periodic u pdates or heartbeats, which may prevent equipment to go into sleep mode. In such cases, it makes sense to explore the use of feasible alternatives that rely on different communication patterns and fewer messages. | <t>Beyond the volume of data itself, another consideration is the number of messages and chattiness of the protocol. Some protocols rely on frequent pe riodic updates or heartbeats, which may prevent equipment from going into sleep mode. In such cases, it makes sense to explore the use of feasible alternatives that rely on different communication patterns and fewer messages. | |||
</t> | </t> | |||
<t> | <t> | |||
The following summarizes some challenges and opportunities in this space that ca n provide the basis for advances in greener networking: | The following summarizes some challenges and opportunities in this space that ca n provide the basis for advances in greener networking: | |||
<list style="symbols"> | ||||
<t>Assessments of energy-related tradeoffs regarding protocol design space a | ||||
nd tradeoffs, such as maintaining state versus more compact encodings or extra c | ||||
omputation for transcoding operations versus larger data volume. </t> | ||||
<t>Protocol advances for improving the ratio of goodput to throughput and to | ||||
reduce waste: reduction in header tax, in protocol verbosity, in need for retra | ||||
nsmissions, improvements in coding, etc. </t> | ||||
<t>Protocols that allow to manage transmission patterns in ways that facilit | ||||
ate periods of link inactivity, such as burstiness and chattiness. </t> | ||||
</list> | ||||
</t> | </t> | |||
</section> | <ul spacing="normal"> | |||
<li> | ||||
<t>Assessments of energy-related trade-offs regarding protocol desig | ||||
n space and trade-offs, such as maintaining state versus more compact encodings, | ||||
or extra computation for transcoding operations versus larger data volume. </t> | ||||
</li> | ||||
<!--[rfced] May this item be rephrased as follows? The original list | ||||
reads as "reduction in improvements in coding", which does not seem intended. | ||||
<section title="Network Addressing" anchor="Addressing"> | Original: | |||
<t> | * Protocol advances for improving the ratio of goodput to throughput | |||
There may be other ways to shave off energy usage from networks. One example co | and to reduce waste: reduction in header tax, in protocol | |||
ncerns network addressing. Address tables can get very large, resulting in larg | verbosity, in need for retransmissions, improvements in coding, | |||
e forwarding tables that require considerable amount of memory, in addition to l | etc. | |||
arge amounts of state needing to be maintained and synchronized. From an energy | ||||
footprint perspective, both can be considered wasteful and offer opportunities | Perhaps: | |||
for improvement. At the protocol level, rethinking how addresses are structure | * Protocol advances for improving the ratio of goodput to throughput | |||
d can allow for flexible addressing schemes that can be exploited in network dep | and to reduce waste; this could include coding improvements as well as | |||
loyments that are less energy-intensive by design. This can be complemented by | reductions in the header tax, the protocol verbosity, and the need for | |||
supporting clever address allocation schemes that minimize the number of require | retransmissions. | |||
d forwarding entries as part of deployments. | --> | |||
<li> | ||||
<t> | ||||
Protocol advances for improving the ratio of goodput to throughput | ||||
and to reduce waste: reduction in header tax, in protocol | ||||
verbosity, in need for retransmissions, improvements in coding, | ||||
etc. | ||||
</t> | ||||
</li> | ||||
<li> | ||||
<t>Protocols that allow for managing transmission patterns in ways t | ||||
hat facilitate periods of link inactivity, such as burstiness and chattiness. </ | ||||
t> | ||||
</li> | ||||
</ul> | ||||
</section> | ||||
<section anchor="Addressing"> | ||||
<name>Network Addressing</name> | ||||
<!--[rfced] "energy footprint" vs. "carbon footprint" | ||||
In Section 5.4, the first paragraph uses the former, whereas the | ||||
summary uses the latter. Is this accurate? | ||||
Note: "energy footprint" only appears twice in this document; | ||||
please consider whether "energy consumption" is more accurate. | ||||
Original: | ||||
From an energy footprint perspective, ... | ||||
[...] | ||||
* Devise methods to assess the magnitude of the carbon footprint | ||||
that is associated with addressing schemes. | ||||
--> | ||||
<t> | ||||
Network addressing is another way to shave off energy usage from networks. Addr | ||||
ess tables can get very large, resulting in large forwarding tables that require | ||||
considerable amount of memory, in addition to large amounts of state that needs | ||||
to be maintained and synchronized. From an energy footprint perspective, both | ||||
can be considered wasteful and offer opportunities for improvement. At the pro | ||||
tocol level, rethinking how addresses are structured can allow for flexible addr | ||||
essing schemes that can be exploited in network deployments that are less energy | ||||
-intensive by design. This can be complemented by supporting clever address all | ||||
ocation schemes that minimize the number of required forwarding entries as part | ||||
of deployments. | ||||
</t> | </t> | |||
<t>Alternatively, the address could be designed to allow for more efficient proc essing than LPM. For instance, a geographic type of addressing (where the next h op is computed as a simple distance calculation based on the respective position of the current node, of its neighbors and of the destination) <xref target="Her zen2011PIE"/> could be potentially more energy efficient. | <t>Alternatively, the addressing could be designed to allow for more eff icient processing than LPM. For instance, a geographic type of addressing (where the next hop is computed as a simple distance calculation based on the respecti ve position of the current node, of its neighbors and of the destination) <xref target="Herzen2011PIE"/> could be potentially more energy efficient. | |||
</t> | </t> | |||
<t> | <t> | |||
The following summarizes some challenges and opportunities in this space that ca n provide the basis for advances in greener networking: | The following summarizes some challenges and opportunities in this space that ca n provide the basis for advances in greener networking: | |||
<list style="symbols"> | ||||
<t>Devise methods to assess the magnitude of the carbon footprint that is as | ||||
sociated with addressing schemes.</t> | ||||
<t>Devise methods to improve addressing schemes, as well as address assignme | ||||
nt schemes, to minimize their footprint.</t> | ||||
</list> | ||||
</t> | </t> | |||
</section> | <ul spacing="normal"> | |||
</section><!-- End of Protocol Level Section--> | <li> | |||
<t>Devise methods to assess the magnitude of the carbon footprint th | ||||
at is associated with addressing schemes.</t> | ||||
</li> | ||||
<li> | ||||
<t>Devise methods to improve addressing schemes, as well as address | ||||
assignment schemes, to minimize their footprint.</t> | ||||
</li> | ||||
</ul> | ||||
</section> | ||||
</section> | ||||
<section title="Challenges and Opportunities - Network Level" anchor="sec:networ | <section anchor="sec_network"> | |||
k"> | <name>Challenges and Opportunities - Network Level</name> | |||
<section title="Network Optimization and Energy/Carbon/Pollution-Aware Networkin | <section anchor="sec_ean"> | |||
g" anchor="sec:ean"> | <name>Network Optimization and Energy/Carbon/Pollution-Aware Networking< | |||
<t> | /name> | |||
Networks have been optimized for many years under many criteria, for example to | <t> | |||
optimize (maximize) network utilization and to optimize (minimize) cost. Hence, | Networks have been optimized for many years under many criteria, for example, to | |||
it is straightforward to add optimization for "greenness" (including energy eff | optimize (maximize) network utilization and to optimize (minimize) cost. Hence | |||
iciency, power consumption, carbon footprint) as important criteria. | , it is straightforward to add optimization for "greenness" (including energy ef | |||
ficiency, power consumption, carbon footprint) as important criteria. | ||||
</t> | </t> | |||
<t> | <t> | |||
This includes assessing the carbon footprints of paths and optimizing those path s so that overall footprint is minimized, then applying techniques such as path- aware networking or segment routing <xref target="RFC8402"/> to steer traffic al ong those paths. (As mentioned earlier, other proxy measures | This includes assessing the carbon footprints of paths and optimizing those path s so that overall footprint is minimized, then applying techniques such as path- aware networking or segment routing <xref target="RFC8402"/> to steer traffic al ong those paths. (As mentioned earlier, other proxy measures | |||
could be used for carbon footprint, such as an energy-efficiency ratings of trav | could be used for carbon footprint, such as energy-efficiency ratings of travers | |||
ersed equipment.) | ed equipment.) | |||
It also includes aspects such as considering the incremental carbon footprint in | It also includes aspects such as considering the incremental carbon footprint in | |||
routing decisions. Optimizing cost has a long tradition in networking; many of | routing decisions. Optimizing cost has a long tradition in networking; many of | |||
the existing mechanisms can be leveraged for greener networking simply by intro | the existing mechanisms can be leveraged for greener networking simply by intro | |||
ducing carbon footprint as a cost factor. Low-hanging fruit include the inclusio | ducing the carbon footprint as a cost factor. Low-hanging fruit includes adding | |||
n of carbon-related parameters as a cost parameter in control planes, whether di | carbon-related parameters as a cost parameter in control planes, whether distrib | |||
stributed (e.g., IGP) or conceptually centralized via SDN controllers. Likewise, | uted (e.g., IGP) or conceptually centralized via SDN controllers. Likewise, ther | |||
there are opportunities in right-placing functionality in the network. An exam | e are opportunities in right-placing functionality in the network. | |||
ple concerns placement of virtualized network functions in carbon-optimized ways | <!--[rfced] Will the term "right-placing" be clear to the reader? | |||
- for example, cohosted on fewer servers in close proximity to each other in or | It has not been used before in the RFC series and does not appear | |||
der to avoid unnecessary overhead in long-distance control traffic. | in the dictionary. It appears twice in this document, as follows. | |||
Please consider whether the term should be replaced or explained, | ||||
as follows or otherwise. | ||||
Section 6.1: | ||||
there are opportunities in right-placing functionality in the network. | ||||
Section 7: | ||||
..., right-placing of computational intelligence, ... | ||||
Perhaps: | ||||
S6.1: there are opportunities for "right-placing" functionality, i.e., | ||||
ensuring that it is in the most suitable location for optimal effectiveness. | ||||
[or] | ||||
there are opportunities for deliberate placement of functionality | ||||
within the network. | ||||
S7: ensuring the most suitable placement of computational intelligence | ||||
within the network design | ||||
--> | ||||
An example is placement of virtualized network functions in carbon-optimized wa | ||||
ys, i.e., cohosted on fewer servers in close proximity to each other in order to | ||||
avoid unnecessary overhead in long-distance control traffic. | ||||
</t> | </t> | |||
<!--[rfced] Please clarify what "This" refers to in each instance. | ||||
Perhaps first "This" is weaning, and the second "This" is load-balancing. | ||||
May it be significantly rephrased as shown below? | ||||
Original: | ||||
Therefore, weaning such | ||||
resources from traffic becomes an important consideration for energy- | ||||
efficient traffic steering. This contrasts and indeed conflicts with | ||||
existing schemes that typically aim to create redundancy and load- | ||||
balance traffic across a network to achieve even resource | ||||
utilization. This usually occurs for important reasons, such as | ||||
making networks more resilient, optimizing service levels, and | ||||
increasing fairness. | ||||
Perhaps: | ||||
Therefore, weaning resources from traffic is an important consideration | ||||
for energy-efficient traffic steering. This approach conflicts with | ||||
existing schemes that typically aim to increase network resilience, | ||||
optimize service levels, and ensure fairness by creating redundancy and | ||||
load-balancing traffic for even resource utilization. | ||||
--> | ||||
<t> | <t> | |||
Other opportunities concern adding carbon-awareness to dynamic path selection sc hemes. This is sometimes also referred to as "energy-aware networking" (respect ively "pollution-aware networking" <xref target="Hossain2019"/> or "carbon-aware networking", when carbon footprint related parameters beyond pure energy consum ption are taken into account). Again, considerable energy savings can potential ly be realized by taking resources offline (e.g., putting them into power-saving or hibernation mode) when they are not currently needed under current network d emand and load conditions. Therefore, weaning such resources from traffic become s an important consideration for energy-efficient traffic steering. This contra sts and indeed conflicts with existing schemes that typically aim to create redu ndancy and load-balance traffic across a network to achieve even resource utiliz ation. This usually occurs for important reasons, such as making networks more r esilient, optimizing service levels, and increasing fairness. One of the big ch allenges hence concerns how resource weaning schemes to realize energy savings c an be accommodated while preventing the cannibalization of other important goals , counteracting other established mechanisms, and avoiding destabilization of th e network. | Other opportunities concern adding carbon awareness to dynamic path selection sc hemes. This is sometimes referred to as "energy-aware networking" (or "pollutio n-aware networking" <xref target="Hossain2019"/> or "carbon-aware networking", w hen parameters beyond simply energy consumption are taken into account). Again, considerable energy savings can potentially be realized by taking resources off line (e.g., putting them into power-saving or hibernation mode) when they are no t needed under current network demand and load conditions. Therefore, weaning su ch resources from traffic becomes an important consideration for energy-efficien t traffic steering. This contrasts and indeed conflicts with existing schemes t hat typically aim to create redundancy and load-balance traffic across a network to achieve even resource utilization. This usually occurs for important reasons , such as making networks more resilient, optimizing service levels, and increas ing fairness. Thus, a big challenge is how resource-weaning schemes to realize energy savings can be accommodated without cannibalizing other important goals, counteracting other established mechanisms, or destabilizing the network. | |||
</t> | </t> | |||
<t>An opportunity may lie in making a distinction between "energy modes" of diff | <!--[rfced] FYI, this sentence has been updated as follows for readability. | |||
erent domains. For instance, in a highly trafficked core, the energy challenge i | Please review whether it conveys your intended meaning, and whether you | |||
s to transmit the traffic efficiently. The amount of traffic is relatively fluid | prefer the shorter alternative. | |||
(due to multiplexing of multiple sessions) and the traffic is predictable. In t | ||||
his case, there is no need to optimize on a per session basis nor even at a shor | Original: | |||
t time scale. In the access networks connecting to that core, though, there are | One of the big challenges hence concerns how | |||
opportunities for this fast convergence: traffic is much more bursty, less predi | resource weaning schemes to realize energy savings can be | |||
ctable and the network should be able to be more reactive. Other domains such as | accommodated while preventing the cannibalization of other important | |||
DCs may have also more variable workloads and different traffic patterns. | goals, counteracting other established mechanisms, and avoiding | |||
destabilization of the network. | ||||
Current: | ||||
Thus, a big challenge is how | ||||
resource-weaning schemes to realize energy savings can be | ||||
accommodated without cannibalizing other important goals, | ||||
counteracting other established mechanisms, or destabilizing the | ||||
network. | ||||
Or even shorter: | ||||
Thus, a big challenge is implementing resource-weaning for | ||||
energy savings without cannibalizing other important goals, | ||||
counteracting other established mechanisms, or destabilizing the network. | ||||
--> | ||||
<t>An opportunity may lie in making a distinction between "energy modes" | ||||
of different domains. For instance, in a highly trafficked core, the energy cha | ||||
llenge is to transmit the traffic efficiently. The amount of traffic is relative | ||||
ly fluid (due to multiplexing of multiple sessions) and the traffic is predictab | ||||
le. In this case, there is no need to optimize on a per-session basis or at a sh | ||||
ort timescale. In the access networks connecting to that core, though, there are | ||||
opportunities for this fast convergence: traffic is much more bursty and less p | ||||
redictable, and the network should be able to be more reactive. Other domains su | ||||
ch as DCs may have more variable workloads and different traffic patterns. | ||||
</t> | </t> | |||
<t> | <t> | |||
The following summarizes some challenges and opportunities in this space that ca n provide the basis for advances in greener networking: | The following summarizes some challenges and opportunities in this space that ca n provide the basis for advances in greener networking: | |||
<list style="symbols"> | ||||
<t>Devise methods for carbon-aware traffic steering and routing; treat carbo | ||||
n footprint as a traffic cost metric to optimize.</t> | ||||
<t>Apply ML and AI methods to optimize networks for carbon footprint; assess | ||||
applicability of game theoretic approaches.</t> | ||||
<t>Articulate and, as applicable, moderate tradeoffs between carbon awarenes | ||||
s and other operational goals such as robustness and redundancy. </t> | ||||
<t>Extend control-plane protocols with carbon-related parameters. </t> | ||||
<t>Consider security issues imposed by greater energy awareness, to minimize | ||||
the new attack surfaces that would allow an adversary to turn off resources or | ||||
to waste energy.</t> | ||||
</list> | ||||
</t> | </t> | |||
</section> | <ul spacing="normal"> | |||
<section title="Assessing Carbon Footprint and Network-Level Instrumentation"> | <li> | |||
<t> | <t>Devise methods for carbon-aware traffic steering and routing; tre | |||
As an important prerequisite to capture many of the opportunities outlined in <x | at carbon footprint as a traffic cost metric to optimize.</t> | |||
ref target="sec:ean"/>, good abstractions (and corresponding instrumentation) th | </li> | |||
at allow to easily assess energy cost and carbon footprint will be required. The | <li> | |||
se abstractions need to account for not only for the energy cost associated with | <t>Apply Machine Learning (ML) and AI methods to optimize networks f | |||
packet forwarding across a given path, but related cost for processing, for mem | or carbon footprint; assess applicability of game theoretic approaches.</t> | |||
ory, for maintaining of state, to result in a holistic picture. | </li> | |||
<li> | ||||
<t>Articulate and, as applicable, moderate trade-offs between carbon | ||||
awareness and other operational goals such as robustness and redundancy. </t> | ||||
</li> | ||||
<li> | ||||
<t>Extend control plane protocols with carbon-related parameters. </ | ||||
t> | ||||
</li> | ||||
<li> | ||||
<t>Consider security issues imposed by greater energy awareness, to | ||||
minimize the new attack surfaces that would allow an adversary to turn off resou | ||||
rces or to waste energy.</t> | ||||
</li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>Assessing Carbon Footprint and Network-Level Instrumentation</name | ||||
> | ||||
<t> | ||||
As an important prerequisite to capture many of the opportunities outlined in <x | ||||
ref target="sec_ean"/>, good abstractions (and corresponding instrumentation) fo | ||||
r easily assessing energy cost and carbon footprint will be required. These abst | ||||
ractions need to account for not only the energy cost associated with packet for | ||||
warding across a given path, but also the related cost for processing, for memor | ||||
y, and for maintaining of state, to result in a holistic picture. | ||||
</t> | </t> | |||
<t> Optimization of carbon footprint involves in many cases trade-offs that invo | ||||
lve not only packet forwarding but also aspects such as keeping state, caching d | <!--[rfced] Section 6.2: What was intended here, rather than 'latter' twice? | |||
ata, or running computations at the edge instead of elsewhere. (Note: there may | ||||
be a differential in running a computation at an edge server vs. at an hypersca | Original: | |||
le DC. The latter is often better optimized than the latter.) Likewise, other a | (Note: there may be a differential in running | |||
spects of carbon footprint beyond mere energy-intensity should be considered. Fo | a computation at an edge server vs. at an hyperscale DC. The latter | |||
r instance, some network segments may be powered by more sustainable energy sour | is often better optimized than the latter.) | |||
ces than others, and some network equipment may be more environmentally friendly | ||||
to build, deploy and recycle, all of which can be reflected in abstractions to | Perhaps: [The first sentence remains the same.] | |||
consider. | ||||
The latter is often better optimized than the former. | ||||
--> | ||||
<t>In many cases, optimization of carbon footprint has trade-offs that i | ||||
nvolve not only packet forwarding but also aspects such as keeping state, cachin | ||||
g data, or running computations at the edge instead of elsewhere. (Note: There | ||||
may be a differential in running a computation at an edge server vs. at a hypers | ||||
cale DC. The latter is often better optimized than the latter.) Likewise, other | ||||
aspects of carbon footprint beyond mere energy-intensity should be considered. | ||||
For instance, some network segments may be powered by more sustainable energy so | ||||
urces than others, and some network equipment may be more environmentally friend | ||||
ly to build, deploy, and recycle, all of which can be reflected in abstractions | ||||
to consider. | ||||
</t> | </t> | |||
<t>Assessing carbon footprint at the network level requires instrumentation that | <!--[rfced] Please clarify "a particularly poor carbon footprint" here. | |||
associates that footprint not just with individual devices (as outline in <xref | Does it mean a large carbon footprint? If so, we suggest replacing | |||
target="sec:instrum"/> but relates it also to concepts that are meaningful at t | the word "poor", which could be interpreted as "weak" or "substandard". | |||
he network level, i.e., to flows and to paths. For example, it will be useful t | ||||
o provide visibility into the carbon intensity of a path: Can the carbon cost of | Original: | |||
traffic transmitted over the path be aggregated? Does the path include outliers | Does the path include | |||
, i.e., segments with equipment with a particularly poor carbon footprint? | outliers, i.e., segments with equipment with a particularly poor | |||
carbon footprint? | ||||
Perhaps: | ||||
Does the path include | ||||
outliers, i.e., segments with equipment with a particularly large | ||||
carbon footprint? | ||||
--> | ||||
<t>Assessing carbon footprint at the network level requires instrumentat | ||||
ion that associates that footprint not just with individual devices (as outlined | ||||
in <xref target="sec_instrum"/>) but also with concepts that are meaningful at | ||||
the network level, i.e., to flows and to paths. For example, it will be useful | ||||
to provide visibility into the carbon intensity of a path: Can the carbon cost o | ||||
f traffic transmitted over the path be aggregated? Does the path include outlier | ||||
s, i.e., segments with equipment with a particularly poor carbon footprint? | ||||
</t> | </t> | |||
<t>Similarly, how can the carbon cost of a flow be assessed? That might serve m any purposes beyond network optimization, from the option to introduce green bil ling and charging schemes to the ability to raise carbon awareness by end users. | <t>Similarly, how can the carbon cost of a flow be assessed? That might serve many purposes beyond network optimization, e.g., introducing green billin g and charging schemes, and raising carbon awareness by end users. | |||
</t> | </t> | |||
<!-- CW: One key class of network that is potentially more energy intensive, but uses mostly renewable energy is that of satellite networks, and in particular L ow Earth Orbit constellations. Wireless networks are less energy efficient than fiber, as there is more signal loss and the transmitted energy is less focused towards the destination (this has to be qualified for free-space optical transmi ssion of course). Therefore transmitting a signal into space and back comes with an arguably high energy cost. However, satellites cannot be connected to a powe r grid, and therefore have the requirement to be energy independent. Solar array s provide the energy to power up the satellites, with a higher efficienty outsid e of the atmosphere. Any discussion of the "greenness" of such network should ta ke into account the energy cost of building up an infrastructure in space and ho w this energy "capital expense" is amortized over time with the lower "operating expense" of using renewable energy. --> | <!-- CW: One key class of network that is potentially more energy intens ive, but uses mostly renewable energy is that of satellite networks, and in part icular Low Earth Orbit constellations. Wireless networks are less energy effici ent than fiber, as there is more signal loss and the transmitted energy is less focused towards the destination (this has to be qualified for free-space optical transmission of course). Therefore transmitting a signal into space and back co mes with an arguably high energy cost. However, satellites cannot be connected t o a power grid, and therefore have the requirement to be energy independent. Sol ar arrays provide the energy to power up the satellites, with a higher efficient y outside of the atmosphere. Any discussion of the "greenness" of such network s hould take into account the energy cost of building up an infrastructure in spac e and how this energy "capital expense" is amortized over time with the lower "o perating expense" of using renewable energy. --> | |||
<t> | <t> | |||
The following summarizes some challenges and opportunities in this space that ca n provide the basis for advances in greener networking: | The following summarizes some challenges and opportunities in this space that ca n provide the basis for advances in greener networking: | |||
<list style="symbols"> | ||||
<t>Devise methods to assess, to estimate, to predict carbon-intensity of paths | ||||
.</t> | ||||
<t>Devise methods to account for carbon footprint of flows and networking serv | ||||
ices.</t> | ||||
</list> | ||||
</t> | </t> | |||
</section> | <ul spacing="normal"> | |||
<section title="Dimensioning and Peak Shaving"> | <li> | |||
<t> | <t>Devise methods to assess, estimate, and predict the carbon intens | |||
As mentioned in <xref target="sec:implications"/>, the overall energy usage of a | ity of paths.</t> | |||
network is in large part determined by how the network is dimensioned, specific | </li> | |||
ally: which and how many pieces of network equipment are deployed and turned on. | <li> | |||
A significant portion of energy is drawn even when simply in idle state. Minim | <t>Devise methods to account for the carbon footprint of flows and n | |||
izing the amount of equipment that needs to be turned on in the first place pres | etworking services.</t> | |||
ents hence one of the biggest energy saving opportunities. | </li> | |||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>Dimensioning and Peak Shaving</name> | ||||
<t> | ||||
As mentioned in <xref target="sec_implications"/>, the overall energy usage of a | ||||
network is in large part determined by how the network is dimensioned, specific | ||||
ally: which and how many pieces of network equipment are deployed and turned on. | ||||
A significant portion of energy is drawn even when simply in idle state. Hence | ||||
, minimizing the amount of equipment that needs to be turned on in the first pla | ||||
ce presents one of the biggest energy-saving opportunities. | ||||
</t> | </t> | |||
<t> | <t> | |||
Network deployments are generally dimensioned for periods of peak traffic, resul | Network deployments are generally dimensioned for periods of peak traffic, resul | |||
ting in excess capacity during periods of non-peak usage that nonetheless consum | ting in excess capacity during periods of non-peak usage that nonetheless consum | |||
es power. Shaving peak usage may thus result in outsized sustainability gains, | es power. Shaving peak usage may thus result in outsized sustainability gains, | |||
as it reduces not only energy usage during peak traffic, but more importantly wa | as it reduces energy usage during peak traffic but, more importantly, waste duri | |||
ste during non-peak periods. | ng non-peak periods. | |||
</t> | </t> | |||
<t>While traffic volume is largely a function of demand traffic that network pro viders have little influence over, some peak shaving cand nevertheless be accomp lished by techniques such as spreading spikes out over geographies (e.g. redirec ting some traffic across more costly but less utilized routes, particular in cas es when traffic spikes are of a more local or reginal nature) or over time (e.g. postponing non-urgent traffic, storing or buffering using edge clouds or extra storage where feasible). | <t>While traffic volume is largely a function of demand traffic that net work providers have little influence over, some peak shaving can nevertheless be accomplished by techniques such as spreading spikes out over geographies (e.g., redirecting some traffic across more costly but less utilized routes, particula rly in cases when traffic spikes are of a more local or regional nature) or over time (e.g., postponing non-urgent traffic, storing or buffering using edge clou ds or extra storage where feasible). | |||
</t> | </t> | |||
<t>To make techniques effective, accurate learning and prediction of traffic pat terns is required. This includes the ability to perform forecasting to ensure th at additional resources can be spun up in time should it be needed. Clearly, th is presents interesting challenges, yet also opportunities for technical advance s to make a difference. | <t>To make techniques effective, accurate learning and prediction of tra ffic patterns are required. This includes the ability to perform forecasting to ensure that additional resources can be spun up in time should they be needed. Clearly, this presents interesting challenges, yet also opportunities for techni cal advances to make a difference. | |||
</t> | </t> | |||
<t> | <t> | |||
The following summarizes some challenges and opportunities in this space that ca n provide the basis for advances in greener networking: | The following summarizes some challenges and opportunities in this space that ca n provide the basis for advances in greener networking: | |||
<list style="symbols"> | ||||
<t>Support for methods that allow to monitor and forecast traffic demand, invo | ||||
lving new mechanisms and/or performance improvements of existing mechanisms to s | ||||
upport the collection of telemetry and generation of traffic matrices at very hi | ||||
gh velocity and scale </t> | ||||
<t>Additional methods that allow for even traffic load distribution across the | ||||
network, i.e. load balancing on a network scale, and enablement of those method | ||||
s through control protocol extensions as needed.</t> | ||||
</list> | ||||
</t> | </t> | |||
<ul spacing="normal"> | ||||
</section> | <li> | |||
<section title="Convergence Schemes"> | <t>Support methods for monitoring and forecasting traffic demand, in | |||
<t> | volving new mechanisms and/or performance improvements of existing mechanisms to | |||
One set of challenges of carbon-aware networking concerns the fact that many sch | support the collection of telemetry and generation of traffic matrices at very | |||
emes result in much greater dynamicity and continuous change in the network as r | high velocity and scale.</t> | |||
esources may be getting steered away from (when possible) and then leveraged aga | </li> | |||
in (when necessary) in rapid succession. This imposes significant stress on con | <li> | |||
vergence schemes that results in challenges to the scalability of solutions and | <t>Additional methods for distributing traffic load evenly across th | |||
their ability to perform in a fast-enough manner. Network-wide convergence impos | e network, i.e., load balancing on a network scale, and enablement of those meth | |||
es high cost and incurs significant delay and is hence not susceptible to such s | ods through control protocol extensions as needed.</t> | |||
chemes. In order to mitigate this problem, mechanisms should be investigated tha | </li> | |||
t do not require convergence beyond the vicinity of the affected network device. | </ul> | |||
Especially in cases where central network controllers are involved that are re | </section> | |||
sponsible for aspects such as configuration of paths and the positioning of netw | <section> | |||
ork functions and that aim for global optimization, the impact of churn needs to | <name>Convergence Schemes</name> | |||
be minimized. This means that, for example, (re-) discovery and update schemes | <t> | |||
need to be simplified and extensive recalculation e.g., of routes and paths bas | One set of challenges of carbon-aware networking concerns the fact that many sch | |||
ed on the current energy state of the network needs to be avoided. | emes result in much greater dynamicity and continuous change in the network, as | |||
resources may be steered away from (when possible) and then leveraged again (whe | ||||
n necessary) in rapid succession. This imposes significant stress on convergenc | ||||
e schemes that results in challenges to the scalability of solutions and their a | ||||
bility to perform in a fast-enough manner. Network-wide convergence imposes high | ||||
cost and incurs significant delay and thus is not susceptible to such schemes. | ||||
In order to mitigate this problem, mechanisms should be investigated that do not | ||||
require convergence beyond the vicinity of the affected network device. The im | ||||
pact of churn needs to be minimized, especially in cases where central network c | ||||
ontrollers (responsible for the configuration of paths and the positioning of ne | ||||
twork functions and that aim for global optimization) are involved. This means | ||||
that, for example, discovery, rediscovery, and update schemes need to be simplif | ||||
ied, and extensive recalculation (e.g., of routes and paths based on the current | ||||
energy state of the network) needs to be avoided. | ||||
</t> | </t> | |||
<t>The following summarizes some challenges and opportunities in this space that | <t>The following summarizes some challenges and opportunities in this sp | |||
can provide the basis for advances in greener networking: | ace that can provide the basis for advances in greener networking: | |||
<list style="symbols"> | ||||
<t>Protocols that facilitate rapid convergence (per <xref target="NetworkEne | ||||
rgySaving"/>).</t> | ||||
<t>Investigate methods that mitigate effects of churn, including methods tha | ||||
t maintain memory or state as well as methods relying on prediction, inference, | ||||
and interpolation.</t> | ||||
</list> | ||||
</t> | </t> | |||
</section> | <ul spacing="normal"> | |||
<li> | ||||
<!-- Alex, feel free to comment out this following section, we can talk more abo | <t>Protocols that facilitate rapid convergence (per <xref target="Ne | |||
ut it. --> | tworkEnergySaving"/>).</t> | |||
</li> | ||||
<li> | ||||
<t>Investigate methods that mitigate effects of churn, including met | ||||
hods that maintain memory or state as well as methods relying on prediction, inf | ||||
erence, and interpolation.</t> | ||||
</li> | ||||
</ul> | ||||
</section> | ||||
<!-- Alex, feel free to comment out this following section, we can talk mo | ||||
re about it. --> | ||||
<section title="The Role of Topology"> | <section> | |||
<t> | <name>The Role of Topology</name> | |||
One of the most important network management constructs is that of the n | <t> | |||
etwork topology. A network topology can usually be represented as a database or | One of the most important network management constructs is that of the n | |||
as a mathematical graph, with vertices or nodes, edges or links, representing ne | etwork topology. A network topology can usually be represented as a database or | |||
tworking nodes, links connecting their interfaces, and all their characteristics | as a mathematical graph, with vertices or nodes, edges or links, representing ne | |||
. Examples of these network topology representations include routing protocols l | tworking nodes, links connecting their interfaces, and all their characteristics | |||
ink-state databases, and service function chaining graphs. | . Examples of these network topology representations include routing protocols' | |||
</t> | link-state databases (LSDBs) and service function chaining graphs. | |||
<t> | ||||
As we desire to add carbon and energy awareness into networks, the energ | ||||
y proportionality of topologies directly supports sustainability visibility and | ||||
improvements via automation. | ||||
</t> | ||||
<t> | ||||
The following summarizes some challenges and opportunities in this space that ca | ||||
n provide the basis for advances in greener networking: | ||||
<list style="symbols"> | ||||
<t>Embedding carbon and energy awareness into the representation of topo | ||||
logies, whether considering IGP LSDBs (link-state databases) and their advertise | ||||
ments, BGP-LS (BGP Link-State), or metadata for the rendering of service functio | ||||
n paths in a service chain.</t> | ||||
<t>Use of those carbon-aware attributes to optimize topology as a whole | ||||
under end-to-end energy and carbon considerations. | ||||
</t> | </t> | |||
</list> | <!--[rfced] The term "sustainability visibility" reads oddly. | |||
</t> | Please review if the updated sentence conveys the intended meaning. | |||
</section> | The phrase "visibility into energy consumption" (a concept from Section 4) | |||
has been used. | ||||
</section> | Original: | |||
As we desire to add carbon and energy awareness into networks, the | ||||
energy proportionality of topologies directly supports sustainability | ||||
visibility and improvements via automation. | ||||
<section title="Challenges and Opportunities - Architecture Level" anchor="sec:a | Current: | |||
rchi"> | To add carbon and energy awareness into networks, the | |||
<t> | energy proportionality of topologies directly supports | |||
Another possibility to improve network energy efficiency is to organize networks | visibility into energy consumption and improvements via automation. | |||
in a way that they allow important applications to reduce energy consumption. E | --> | |||
xamples include facilitating retrieval of content or performing computation in w | <t> | |||
ays that minimize the amount of communication that needs to take place in the fi | To add carbon and energy awareness into networks, the | |||
rst place, even if energy savings within the network may at least in part be off | energy proportionality of topologies directly supports | |||
set by additional energy consumption elsewhere. The following are some examples | visibility into energy consumption and improvements via automation. | |||
that suggest that it may be worthwhile reconsidering the ways in which networks | </t> | |||
are architected to minimize their carbon footprint. | <t> | |||
The following summarizes some challenges and opportunities in this space that ca | ||||
n provide the basis for advances in greener networking: | ||||
</t> | ||||
<ul spacing="normal"> | ||||
<li> | ||||
<t>Embedding carbon and energy awareness into the representation of | ||||
topologies, whether considering IGP LSDBs and their advertisements, BGP-LS (BGP | ||||
Link-State), or metadata for the rendering of service function paths in a servic | ||||
e chain.</t> | ||||
</li> | ||||
<li> | ||||
<t>Use of those carbon-aware attributes to optimize topology as a wh | ||||
ole under end-to-end energy and carbon considerations. | ||||
</t> | ||||
</li> | ||||
</ul> | ||||
</section> | ||||
</section> | ||||
<section anchor="sec_archi"> | ||||
<name>Challenges and Opportunities - Architecture Level</name> | ||||
<t> | ||||
Another possibility to improve network energy efficiency is to organize networks | ||||
in a way that they allow important applications to reduce energy consumption. E | ||||
xamples include facilitating retrieval of content or performing computation in w | ||||
ays that minimize the amount of communication needed in the first place, even if | ||||
energy savings within the network may be offset (at least in part) by additiona | ||||
l energy consumption elsewhere. The following examples suggest that it may be wo | ||||
rthwhile to reconsider the ways in which networks are architected to minimize th | ||||
eir carbon footprint. | ||||
</t> | </t> | |||
<t> | <t> | |||
For example, Content Delivery Networks (CDNs) have reduced the energy expenditur | For example, Content Delivery Networks (CDNs) have reduced the energy expenditur | |||
e of the Internet by downloading content near the users. The content is sent onl | e of the Internet by downloading content near the users. The content is sent onl | |||
y a few times over the WAN, and then is served locally. This shifts the energy c | y a few times over the WAN and then is served locally. This shifts the energy co | |||
onsumption from networking to storage. Further methods can reduce the energy usa | nsumption from networking to storage. Further methods can reduce the energy usag | |||
ge even more <xref target="Bianco2016energy"/> <xref target="Mathew2011energy"/> | e even more <xref target="Bianco2016energy"/> <xref target="Mathew2011energy"/> | |||
<xref target="Islam2012evaluating"/>. Whether overall energy savings are net po | <xref target="Islam2012evaluating"/>. Whether overall energy savings are net pos | |||
sitive depends on the actual deployment, but from the network operator's perspec | itive depends on the actual deployment, but from the network operator's perspect | |||
tive, at least it shifts the energy bill away from the network to the CDN operat | ive, at least it shifts the energy bill away from the network to the CDN operato | |||
or. | r. | |||
</t> | </t> | |||
<t> | <t> | |||
While CDNs operate as an overlay, another architecture has been proposed to prov | While CDNs operate as an overlay, another architecture has been proposed to prov | |||
ide the CDN features directly in the network, namely Information Centric Network | ide the CDN features directly in the network -- namely, Information-Centric Netw | |||
s <xref target="Ahlgren2012survey"/>, studied as well in the IRTF ICNRG. This ho | orks <xref target="Ahlgren2012survey"/>, also studied in the ICNRG of the IRTF. | |||
wever shifts the energy consumption back to the network operator and requires so | However, this shifts the energy consumption back to the network operator and req | |||
me power-hungry hardware, such as chips for larger name look-ups and memory for | uires some power-hungry hardware, such as chips for larger name lookups and memo | |||
the in-network cache. As a result, it is unclear if there is an actual energy g | ry for the in-network cache. As a result, it is unclear if there is an actual e | |||
ain from the dissemination and retrieval of content within in-network caches. | nergy gain from the dissemination and retrieval of content within in-network cac | |||
hes. | ||||
</t> | </t> | |||
<t> | <t> | |||
Fog computing and placing intelligence at the edge are other architectural direc | Fog computing and placing intelligence at the edge are other architectural direc | |||
tions for reducing the amount of energy that is spent on packet forwarding and i | tions for reducing the amount of energy that is spent on packet forwarding and i | |||
n the network. There again, the trade-off is between performing computation in a | n the network. There again, the trade-off is between performing computational ta | |||
n energy-optimized data center at very large scale (but requiring transmission o | sks (a) in an energy-optimized data center at very large scale (but requiring tr | |||
f significant volumes of data across many nodes and long distances) versus perfo | ansmission of significant volumes of data across many nodes and long distances) | |||
rming computational tasks at the edge where the energy may not be used as effici | versus (b) at the edge where the energy may not be used as efficiently (less mul | |||
ently (less multiplexing of resources and inherently lower efficiency of smaller | tiplexing of resources and inherently lower efficiency of smaller sites due to t | |||
sites due to their smaller scale) but the amount of long-distance network traff | heir smaller scale) but the amount of long-distance network traffic and energy r | |||
ic and energy required for the network is significantly reduced. | equired for the network is significantly reduced. | |||
Softwarization, containers, microservices are direct enablers for such architect | <!--[rfced] FYI, this sentence has been updated as follows | |||
ures, and the deployment of programmable network infrastructure (as for instance | to clarify the phrase "help its realization". Seemingly this phrase | |||
Infrastructure Processing Units - IPUs or SmartNICs that offload some computati | refers to help the realization of such architectures. Please review. | |||
ons from the CPU onto the NIC) will help its realization. | ||||
However, the power consumption characteristics of CPUs are different from those | Original: | |||
of NPUs, another aspect to be considered in conjunction with virtualization. | Softwarization, | |||
containers, microservices are direct enablers for such architectures, | ||||
and the deployment of programmable network infrastructure (as for | ||||
instance Infrastructure Processing Units - IPUs or SmartNICs that | ||||
offload some computations from the CPU onto the NIC) will help its | ||||
realization. | ||||
Current: | ||||
Softwarization, containers, and | ||||
microservices are direct enablers of such architectures. Their | ||||
realization will be further aided by the deployment of programmable | ||||
network infrastructure, such as Infrastructure Processing Units | ||||
(IPUs) or SmartNICs that offload some computations from the CPU onto | ||||
the NIC. | ||||
--> | ||||
Softwarization, containers, and microservices are direct enablers of such archit | ||||
ectures. Their realization will be further aided by the deployment of programma | ||||
ble network infrastructure, such as Infrastructure Processing Units (IPUs) or Sm | ||||
artNICs that offload some computations from the CPU onto the NIC. | ||||
However, the power consumption characteristics of CPUs are different from those | ||||
of NPUs; this is another aspect to be considered in conjunction with virtualizat | ||||
ion. | ||||
</t> | </t> | |||
<t> | <t> | |||
Other possibilities concern taking economic aspects into consideration impact, s | Other possibilities are taking economic aspects into consideration, such as prov | |||
uch as providing incentives to users of networking services in order to minimize | iding incentives to users of networking services in order to minimize energy con | |||
energy consumption and emission impact. An example for this is given in <xref | sumption and emission impact. In <xref target="Wolf2014choicenet"/>, an example | |||
target="Wolf2014choicenet"/>, which could be expanded to include energy incentiv | is provided that could be expanded to include energy incentives. | |||
es. | ||||
</t> | </t> | |||
<t> | <t> | |||
Other approaches consider performing a late binding of data and functions to be | Other approaches consider performing a late binding of the data and the function | |||
performed on the data <xref target="Krol2017NFaaS"/>. The COIN Research Group in | s to be performed on it <xref target="Krol2017NFaaS"/>. The COINRG of the IRTF f | |||
IRTF focuses on similar issues. Jointly optimizing for the total energy cost th | ocuses on similar issues. Jointly optimizing for the total energy cost that take | |||
at takes into account networking as well as computing (along with the different | s into account networking as well as computing (along with the different energy | |||
energy cost of computing in an hyperscale DC vs at an edge node) is still an are | cost of computing in a hyperscale DC vs. at an edge node) is still an area of op | |||
a of open research. | en research. | |||
</t> | </t> | |||
<t> | <t> | |||
In summary, rethinking of the overall network (and networked application) archit | In summary, rethinking the overall network (and networked application) architect | |||
ecture can be an opportunity to significantly reduce the energy cost at the netw | ure can be an opportunity to significantly reduce the energy cost at the network | |||
ork layer, for example by performing tasks that involve massive communications c | layer, for example, by performing tasks that involve massive communications clo | |||
loser to the user. To what extend these shifts result in a net reduction of car | ser to the user. To what extent these shifts result in a net reduction of carbo | |||
bon footprint is an important question that requires further analysis on a case- | n footprint is an important question that requires further analysis on a case-by | |||
by-case basis. | -case basis. | |||
</t> | </t> | |||
<t> | <t> | |||
The following summarizes some challenges and opportunities in this space that ca n provide the basis for advances in greener networking: | The following summarizes some challenges and opportunities in this space that ca n provide the basis for advances in greener networking: | |||
<list style="symbols"> | ||||
<t>Investigate organization of networking architecture for important classes | ||||
of applications (examples: content delivery, right-placing of computational int | ||||
elligence, industrial operations and control, massively distributed machine lear | ||||
ning and AI) to optimize green foot print and holistic approaches to trade off c | ||||
arbon footprint between forwarding, storage, and computation.</t> | ||||
<t>Models to assess and compare alternatives in providing networked services | ||||
, e.g., evaluate carbon impact relative to alternatives where to perform compute | ||||
, what information to cache, and what communication exchanges to conduct.</t> | ||||
</list> | ||||
</t> | </t> | |||
</section> | <ul spacing="normal"> | |||
<li> | ||||
<!--[rfced] "green footprint" (one instance) | ||||
You might want to consider a different term. | ||||
<section title="Conclusions"> | Original: | |||
<t> How to make networks "greener" and reduce their carbon footprint is an impor | * Investigate organization of networking architecture for important | |||
tant problem for the networking industry to address, both for societal and for e | classes of applications (examples: content delivery, right-placing | |||
conomic reasons. This document has highlighted a number of the technical challen | of computational intelligence, industrial operations and control, | |||
ges and opportunities in that regard. | massively distributed machine learning and AI) to optimize green | |||
</t> | foot print and holistic approaches to trade off carbon footprint | |||
<t> | between forwarding, storage, and computation. | |||
Of those, perhaps the key challenge to address right away concerns the ability t | --> | |||
o expose at a fine granularity the energy impact of any networking actions. Prov | <t>Investigate organization of networking architecture for important c | |||
iding visibility into this will enable many approaches to come towards a solutio | lasses of applications (e.g., content delivery, right-placing of computational i | |||
n. It will be key to implementing optimization via control loops that allow to a | ntelligence, industrial operations and control, massively distributed ML and AI) | |||
ssess the energy impact of decision taken. It will also help to answer question | to optimize green footprint and holistic approaches to trade-offs of carbon foo | |||
s such as: is caching - with the associated storage energy - better than retrans | tprint with forwarding, storage, and computation.</t> | |||
mitting from a different server - with the associated networking cost? Is compre | </li> | |||
ssion more energy-efficient once factoring the computation cost of compression v | <li> | |||
s transmitting uncompressed data? Which compression scheme is more energy effici | <t>Models to assess and compare alternatives in providing networked se | |||
ent? Is energy saving of computing at an efficient hyperscale DC compensated by | rvices, e.g., evaluate carbon impact relative to where to perform computation, w | |||
the networking cost to reach that DC? Is the overhead of gathering and transmitt | hat information to cache, and what communication exchanges to conduct.</t> | |||
ing fine-grained energy telemetry data offset by the total energy gain by ways o | </li> | |||
f better decisions that this data enables? Is transmitting data to a Low Earth O | </ul> | |||
rbit (LEO) satellite constellation compensated by the fact that once in the cons | </section> | |||
tellation, the networking is fueled by solar energy? Is the energy cost of sendi | <section> | |||
ng rockets to place routers in Low Earth Orbit amortized over time? | <name>Conclusions</name> | |||
</t> | <t> How to make networks "greener" and reduce their carbon footprint is an | |||
<t> | important problem for the networking industry to address, both for societal and | |||
Determining where the sweet spots are and optimizing networks along those lines | for economic reasons. This document has highlighted a number of the technical c | |||
will be a key towards making networks "greener". We expect to see significant ad | hallenges and opportunities in that regard. | |||
vances across these areas and believe that researchers, developers, and operator | ||||
s of networking technology have an important role to play in this. | ||||
</t> | </t> | |||
</section> | <!--[rfced] Section 8: FYI, we have formatted this list of questions as | |||
a bulleted list. Please let us know if you prefer otherwise. | ||||
<section title="IANA Considerations"> | Current: | |||
<t>This document does not have any IANA requests. </t> | It will also help to answer questions such as: | |||
</section> | ||||
<section title="Security Considerations"> | * Is caching (with the associated storage) better than | |||
retransmitting from a different server (with the associated | ||||
networking cost)? | ||||
* Is compression more energy efficient once factoring in the | ||||
computation cost of compression vs. transmitting uncompressed | ||||
data? | ||||
* Which compression scheme is more energy efficient? | ||||
* Is energy saving of computing at an efficient hyperscale DC | ||||
compensated by the networking cost to reach that DC? | ||||
* Is the overhead of gathering and transmitting fine-grained energy | ||||
telemetry data offset by the total energy gain resulting from the | ||||
better decisions that this data enables? | ||||
* Is transmitting data to a Low Earth Orbit (LEO) satellite | ||||
constellation compensated by the fact that once in the | ||||
constellation, the networking is fueled by solar energy? | ||||
* Is the energy cost of sending rockets to place routers in LEO | ||||
amortized over time? | ||||
--> | ||||
<t> | ||||
Of those, perhaps the key challenge to address right away is the ability to expo | ||||
se at a fine granularity the energy impact of any networking actions. Providing | ||||
visibility into this will enable many approaches to come towards a solution. It | ||||
will be key to implementing optimization via control loops that can assess the e | ||||
nergy impact of a decision taken. It will also help to answer questions such as | ||||
:</t> | ||||
<ul spacing="compact"> | ||||
<li>Is caching (with the associated storage) better than retransmitting from a | ||||
different server (with the associated networking cost)?</li> | ||||
<li>Is compression more energy efficient once factoring in the computation cos | ||||
t of compression vs. transmitting uncompressed data?</li> | ||||
<li>Which compression scheme is more energy efficient?</li> | ||||
<li>Is energy saving of computing at an efficient hyperscale DC compensated by | ||||
the networking cost to reach that DC?</li> | ||||
<li>Is the overhead of gathering and transmitting fine-grained energy telemetr | ||||
y data offset by the total energy gain resulting from the better decisions that | ||||
this data enables?</li> | ||||
<!--[rfced] In order to clarify the phrase "by the fact that once in | ||||
the constellation", please consider whether the updated text conveys | ||||
the intended meaning. | ||||
<t>Security considerations may appear to be orthogonal to green networking consi | Original: | |||
derations. However, there are a number of important caveats. | Is transmitting data to a Low Earth Orbit (LEO) satellite | |||
constellation compensated by the fact that once in the | ||||
constellation, the networking is fueled by solar energy? | ||||
Perhaps: | ||||
* Is the energy cost of transmitting data to a Low Earth Orbit | ||||
(LEO) satellite constellation offset by the networking of | ||||
that constellation being powered by solar energy? | ||||
Or: | ||||
* Does the energy saved by a Low Earth Orbit (LEO) satellite | ||||
constellation, which is powered by solar energy, offset the | ||||
energy required to transmit data to it? | ||||
--> | ||||
<li>Is transmitting data to a Low Earth Orbit (LEO) satellite constellation co | ||||
mpensated by the fact that once in the constellation, the networking is fueled b | ||||
y solar energy?</li> | ||||
<li>Is the energy cost of sending rockets to place routers in LEO amortized ov | ||||
er time?</li> | ||||
</ul> | ||||
<t> | ||||
Determining where the sweet spots are and optimizing networks along those lines | ||||
will be a key towards making networks "greener". We expect to see significant ad | ||||
vances across these areas and believe that researchers, developers, and operator | ||||
s of networking technology have an important role to play in this. | ||||
</t> | </t> | |||
<t>Security vulnerabilities of networks may manifest themselves in compromised e | </section> | |||
nergy efficiency. For example, attackers could aim at increasing energy consump | <section> | |||
tion to drive up attack victims' energy bill. Specific vulnerabilities will dep | <name>IANA Considerations</name> | |||
end on the particular mechanisms. For example, in the case of monitoring energy | <t>This document has no IANA actions.</t> | |||
consumption data, tampering with such data might result in compromised energy o | </section> | |||
ptimization control loops. Hence any mechanisms to instrument and monitor the ne | <section> | |||
twork for such data need to be properly secured to ensure authenticity. | <name>Security Considerations</name> | |||
<t>Security considerations may appear to be orthogonal to green networking | ||||
considerations. However, there are a number of important caveats. | ||||
</t> | </t> | |||
<t>In some cases, there are inherent tradeoffs between security and maximal ener gy efficiency that might otherwise be achieved. An example is encryption, which requires additional computation for encryption and decryption activities and se curity handshakes, in addition to the need to send more traffic than necessitate d by the entropy of the actual data stream. Likewise, mechanisms that allow to turn resources on or off could become a target for attackers. | <t>Security vulnerabilities of networks may manifest themselves in comprom ised energy efficiency. For example, attackers could aim at increasing energy c onsumption to drive up attack victims' energy bills. Specific vulnerabilities w ill depend on the particular mechanisms. For example, in the case of monitoring energy consumption data, tampering with such data might result in compromised e nergy optimization control loops. Hence, any mechanisms to instrument and monito r the network for such data need to be properly secured to ensure authenticity. | |||
</t> | </t> | |||
<t>Energy consumption can be used to create covert channels, which is a security risk for information leakage. For instance, the temperature of an element can b e used to create a Thermal Covert Channel <xref target="TCC"/>, or the reading/s haring of the measured energy consumption can be abused to create a covert chann el (see for instance <xref target="DRAM"/> or <xref target="NewClass"/>). Power information may be used to create side-channel attacks. For instance, <xref targ et="SideChannel"/> provides a review of 20 years of study on this topic. Any new parameters considered in protocol designs or in measurements are susceptible to create such covert or side channel and this should be taken into account while designing energy efficient protocols. | <t>In some cases, there are inherent trade-offs between security and maxim al energy efficiency that might otherwise be achieved. An example is encryption , which requires additional computation for encryption and decryption activities and security handshakes, in addition to the need to send more traffic than nece ssitated by the entropy of the actual data stream. Likewise, mechanisms that al low to turn resources on or off could become a target for attackers. | |||
</t> | </t> | |||
</section> | <t>Energy consumption can be used to create covert channels, which is a se | |||
curity risk for information leakage. For instance, the temperature of an element | ||||
can be used to create a Thermal Covert Channel <xref target="TCC"/>, or the rea | ||||
ding/sharing of the measured energy consumption can be abused to create a covert | ||||
channel (see for instance <xref target="DRAM"/> or <xref target="NewClass"/>). | ||||
Power information may be used to create side-channel attacks. For instance, <xre | ||||
f target="SideChannel"/> provides a review of 20 years of study on this topic. A | ||||
ny new parameters considered in protocol designs or in measurements are suscepti | ||||
ble to create such covert or side channels, and this should be taken into accoun | ||||
t while designing energy-efficient protocols. | ||||
</t> | ||||
</section> | ||||
<section title="Contributors"> | </middle> | |||
<t> | <back> | |||
<list> | <displayreference target="I-D.ietf-tvr-requirements" to="TVR_REQS" /> | |||
<t>Michael Welzl, University of Oslo, michawe@ifi.uio.no</t> | <displayreference target="I-D.cx-green-green-metrics" to="GREEN_METRICS"/> | |||
</list> | <displayreference target="I-D.li-green-power" to="POWER_YANG"/> | |||
</t> | ||||
</section> | ||||
<section title="Acknowledgments"> | <references> | |||
<t> | ||||
The authors thank Dave Oran for providing the information regarding covert chann | ||||
els using energy measurements, and Mike King for an exceptionally thorough revie | ||||
w and useful comments. | ||||
</t> | ||||
</section> | ||||
</middle> | ||||
<back> | <!-- [rfced] Informative reference RFC 2481 has been obsoleted by | |||
RFC 3168. We recommend replacing RFC 2481 with RFC 3168; is that | ||||
acceptable? It is cited only once in the original: | ||||
<references title="Informative References"> | ECN [RFC2481] is a possible solution, however, it is not widely deployed. | |||
&RFC.2481; | --> | |||
&RFC.3031; | ||||
&RFC.3095; | ||||
&RFC.7950; | ||||
&RFC.8402; | ||||
&RFC.9330; | ||||
<reference anchor="I.D.draft-cx-green-green-metrics"> | <!-- [rfced] FYI - We have updated the following references to include DOIs | |||
<front> | and added URLs. Please let us know if you have any objections or | |||
<title>Green Networking Metrics</title> | clarifications. | |||
<author fullname="Alexander Clemm"></author> | ||||
<author fullname="Carlos Pignataro"></author> | ||||
<author fullname="Eve Schooler"></author> | ||||
<author fullname="Laurent Ciavaglia"></author> | ||||
<author fullname="Ali Rezaki"></author> | ||||
<author fullname="Greg Mirsky"></author> | ||||
<author fullname="Jeff Tantsura"></author> | ||||
<date month="October" year="2024"/> | ||||
</front> | ||||
</reference> | ||||
<reference anchor="I.D.draft-li-green-power"> | [Ahlgren2012survey] | |||
<front> | [Alizadeh2010DCTCP] | |||
<title>A YANG model for Power Management</title> | [Bianco2016energy] | |||
<author fullname="Tony Li"></author> | [Bolla2011energy] | |||
<author fullname="Ron Bonica"></author> | [Chabarek08] | |||
<date month="October" year="2024"/> | [DRAM] | |||
</front> | [Emergy] | |||
</reference> | [Framework] | |||
[GreenNet22] | ||||
[Herzen2011PIE] | ||||
[Islam2012evaluating] | ||||
[Junkyard] | ||||
[Krol2017NFaaS] | ||||
[Mathew2011energy] | ||||
[NewClass] | ||||
[QUAL] | ||||
[Ren2018jordan] | ||||
[SideChannel] | ||||
[TCC] | ||||
[TradeOff] | ||||
[Westphal2021qualitative] | ||||
[Wolf2014choicenet] | ||||
--> | ||||
<reference anchor="I.D.draft-ietf-tvr-requirements"> | <name>Informative References</name> | |||
<front> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.248 | |||
<title>TVR (Time-Variant Routing) Requirements</title> | 1.xml"/> | |||
<author fullname="Daniel King"></author> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.303 | |||
<author fullname="Luis Contreras"></author> | 1.xml"/> | |||
<author fullname="Brian Sipos"></author> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.309 | |||
<author fullname="L. Zhang"></author> | 5.xml"/> | |||
<date month="September" year="2024"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.795 | |||
</front> | 0.xml"/> | |||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.840 | ||||
2.xml"/> | ||||
<xi:include | ||||
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9330.xml"/> | ||||
<!-- [I-D.cx-green-green-metrics] IESG State: Expired as of 06/27/25--> | ||||
<reference anchor="I-D.cx-green-green-metrics" target="https://datatracker.ietf. | ||||
org/doc/html/draft-cx-green-green-metrics-00"> | ||||
<front> | ||||
<title>Green Networking Metrics for Environmentally Sustainable Networking | ||||
</title> | ||||
<author initials="A." surname="Clemm" fullname="Alexander Clemm" role="edi | ||||
tor"> | ||||
<organization>Santa Clara University</organization> | ||||
</author> | ||||
<author initials="C." surname="Pignataro" fullname="Carlos Pignataro" role | ||||
="editor"> | ||||
<organization>North Carolina State University</organization> | ||||
</author> | ||||
<author initials="E." surname="Schooler" fullname="Eve Schooler"> | ||||
<organization>University of Oxford</organization> | ||||
</author> | ||||
<author initials="L." surname="Ciavaglia" fullname="Laurent Ciavaglia"> | ||||
<organization>Nokia</organization> | ||||
</author> | ||||
<author initials="A." surname="Rezaki" fullname="Ali Rezaki"> | ||||
<organization>Nokia</organization> | ||||
</author> | ||||
<author initials="G." surname="Mirsky" fullname="Greg Mirsky"> | ||||
<organization>Ericsson</organization> | ||||
</author> | ||||
<author initials="J." surname="Tantsura" fullname="Jeff Tantsura"> | ||||
<organization>Nvidia</organization> | ||||
</author> | ||||
<date month="October" day="21" year="2024" /> | ||||
</front> | ||||
<seriesInfo name="Internet-Draft" value="draft-cx-green-green-metrics-00" /> | ||||
</reference> | ||||
<!-- [I-D.li-green-power] IESG State: Expired as of 06/27/25--> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.li | ||||
-green-power.xml"/> | ||||
<!-- [I-D.ietf-tvr-requirements] IESG State: I-D Exists as of 06/27/25--> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ie | ||||
tf-tvr-requirements.xml"/> | ||||
<!-- [rfced] We found the following URL for [Telefonica2021]; | ||||
would you like to add it or a different URL to this reference? | ||||
https://www.telefonica.com/en/shareholders-investors/financial-reports/historica | ||||
l-archive-annual-reports/2021/ | ||||
Current: | ||||
[Telefonica2021] | ||||
Telefonica, "Telefonica Consolidated Annual Report 2021", | ||||
2021. | ||||
--> | ||||
</reference> | ||||
<reference anchor="Telefonica2021"> | <reference anchor="Telefonica2021"> | |||
<front> | <front> | |||
<title>Telefonica Consolidated Annual Report 2021.</title> | <title>Telefonica Consolidated Annual Report 2021</title> | |||
<author fullname="Telefonica"> </author> | <author> | |||
<organization>Telefonica</organization> | ||||
</author> | ||||
<date year="2021"/> | <date year="2021"/> | |||
</front> | </front> | |||
</reference> | </reference> | |||
<reference anchor="GreenNet22"> | <reference anchor="GreenNet22"> | |||
<front> | <front> | |||
<title>Challenges and Opportunities in Green Networking</title> | <title>Challenges and Opportunities in Green Networking</title> | |||
<author fullname="Alexander Clemm"> </author> | <author fullname="Alexander Clemm"> </author> | |||
<author fullname="Cedric Westphal"></author> | <author fullname="Cedric Westphal"/> | |||
<date month="June" year="2022" /> | <date month="June" year="2022"/> | |||
</front> | </front> | |||
<seriesInfo | <seriesInfo name="DOI" value="10.1109/NetSoft54395.2022.9844020"/> | |||
name="1st International Workshop on Network Energy Efficiency in | <refcontent>1st International Workshop on Network Energy Efficiency in t | |||
the Softwarization Era" value="IEEE NetSoft 2022"/> | he Softwarization Era, IEEE NetSoft 2022</refcontent> | |||
</reference> | ||||
</reference> | ||||
<reference anchor="Bolla2011energy"> | <reference anchor="Bolla2011energy"> | |||
<front> | <front> | |||
<title>Energy Efficiency in the Future Internet: A Survey of Existing Approa | <title>Energy Efficiency in the Future Internet: A Survey of Existing | |||
ches and Trends in Energy-Aware Fixed Network Infrastructures</title> | Approaches and Trends in Energy-Aware Fixed Network Infrastructures</title> | |||
<author fullname="Raffaele Bolla"> </author> | <author fullname="Raffaele Bolla"> </author> | |||
<author fullname="Roberto Bruschi"> </author> | <author fullname="Roberto Bruschi"> </author> | |||
<author fullname="Franco Davoli"> </author> | <author fullname="Franco Davoli"> </author> | |||
<author fullname="Flavio Cucchietti"> </author> | <author fullname="Flavio Cucchietti"> </author> | |||
<date year="2011" /> | <date year="2011"/> | |||
</front> | </front> | |||
<seriesInfo name="IEEE Communications Surveys and Tutorials" value="Vol.13 N | <refcontent>IEEE Communications Surveys and Tutorials, vol. 13, no. 2, p | |||
o.2, pp.223-244"/> | p. 223-244</refcontent> | |||
<seriesInfo name="DOI" value="10.1109/SURV.2011.071410.00073"/> | ||||
</reference> | ||||
</reference> | <reference anchor="Chabarek08"> | |||
<front> | ||||
<title>Power Awareness in Network Design and Routing</title> | ||||
<author fullname="J. Chabarek"/> | ||||
<author fullname="J. Sommers"/> | ||||
<author fullname="P. Barford"/> | ||||
<author fullname="C. Estan"/> | ||||
<author fullname="D. Tsiang"/> | ||||
<author fullname="S. Wright"/> | ||||
<date year="2008"/> | ||||
</front> | ||||
<refcontent>IEEE INFOCOM 2008 - The 27th Conference on Computer Communic | ||||
ations, pp. 457-465</refcontent> | ||||
<seriesInfo name="DOI" value="10.1109/INFOCOM.2008.93"/> | ||||
</reference> | ||||
<reference anchor="Chabarek08"> | <!-- [rfced] FYI, for [Cervero19], we updated the year from 2019 to | |||
<front> | 2015 to match the year found at the DOI. Please let us know if that | |||
<title>Power awareness in network design and routing</title> | is not accurate. | |||
<author fullname="J. Chabarek"></author> | ||||
<author fullname="J. Sommers"></author> | ||||
<author fullname="P. Barford"></author> | ||||
<author fullname="D. Tsiang"></author> | ||||
<author fullname="S. Wright"></author> | ||||
<date year="2008"/> | ||||
</front> | ||||
<seriesInfo name="IEEE Infocom" value="pp.457-465"/> | ||||
</reference> | Current: | |||
[Cervero15] | ||||
Cervero, A. G., Chincoli, M., Dittmann, L., Fischer, A., | ||||
Garcia, A., Galán-Jiménez, J., Lefevre, L., Meer, H. D., | ||||
Monteil, T., Monti, P., Orgerie, A., Pau, L., Phillips, | ||||
C., Ricciardi, S., Sharrock, R., Stolf, P., Trinh, T., and | ||||
L. Valcarenghi, "Green Wired Networks", Large-Scale | ||||
Distributed Systems and Energy Efficiency, pp. 41-80, | ||||
DOI 10.1002/9781118981122.ch3, 2015, | ||||
<https://doi.org/10.1002/9781118981122.ch3>. | ||||
--> | ||||
<reference anchor="Cervero19"> | <reference anchor="Cervero15"> | |||
<front> | <front> | |||
<title>Green Wired Networks</title> | <title>Green Wired Networks</title> | |||
<author fullname="Alfonso Gazo Cervero"></author> | <author fullname="Alfonso Gazo Cervero"/> | |||
<author fullname="Michele Chincoli"></author> | <author fullname="Michele Chincoli"/> | |||
<author fullname="Lars Dittmann"></author> | <author fullname="Lars Dittmann"/> | |||
<author fullname="Andreas Fischer"></author> | <author fullname="Andreas Fischer"/> | |||
<author fullname="Alberto Garcia"></author> | <author fullname="Alberto Garcia"/> | |||
<date year="2019"/> | <author fullname="Jaime Galán-Jiménez"/> | |||
</front> | <author fullname="Laurent Lefevre"/> | |||
<seriesInfo name="Wiley Journal on Large-Scale Distributed Systems and En | <author fullname="Hermann de Meer"/> | |||
ergy Efficiency" value="pp.41-80"/> | <author fullname="Thierry Monteil"/> | |||
<author fullname="Paolo Monti"/> | ||||
<author fullname="Anne-Cecile Orgerie"/> | ||||
<author fullname="Louis-Francois Pau"/> | ||||
<author fullname="Chris Phillips"/> | ||||
<author fullname="Sergio Ricciardi"/> | ||||
<author fullname="Remi Sharrock"/> | ||||
<author fullname="Patricia Stolf"/> | ||||
<author fullname="Tuan Trinh"/> | ||||
<author fullname="Luca Valcarenghi"/> | ||||
<date year="2015"/> | ||||
</front> | ||||
<refcontent>Large-Scale Distributed Systems and Energy Efficiency, pp. 4 | ||||
1-80</refcontent> | ||||
<seriesInfo name="DOI" value="10.1002/9781118981122.ch3"/> | ||||
</reference> | ||||
</reference> | <reference anchor="Alizadeh2010DCTCP"> | |||
<front> | ||||
<title>Data Center TCP (DCTCP) </title> | ||||
<author fullname="Mohammad Alizadeh"/> | ||||
<author fullname="Albert Greenberg"/> | ||||
<author fullname="David Maltz"/> | ||||
<author fullname="Jitendra Padhye"/> | ||||
<author fullname="Parveen Patel"/> | ||||
<author fullname="Balaji Prabhakar"/> | ||||
<author fullname="Sudipta Sengupta"/> | ||||
<author fullname="Murari Sridharan"/> | ||||
<date year="2010"/> | ||||
</front> | ||||
<refcontent>ACM SIGCOMM Computer Communication Review, vol. 40, no. 4, p | ||||
p. 63-74</refcontent> | ||||
<seriesInfo name="DOI" value="10.1145/1851275.1851192"/> | ||||
</reference> | ||||
<reference anchor="Alizadeh2010DCTCP"> | <reference anchor="QUAL"> | |||
<front> | <front> | |||
<title>Data Center TCP (DCTCP) </title> | <title>A Framework for Qualitative Communications using Big Packet Pro | |||
<author fullname="Mohammad Alizadeh"></author> | tocol</title> | |||
<author fullname="Albert Greenberg"></author> | <author fullname="Richard Li"/> | |||
<author fullname="David Maltz"></author> | <author fullname="Kiran Makhijani"/> | |||
<author fullname="Jitendra Padhye"></author> | <author fullname="Hamed Yousefi"/> | |||
<author fullname="Parveen Patel"></author> | <author fullname="Cedric Westphal"/> | |||
<author fullname="Balaji Prabhakar"></author> | <author fullname="Lijun Xong"/> | |||
<author fullname="Sudipta Sengupta"></author> | <author fullname="Tim Wauters"/> | |||
<author fullname="Murari Sridharan"></author> | <author fullname="Filip De Turck"/> | |||
<date year="2010"/> | <date year="2019"/> | |||
</front> | </front> | |||
<seriesInfo name="ACM SIGCOMM" value="pp.63-74"/> | <seriesInfo name="DOI" value="10.1145/3341558.3342201"/> | |||
<refcontent>NEAT'19: Proceedings of the ACM Sigcomm Workshop On Networki | ||||
ng For Emerging Applications And Technologies, pp. 22-28</refcontent> | ||||
</reference> | ||||
</reference> | <reference anchor="Westphal2021qualitative"> | |||
<front> | ||||
<title>Qualitative Communications for Augmented Reality and Virtual Re | ||||
ality </title> | ||||
<author fullname="Cedric Westphal"/> | ||||
<author fullname="Dongbiao He"/> | ||||
<author fullname="Kiran Makhijani"/> | ||||
<author fullname="Richard Li"/> | ||||
<date year="2021"/> | ||||
</front> | ||||
<seriesInfo name="DOI" value="10.1109/HPSR52026.2021.9481793"/> | ||||
<refcontent>22nd IEEE International Conference on High Performance Switc | ||||
hing and Routing (HPSR), pp. 1-6</refcontent> | ||||
</reference> | ||||
<reference anchor="QUAL"> | <reference anchor="Herzen2011PIE"> | |||
<front> | <front> | |||
<title> A Framework for Qualitative Communications using Big Packet Protocol | <title>Scalable routing easy as PIE: A practical isometric embedding p | |||
</title> | rotocol</title> | |||
<author fullname="Richard Li"></author> | <author fullname="Julien Herzen"/> | |||
<author fullname="Kiran Makhijani"></author> | <author fullname="Cedric Westphal"/> | |||
<author fullname="Hamed Yousefi"></author> | <author fullname="Patrick Thiran"/> | |||
<author fullname="Cedric Westphal"></author> | <date year="2011"/> | |||
<author fullname="Lijun Xong"></author> | </front> | |||
<author fullname="Tim Wauters"></author> | <seriesInfo name="DOI" value="10.1109/ICNP.2011.6089081"/> | |||
<author fullname="Filip De Turck"></author> | <refcontent>19th IEEE International Conference on Network Protocols (ICN | |||
<date year="2019"/> | P), pp. 49-58</refcontent> | |||
</front> | </reference> | |||
<seriesInfo name="Proceedings ACM Sigcomm Workshop On Networking For Emer | ||||
ging Applications And Technologies" value="pp.22-28"/> | ||||
</reference> | <reference anchor="Ren2018jordan"> | |||
<front> | ||||
<title>JORDAN: A Novel Traffic Engineering Algorithm for Dynamic Adapt | ||||
ive Streaming over HTTP</title> | ||||
<author fullname="Jing Ren"/> | ||||
<author fullname="Kejie Lu"/> | ||||
<author fullname="Cedric Westphal"/> | ||||
<author fullname="Jin Wang"/> | ||||
<author fullname="Jinfan Wang"/> | ||||
<author fullname="Tongyu Song"/> | ||||
<author fullname="Shucheng Liu"/> | ||||
<author fullname="Jianping Wang"/> | ||||
<date year="2018"/> | ||||
</front> | ||||
<seriesInfo name="DOI" value="10.1109/ICCNC.2018.8390337"/> | ||||
<refcontent>2018 International Conference on Computing, Networking and C | ||||
ommunications (ICNC), pp. 581-587</refcontent> | ||||
</reference> | ||||
<reference anchor="Westphal2021qualitative"> | <reference anchor="Bianco2016energy"> | |||
<front> | <front> | |||
<title>Qualitative Communications for Augmented Reality and Virtual Reality | <title>Energy consumption for data distribution in content delivery ne | |||
</title> | tworks</title> | |||
<author fullname="Cedric Westphal"></author> | <author fullname="Andreas Bianco"/> | |||
<author fullname="Dongbiao He"></author> | <author fullname="Reza Mashayekhi"/> | |||
<author fullname="Kiran Makhijani"></author> | <author fullname="Michele Meo"/> | |||
<author fullname="Richard Li"></author> | <date year="2016"/> | |||
<date year="2021"/> | </front> | |||
</front> | <refcontent>IEEE International Conference on Communications (ICC), pp. 1 | |||
<seriesInfo name="22nd IEEE International Conference on High Performance | -6</refcontent> | |||
Switching and Routing (HPSR)" value="pp.1-6"/> | <seriesInfo name="DOI" value="10.1109/ICC.2016.7511356"/> | |||
</reference> | </reference> | |||
<reference anchor="Herzen2011PIE"> | <reference anchor="Mathew2011energy" target="https://arxiv.org/abs/1109.56 | |||
<front> | 41"> | |||
<title>Scalable routing easy as PIE: A practical isometric embedding protoco | <front> | |||
l</title> | <title>Energy-Aware Load Balancing in Content Delivery Networks</title | |||
<author fullname="Julien Herzen"></author> | > | |||
<author fullname="Cedric Westphal"></author> | <author fullname="Vimal Mathew"/> | |||
<author fullname="Patrick Thiran"></author> | <author fullname="Ramesh Sitaraman"/> | |||
<date year="2011"/> | <author fullname="Prashant Shenoy"/> | |||
</front> | <date year="2011"/> | |||
<seriesInfo name="19th IEEE International Conference on Network Protocols | </front> | |||
(ICNP)" value="pp.49-58"/> | <seriesInfo name="DOI" value="10.48550/arXiv.1109.5641"/> | |||
</reference> | <seriesInfo name="arXiv:" value="1109.5641v1"/> | |||
</reference> | ||||
<reference anchor="Ren2018jordan"> | <reference anchor="Islam2012evaluating"> | |||
<front> | <front> | |||
<title>JORDAN: A Novel Traffic Engineering Algorithm for Dynamic Adaptive St | <title>Evaluating Energy Consumption in CDN Servers</title> | |||
reaming over HTTP</title> | <author fullname="Saif ul Islam"/> | |||
<author fullname="Jing Ren"></author> | <author fullname="Jean-Marc Pierson"/> | |||
<author fullname="Kejie Ren"></author> | <date year="2012"/> | |||
<author fullname="Cedric Westphal"></author> | </front> | |||
<author fullname="Jin Wang"></author> | <seriesInfo name="DOI" value="10.1007/978-3-642-32606-6_6"/> | |||
<author fullname="Jinfan Wang"></author> | <refcontent>Proceedings of the Second International Conference on ICT as Key Tec | |||
<author fullname="Tongyu Song"></author> | hnology against Global Warming, Lecture Notes in Computer Science, vol 7453, pp. | |||
<author fullname="Sucheng Liu"></author> | 64-78</refcontent> | |||
<author fullname="Jianping Wang"></author> | </reference> | |||
<date year="2018"/> | ||||
</front> | ||||
<seriesInfo name="IEEE International Conference on Computing, Networking | ||||
and Communications (ICNC)" value="pp.581-587"/> | ||||
</reference> | ||||
<reference anchor="Bianco2016energy"> | <reference anchor="Ahlgren2012survey"> | |||
<front> | <front> | |||
<title>Energy consumption for data distribution in content delivery networks | <title>A survey of information-centric networking</title> | |||
</title> | <author fullname="Bengt Ahlgren"/> | |||
<author fullname="Andreas Bianco"></author> | <author fullname="Christian Dannewitz"/> | |||
<author fullname="Reza Mashayekhi"></author> | <author fullname="Claudio Imbrenda"/> | |||
<author fullname="Michele Meo"></author> | <author fullname="Dirk Kutscher"/> | |||
<date year="2016"/> | <author fullname="Borje Ohlman"/> | |||
</front> | <date year="2012"/> | |||
<seriesInfo name="IEEE International Conference on Communications (ICC)" val | </front> | |||
ue="pp.1-6"/> | <refcontent>IEEE Communications Magazine, vol. 50, no. 7, pp. 26-36</ref | |||
content> | ||||
<seriesInfo name="DOI" value="10.1109/MCOM.2012.6231276"/> | ||||
</reference> | ||||
</reference> | <reference anchor="Wolf2014choicenet"> | |||
<front> | ||||
<title>ChoiceNet: Toward an Economy Plane for the Internet</title> | ||||
<author fullname="Wolf Tilman"/> | ||||
<author fullname="James Griffioen"/> | ||||
<author fullname="Lenneth Calvert"/> | ||||
<author fullname="Rudra Dutta"/> | ||||
<author fullname="George Rouskas"/> | ||||
<author fullname="Ilya Baldin"/> | ||||
<author fullname="Anna Nagurney"/> | ||||
<date year="2014" month="July"/> | ||||
</front> | ||||
<seriesInfo name="DOI" value="10.1145/2656877.2656886"/> | ||||
<refcontent>ACM SIGCOMM Computer Communciations Review, vol. 44, no. 3, | ||||
pp. 58-65</refcontent> | ||||
</reference> | ||||
<reference anchor="Mathew2011energy"> | <reference anchor="Krol2017NFaaS"> | |||
<front> | <front> | |||
<title>Energy-Aware Load Balancing in Content Delivery Networks</title> | <title>NFaaS: Named Function as a Service</title> | |||
<author fullname="Vimal Mathew"></author> | <author fullname="Michal Krol"/> | |||
<author fullname="Ramesh Sitaraman"></author> | <author fullname="Ioannis Psaras"/> | |||
<author fullname="Prashant Shenoy"></author> | <date year="2017"/> | |||
<date year="2011"/> | </front> | |||
</front> | <refcontent>ICN '17: Proceedings of the 4th ACM Conference on Informatio | |||
<seriesInfo name="CoRR http://arxiv.org/abs/1109.5641" value=""/> | n-Centric Networking, pp. 134-144</refcontent> | |||
</reference> | <seriesInfo name="DOI" value="10.1145/3125719.3125727"/> | |||
</reference> | ||||
<reference anchor="Islam2012evaluating"> | <reference anchor="TCC"> | |||
<front> | <front> | |||
<title>Evaluating Energy Consumption in CDN Servers</title> | <title>Selective Noise Based Power-Efficient and Effective Countermeas | |||
<author fullname="Saif ul Islam"></author> | ure Against Thermal Covert Channel Attacks in Multi-Core Systems</title> | |||
<author fullname="Jean-Marc Pierson"></author> | <author fullname="Parisa Rahimi"/> | |||
<date year="2012"/> | <author fullname="Amit Kumar Singh"/> | |||
</front> | <author fullname="Xioahang Wang"/> | |||
<seriesInfo name="Proceedings of the Second International Conference on I | <date year="2022"/> | |||
CT as Key Technology against Global Warming" value="pp.64-78"/> | </front> | |||
</reference> | <seriesInfo name="DOI" value="10.3390/jlpea12020025"/> | |||
<refcontent>Journal on Low Power Electronics and Applications, vol. 12, | ||||
no. 2</refcontent> | ||||
</reference> | ||||
<reference anchor="Ahlgren2012survey"> | <reference anchor="DRAM"> | |||
<front> | <front> | |||
<title>A survey of information-centric networking</title> | <title>Robust Covert Channels Based on DRAM Power Consumption</title> | |||
<author fullname="Bengt Ahlgren"></author> | <author fullname="Thales Bandiera Paiva"/> | |||
<author fullname="Christian Dannewitz"></author> | <author fullname="Javier Navaridas"/> | |||
<author fullname="Claudio Imbrenda"></author> | <author fullname="Routo Terada"/> | |||
<author fullname="Dirk Kutscher"></author> | <date year="2019"/> | |||
<author fullname="Borje Ohlman"></author> | </front> | |||
<date year="2012"/> | <seriesInfo name="DOI" value="10.1007/978-3-030-30215-3_16"/> | |||
</front> | <refcontent>Information Security, ISC 2019, Lecture Notes in Computer Sc | |||
<seriesInfo name="IEEE Communications Magazine" value="Vol.50 No.7"/> | ience, vol 11723</refcontent> | |||
</reference> | </reference> | |||
<reference anchor="Wolf2014choicenet"> | <reference anchor="NewClass"> | |||
<front> | <front> | |||
<title>ChoiceNet: Toward an Economy Plane for the Internet</title> | <title>A New Class of Covert Channels Exploiting Power Management Vuln | |||
<author fullname="Wolf Tilman"></author> | erabilities</title> | |||
<author fullname="James Griffioen"></author> | <author fullname="S. Karen Khatamifard"/> | |||
<author fullname="Lenneth Calvert"></author> | <author fullname="Longfei Wang"/> | |||
<author fullname="Rudra Dutta"></author> | <author fullname="Selcuk Kose"/> | |||
<author fullname="George Rouskas"></author> | <author fullname="Ulya R. Karpuzcu"/> | |||
<author fullname="Ilya Baldin"></author> | <date year="2018"/> | |||
<author fullname="Anna Nagurney"></author> | </front> | |||
<date year="2014" month="July"/> | <seriesInfo name="DOI" value="10.1109/LCA.2018.2860006"/> | |||
</front> | <refcontent>IEEE Computer Architecture Letters, vol. 15, no. 2, pp. 201- | |||
<seriesInfo name="SIGCOMM Computer Communciations Review" value="Vol.44 N | 204</refcontent> | |||
o.3"/> | </reference> | |||
</reference> | ||||
<reference anchor="Krol2017NFaaS"> | <reference anchor="SideChannel"> | |||
<front> | <front> | |||
<title>NFaaS: Named Function as a Service</title> | <title>Power Side-Channel Attack Analysis: A Review of 20 Years of Stu | |||
<author fullname="Michal Krol"></author> | dy for the Layman</title> | |||
<author fullname="Ioannis Psaras"></author> | <author fullname="Mark Randolph"/> | |||
<date year="2017"/> | <author fullname="William Diehl"/> | |||
</front> | <date year="2020"/> | |||
<seriesInfo name="ACM SIGCOMM ICN Conference" value=""/> | </front> | |||
</reference> | <refcontent>Cryptography, vol. 4, no. 2</refcontent> | |||
<seriesInfo name="DOI" value="10.3390/cryptography4020015"/> | ||||
</reference> | ||||
<reference anchor="TCC"> | <reference anchor="Framework"> | |||
<front> | <front> | |||
<title>Selective Noise Based Power Efficient and Effective Countermeasure Ag | <title>A framework to estimate emissions from virtual conferences</tit | |||
ainst Thermal Covert Channel Attacks in Multi-Core Systems</title> | le> | |||
<author fullname="Parisa Rahimi"></author> | <author fullname="Grant Faber"/> | |||
<author fullname="Amit Kumar Singh"></author> | <date year="2021"/> | |||
<author fullname="Xioahang Wang"></author> | </front> | |||
<date year="2022"/> | <seriesInfo name="DOI" value="10.1080/00207233.2020.1864190"/> | |||
</front> | <refcontent>International Journal of Environmental Studies, vol. 78, no. | |||
<seriesInfo name="Journal on Low Power Electronics and Applications" valu | 4, pp. 608-623</refcontent> | |||
e=""/> | </reference> | |||
</reference> | ||||
<reference anchor="DRAM"> | <reference anchor="Emergy"> | |||
<front> | <front> | |||
<title>Robust Covert Channels Based on DRAM Power Consumption</title> | <title>The Energy and Emergy of the Internet</title> | |||
<author fullname="Thales Bandiera Paiva"></author> | <author fullname="Barath Raghavan"/> | |||
<author fullname="Javier Navaridas"></author> | <author fullname="Justin Ma"/> | |||
<author fullname="Routo Terada"></author> | <date year="2011"/> | |||
<date year="2019"/> | </front> | |||
</front> | <seriesInfo name="DOI" value="10.1145/2070562.2070571"/> | |||
<seriesInfo name="In book: Information Security (pp.319-338)" value=""/> | <refcontent>Proceedings of the 10th ACM Workshop on Hot Topics in Networ | |||
</reference> | ks, no. 9, pp. 1-6</refcontent> | |||
</reference> | ||||
<reference anchor="NewClass"> | <reference anchor="Junkyard" target="https://arxiv.org/abs/2110.06870v1"> | |||
<front> | <front> | |||
<title>A New Class of Covert Channels Exploiting Power Management Vulnerabil | <title>Architecture of a Junkyard Datacenter</title> | |||
ities</title> | <author fullname="Jennifer Switzer"/> | |||
<author fullname="S. Karen Khatamifard"></author> | <author fullname="Ryan Kastner"/> | |||
<author fullname="Longfei Wang"></author> | <author fullname="Pat Pannuto"/> | |||
<author fullname="Selcuk Kose"></author> | <date year="2021"/> | |||
<author fullname="Ulya R. Karpuzcu"></author> | </front> | |||
<date year="2018"/> | <seriesInfo name="DOI" value="10.48550/arXiv.2110.06870"/> | |||
</front> | <seriesInfo name="arXiv:" value="2110.06870v1"/> | |||
<seriesInfo name="IEEE Computer Architecture Letters" value=""/> | </reference> | |||
</reference> | ||||
<reference anchor="SideChannel"> | <reference anchor="TradeOff"> | |||
<front> | <front> | |||
<title>Power Side-Channel Attack Analysis: A Review of 20 Years of Study for | <title>Not a Trade-Off: On the Wi-Fi Energy Efficiency of Effective In | |||
the Layman</title> | ternet Congestion Control</title> | |||
<author fullname="Mark Randolph"></author> | <author fullname="Michael Welzl"/> | |||
<author fullname="William Diehl"></author> | <date year="2022"/> | |||
<date year="2020"/> | </front> | |||
</front> | <refcontent>2022 17th Wireless On-Demand Network Systems and Services Co | |||
<seriesInfo name="Cryptography 2020, 4, 15" value=""/> | nference (WONS), pp. 1-4</refcontent> | |||
</reference> | <seriesInfo name="DOI" value="10.23919/WONS54113.2022.9764413"/> | |||
</reference> | ||||
<reference anchor="Framework"> | <!-- [rfced] For [Hossain2019], the URL provided | |||
<front> | (https://ieeexplore.ieee.org/document/6779082) is fro an article | |||
<title> A framework to estimate emissions from virtual conferences</title> | titled "Measurement and modeling the power consumption of router | |||
<author fullname="Grant Faber"></author> | interface". | |||
<date year="2021"/> | ||||
</front> | ||||
<seriesInfo name="International Journal of Environmental Studies, 78:4, 6 | ||||
08-623" value=""/> | ||||
</reference> | ||||
<reference anchor="Emergy"> | We have updated the URL to use the DOI provided in the original | |||
<front> | reference. Please let us know if that is not accurate. | |||
<title>The Energy and Emergy of the Internet</title> | ||||
<author fullname="Barath Raghavan"></author> | ||||
<author fullname="Justin Ma"></author> | ||||
<date year="2011"/> | ||||
</front> | ||||
<seriesInfo name="ACM HotNets" value=""/> | ||||
</reference> | ||||
<reference anchor="Junkyard"> | Original: | |||
<front> | [Hossain2019] | |||
<title>Architecture of a Junkyard Datacenter</title> | Hossain, M., Georges, J., Rondeau, E., and T. Divoux, | |||
<author fullname="Jennifer Switzer"></author> | "Energy, Carbon and Renewable Energy: Candidate Metrics | |||
<author fullname="Ryan Kastner"></author> | for Green-Aware Routing?", DOI 10.3390/s19132901, | |||
<author fullname="Pat Pannuto"></author> | Sensors Vol. 19 No. 3, June 2019, | |||
<date year="2021"/> | <https://ieeexplore.ieee.org/document/6779082>. | |||
</front> | ||||
<seriesInfo name="arXiv:2110.06870v1, October 2021" value=""/> | ||||
</reference> | ||||
<reference anchor="TradeOff"> | Current: | |||
<front> | [Hossain2019] | |||
<title>Not a Trade-Off: On the Wi-Fi Energy Efficiency of Effective Internet | Hossain, M., Georges, J., Rondeau, E., and T. Divoux, | |||
Congestion Control</title> | "Energy, Carbon and Renewable Energy: Candidate Metrics | |||
<author fullname="Michael Welzl"></author> | for Green-Aware Routing?", Sensors, vol. 19, no. 3, | |||
<date year="2022"/> | DOI 10.3390/s19132901, June 2019, | |||
</front> | <https://doi.org/10.3390/s19132901>. | |||
<seriesInfo name="IEEE/IFIP WONS" value=""/> | --> | |||
</reference> | ||||
<reference anchor="Hossain2019" target="https://ieeexplore.ieee.org/docu ment/6779082"> | <reference anchor="Hossain2019"> | |||
<front> | <front> | |||
<title>Energy, Carbon and Renewable Energy: Candidate Metrics for Gree n-Aware Routing?</title> | <title>Energy, Carbon and Renewable Energy: Candidate Metrics for Gree n-Aware Routing?</title> | |||
<author fullname="M.M. Hossain"> </author> | <author fullname="M.M. Hossain"> </author> | |||
<author fullname="J.-P. Georges"> </author> | <author fullname="J.-P. Georges"> </author> | |||
<author fullname="E. Rondeau"> </author> | <author fullname="E. Rondeau"> </author> | |||
<author fullname="T. Divoux"> </author> | <author fullname="T. Divoux"> </author> | |||
<date month="June" year="2019"/> | <date month="June" year="2019"/> | |||
</front> | </front> | |||
<seriesInfo name="DOI" value="10.3390/s19132901"/> | <seriesInfo name="DOI" value="10.3390/s19132901"/> | |||
<seriesInfo name="Sensors" value="Vol. 19 No. 3"/> | <refcontent>Sensors, vol. 19, no. 3</refcontent> | |||
</reference> | </reference> | |||
<reference anchor="IETF-Net0" target="https://www.ietf.org/blog/towards-a-net- | <reference anchor="IETF-Net0" target="https://www.ietf.org/blog/towards-a- | |||
zero-ietf/"> | net-zero-ietf/"> | |||
<front> | <front> | |||
<title>Towards a net zero IETF</title> | <title>Towards a net zero IETF</title> | |||
<author fullname="Jay Daley"></author> | <author fullname="Jay Daley"/> | |||
<date day="6" month="5" year="2022"/> | <date day="6" month="5" year="2022"/> | |||
</front> | </front> | |||
<seriesInfo name="IETF News" value=""/> | <refcontent>IETF News</refcontent> | |||
</reference> | </reference> | |||
</references> | </references> | |||
</back> | <section numbered="false"> | |||
<name>Acknowledgments</name> | ||||
<t>The authors thank <contact fullname="Dave Oran"/> for providing the | ||||
information regarding covert channels using energy measurements and | ||||
<contact fullname="Mike King"/> for an exceptionally thorough review and | ||||
useful comments.</t> | ||||
</section> | ||||
<section numbered="false"> | ||||
<name>Contributors</name> | ||||
<contact fullname="Michael Welzl"> | ||||
<organization>University of Oslo</organization> | ||||
<address> | ||||
<email>michawe@ifi.uio.no</email> | ||||
</address> | ||||
</contact> | ||||
</section> | ||||
</back> | ||||
<!-- [rfced] Please review the "Inclusive Language" portion of the online | ||||
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> | ||||
and let us know if any changes are needed. Updates of this nature typically | ||||
result in more precise language, which is helpful for readers. | ||||
In addition, please consider whether "tradition" should be updated for clarity. | ||||
It can be ambiguous. | ||||
Section 6.1: Optimizing cost has a long tradition in networking; | ||||
--> | ||||
<!-- [rfced] Some author comments are present in the XML. Please confirm | ||||
that no updates related to these comments are outstanding. Note that the | ||||
comments will be deleted prior to publication. --> | ||||
</rfc> | </rfc> | |||
End of changes. 199 change blocks. | ||||
1287 lines changed or deleted | 2078 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |