Re: Network Energy Management

Tim Bray <tbray@textuality.com> Fri, 05 August 2022 05:57 UTC

Return-Path: <tbray@textuality.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819CCC157B44 for <ietf@ietfa.amsl.com>; Thu, 4 Aug 2022 22:57:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.908
X-Spam-Level:
X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.20210112.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21-mj6axwbTE for <ietf@ietfa.amsl.com>; Thu, 4 Aug 2022 22:57:01 -0700 (PDT)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D874C14F72D for <ietf@ietf.org>; Thu, 4 Aug 2022 22:57:01 -0700 (PDT)
Received: by mail-ej1-x631.google.com with SMTP id w19so3173790ejc.7 for <ietf@ietf.org>; Thu, 04 Aug 2022 22:57:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+3/9C4i8cfYHkt/80tjCbgzaMM+4CEWRHdJJTP4zuvI=; b=iXOxwUaIR1Oa5+oBLqq8KT4oPH1cUn+Q3SsNCOEiaMZy6R7U0Yh7ZyniPvSQ+lOp8H N9PCwDLArLy9J/IJWByiFhLqJBRKRtljUo+C6frfBZMQXX1thRcYpQ9FnYmQAPo+cG3y oGbpYTFgVCm8s8Zyg37U4WfmOim2UWXUpizdShpt5DK2hImcKruuHLPsjIKXv342Mbkf N6w07tyQGPhGOL2j9bxNXYAv89ys1+MFpo+a3rfGDY9EO53u/Nm57kxrMI41piahkuxG nWxPPxHpyvAkx3pFNW5Gsmb90qDGQAZm1bJNTY41AYFAz+Co7JVvyvg6ZDjpBQmZQZ0u jdcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+3/9C4i8cfYHkt/80tjCbgzaMM+4CEWRHdJJTP4zuvI=; b=YUKl6or6JsuqBzTaNriYOziYZ8deM8XHGKq18ZyIS9XeZW8NRiodQjVGCARseXk3+v EjafVFISMvx2M5h4Meu+SjByWa18Nferg/cAyHIEniNBPms8wnlDV55kKZxSkpKzG+rN AxvdmXecnNXZtXgCd5VYMgt9UGd/vgdzL6nR7yXMANM0o2XawQs1VCk1FMtAnVhcc6v5 yte9AyJJslYN7jw0mimIzGaK/mV+RoB+9u2tgkMp8gmdq8IIkbw/FC1nSC/Jl3f533gc pSobQqX2W+RG2D4tqdtBEyEtUuWmByf1vdpv0AjUnymxWw7gzChoVtmkG7cgJmRUqJ9t C0uw==
X-Gm-Message-State: ACgBeo0Rmkpodo5kxhtHnigYYliL31Eht9k1OiAudDKlFMA8TpiGLESC fhBf03vP2WVuWuYJ1Lt9CtvuK8OF0xoPlrj+JaE6MXPqD+4=
X-Google-Smtp-Source: AA6agR4bjNQP8TMTx0EpfajDgYi0fNug7Cqipw0L/SWeQ2bfvPGbhpGx96aC3+idOERCMA4D9f8WEyuTIsHlZwQoqYI=
X-Received: by 2002:a17:907:3e86:b0:6f5:917:10cc with SMTP id hs6-20020a1709073e8600b006f5091710ccmr4244758ejc.53.1659679019157; Thu, 04 Aug 2022 22:56:59 -0700 (PDT)
MIME-Version: 1.0
References: <81c9a652-81d2-9511-1c4a-3da06e80b48b@gmail.com> <c23c3f60359249f3959e14d616f014c4@huawei.com> <CAFvDQ9qQKTD5QSmmsD7Yuv+KihBxusXi4BD8wcuWxRGhy556HA@mail.gmail.com> <7dcc2e2d7cf245c88ab7788f0df36148@huawei.com> <2c3b9597-c1f4-a062-50ba-ba55d342c7d2@gmail.com> <CAKr6gn2T=Lu3h0w3_tdD2Yu-iTXdGky1ei1pXUWs46k8-dyqhw@mail.gmail.com> <1893e737-698e-c428-e55e-b8d613988163@gmail.com>
In-Reply-To: <1893e737-698e-c428-e55e-b8d613988163@gmail.com>
From: Tim Bray <tbray@textuality.com>
Date: Thu, 04 Aug 2022 22:56:47 -0700
Message-ID: <CAHBU6ivx0uQeM_Ug2Hfa2QMWp-toxqz=v=_+BM_41-yYSViX2Q@mail.gmail.com>
Subject: Re: Network Energy Management
To: Hesham ElBakoury <helbakoury@gmail.com>
Cc: George Michaelson <ggm@algebras.org>, IETF <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000060e13e05e5782205"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/jXh6RmwD8xsPtfzj0aTw8tcxjWM>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Aug 2022 05:57:02 -0000

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@gmail.com>
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@gmail.com>
> 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@gmail.com]
> >> Sent: Friday, August 5, 2022 9:08 AM
> >> To: Tianran Zhou <zhoutianran@huawei.com>
> >> Cc: IETF <ietf@ietf.org>
> >> 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@huawei.com>
> 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@ietf.org] On Behalf Of Hesham ElBakoury
> >> Sent: Friday, August 5, 2022 7:12 AM
> >> To: IETF <ietf@ietf.org>
> >> 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
>
>