FWIW, when I was at AWS and Amazon got on the climate-pledge program, I got interested to see if there was anything we could do in software or networking to reduce the carbon cost of various applications and services. I came up pretty empty. The word I got is that your AWS bill is a pretty decent proxy for your carbon load.
Having said that, at that point pretty well all the CPUs were Intel, and the newer ARM instruction-set chips - what AWS calls “Graviton” and Apple calls “Apple Silicon” - have a really different characteristic in the power consumed per unit of useful work, as evidenced by the remarkable battery life of the Apple products with the new CPUs. I suppose you could imagine a protocol for querying a host's power efficiency according to some standard metric and use that to route workload to reduce carbon load. Having said that, in the AWS case the Gravitons are just *cheaper* per unit of work so there's a natural incentive to just pick those those instance types wherever possible - not sure the protocol is really a value-add.
What I thought was the real news story, and I could never get anyone to hype up, is how remarkably easy it is to move many (most?) modern workloads from one instruction set to another. VM runtimes like Java and Python, and modern compilers like Go and Rust, really more or less Just Work. I saw some scarily complex microservice-based services ported from Intel to Graviton with absurdly little time and effort.
Pardon the rambling, back to your regular programming.
On Thu, Aug 4, 2022 at 9:48 PM Hesham ElBakoury <helbakoury@xxxxxxxxx> wrote:
There are representatives of several service providers who attend IETF.
They may have good ideas on the solutions they need to achieve their Net
Zero goal, and what needs to be standardized (if any) in IETF.
Thank
Hesham
On 8/4/2022 9:25 PM, George Michaelson wrote:
> If you want to ask SP's a question, a NOG list or a WG is a better
> place than an IETF wide list.
>
> -G
>
> On Fri, Aug 5, 2022 at 2:11 PM Hesham ElBakoury <helbakoury@xxxxxxxxx> wrote:
>> Actually, I am interested to find out from service providers what solutions they need to deploy to achieve their Net-Zero goal and what needs to be standardized (if any) to deploy these solutions.
>>
>> Hesham
>>
>> On 8/4/2022 6:53 PM, Tianran Zhou wrote:
>>
>> Hi Hesham,
>>
>> To be specific, what’s your thoughts on the following two use cases.
>>
>>
>>
>> 3- Use traffic analysis and modeling techniques perhaps with AI/ML algorithms to predict which elements to power down/up and when, in such a way to avoid service disruption.
>> 4- Use renewable energy, store it in the router and return back to the energy source the energy that is not used so that someone else can use it.
>>
>>
>>
>> Thanks,
>>
>> Tianran
>>
>>
>>
>> From: Hesham ElBakoury [mailto:helbakoury@xxxxxxxxx]
>> Sent: Friday, August 5, 2022 9:08 AM
>> To: Tianran Zhou <zhoutianran@xxxxxxxxxx>
>> Cc: IETF <ietf@xxxxxxxx>
>> Subject: Re: Network Energy Management
>>
>>
>>
>> There are publicatipns about changes to IP, TCP, Routing Protocols, Traffic Engineering, ... etc but I am not sure if these changes are implemented and deployed in service provider networks.
>>
>>
>>
>> Thanks
>>
>>
>>
>> Hesham
>>
>>
>>
>> On Thu, Aug 4, 2022, 5:49 PM Tianran Zhou <zhoutianran@xxxxxxxxxx> wrote:
>>
>> While I think this is an very interesting topic that I would like to follow, I am confused most of the proposal here may not related to network protocol.
>> I.e, I am not sure what IETF can help on this.
>>
>> Best,
>> Tianran
>>
>> -----Original Message-----
>> From: ietf [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Hesham ElBakoury
>> Sent: Friday, August 5, 2022 7:12 AM
>> To: IETF <ietf@xxxxxxxx>
>> Subject: Network Energy Management
>>
>> There has been some discussions in IETF 114 about how to reduce the network energy consumption and carbon footprint. Most of the energy-aware routing and traffic engineering publications that I have seen rely on powering down network elements such as interfaces, line cards and routers to save power. The problems with this approach are: 1) to power up these elements when they are needed may take long time which may cause undesirable service disruption, and 2) network operators may not trust routing and traffic engineering software to power down and up these elements without operator intervention.
>>
>> To address these problems we may do one of the following:
>>
>> 1- Do not power down any network element, and try some other way to reduce energy such as adjusting the cooling level based on network load.
>>
>> 2- Do not power down any network element, but put the element in low power idle state to consume least amount of power while it is not used to forward traffic. In this state it is quicker to bring the element into fully operational state. This solution may require hardware support.
>>
>> 3- Use traffic analysis and modeling techniques perhaps with AI/ML algorithms to predict which elements to power down/up and when, in such a way to avoid service disruption.
>>
>> 4- Use renewable energy, store it in the router and return back to the energy source the energy that is not used so that someone else can use it.
>>
>> 5- If you have other approaches, please let us know.
>>
>> In all these approaches we need to instrument the network to monitor its traffic loading and energy consumption.
>>
>> Comments ?
>>
>> Hesham
