From nobody Thu May 11 15:40:03 2023 Return-Path: X-Original-To: e-impact@ietfa.amsl.com Delivered-To: e-impact@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69192C1782AC for ; Thu, 11 May 2023 15:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 EizMwi0-vScb for ; Thu, 11 May 2023 15:39:58 -0700 (PDT) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 2A554C16B5C6 for ; Thu, 11 May 2023 15:39:58 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id 41be03b00d2f7-5144043d9d1so6285352a12.3 for ; Thu, 11 May 2023 15:39:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683844797; x=1686436797; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=jVBREUhXcEQ1VV6VYRgHnM4QTuVRMVKEIeA+QZWa2Pg=; b=p0mybxy3/Iz+J7rmrF6ZtrVsMLImahgxrHCzdw2QdiFbuY5W/srshkhbT9Hn/bOMuF nUevuflNwb5tYpQmUrSKd8qfjAb8JxouOc06/hPhk1tIpSoRMLFbgx3FILhnPhP1EF6E rDrXX2oCOlBn2t3y4HzoS6nRnqwwurgKX3qyU0hvE58d6XaeuSJUvhNRsF0jPaiUcaf4 kvojXlEl3ZhStJehm8S7R8mSoWQc25Rew4qDwguhaVSeSRGWVhI/RFojujA7CuMvQq3E FeTXbQyb0sB5E2E53b7JBFvX8wIkxAifnICjaMByRMxcAgfb+VgOGP+tqvwzEaG9wWcJ aWRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683844797; x=1686436797; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=jVBREUhXcEQ1VV6VYRgHnM4QTuVRMVKEIeA+QZWa2Pg=; b=hKxfvfZwN89PPxe8bN3KTTzd/hkkoncPyJrOzKKqlvv1ooB6ie5glL5t9ZHvYmaUrG OmRIOatmyTsrr6XlDftzIgCs+0I2W+tHBX57/GRpkcS5aL1HRmfZscqkJLOZMM+Hn1Y1 nMywX4G0YeM+YKvfb7jAOS+Mo6NuECmGssnte240Vuky+1oRq8qd4v1c/g/eDYDLUs9v uj9SqQh+SI0N1ldtMXCAVO46dfpBAHhL/fHC1RipusptjDbyvl+EFsnjXbCUCYk0gv5P fyPZjowue23yMPpLaD9ZVNnIJyRMgB60qyFMcQaBqdeDjhuCle97z9N8t6PV7x4cl9P5 4Frw== X-Gm-Message-State: AC+VfDya9Ds4ltmJo9VJKVyia4VBFUETmgu9UozI+f0tSSqmigig1xLv +R80MlFnOGhgQS/Uk1O3Zu2xImVu3zxhveKfDUQ= X-Google-Smtp-Source: ACHHUZ4IXGhjD+WZR6+HBd7yAw+j0se0F6aaCNXD+rsYBhr/RbAdNH/Yuy85uv0iVb5cPdQImqEx5czmIp4YXYFUt5c= X-Received: by 2002:a17:90b:3ec2:b0:250:ca6c:d7a8 with SMTP id rm2-20020a17090b3ec200b00250ca6cd7a8mr8453778pjb.29.1683844797432; Thu, 11 May 2023 15:39:57 -0700 (PDT) MIME-Version: 1.0 References: <841c38f0-cf9e-a1d1-b3a7-48e70f2b090a@gmail.com> In-Reply-To: <841c38f0-cf9e-a1d1-b3a7-48e70f2b090a@gmail.com> From: Hesham ElBakoury Date: Thu, 11 May 2023 15:39:46 -0700 Message-ID: To: Brian E Carpenter Cc: Vesna Manojlovic , e-impact@ietf.org Content-Type: multipart/alternative; boundary="00000000000002079205fb72ab8a" Archived-At: Subject: Re: [E-impact] kWh/GB should be banned and the IETF should warn against its use X-BeenThere: e-impact@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Environmental impacts of the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2023 22:40:02 -0000 --00000000000002079205fb72ab8a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Brian, You help answer one of my questions in my response to Jari's State of Metrics email. The other question is related to the type networks IETF is intetested in to define these metrics. Hesham On Thu, May 11, 2023, 2:09 PM Brian E Carpenter wrote: > On 12-May-23 02:50, Vesna Manojlovic wrote: > > Rudolf, all, > > > > On 11/05/2023 12:24, Rudolf van der Berg wrote: > >> kWh/GB is one of the most misleading and scientifically incorrect > >> ways of describing the energy use of networks. > > > > What is a better way to describe the energy use? > > I very much doubt that there is a simple answer to that. Lars ask for > metrics (plural) and that is probably the right question. > > For example, for a given technology, we could ask: what is the ratio > between energy consumed when doing nothing and energy consumed when > operating at full capacity? How do we maximize that ratio? > > For a given protocol, we could ask: what is the minimum rate of keep-aliv= es > for acceptable performance? > > It gets more complicated when you consider (for example) compression. > Does compression (for a given protocol) save more energy during > transmission > than it costs during compression and decompression at each end? > > How does an encoding like CBOR compare to traditional TLVs, considering > both energy for transmission and energy for encoding and decoding? > How much energy does SCHC save? > > (Did 6LOWPAN, LPWAN or ROLL already analyse such questions?) > > > And, more importantly, how are we going to decrease the energy use? > > We, the IETF, need some design guidelines for our protocols. And we > should stick to that and not try to discuss more general aspects, > because that will get us nowhere, IMHO. > > Brian > > > Because: there are many recommendations, and even regulations, to do so= : > > > > https://www.iea.org/reports/data-centres-and-data-transmission-networks > > > > "ICT companies should set ambitious efficiency and CO2 emission targets > > and implement concrete measures to track progress and achieve these > > goals. This includes alignment with the ICT industry=E2=80=99s science-= based > > target to reduce GHG emissions by 45%=E2=80=AFbetween 2020 and 2030. " > > > > The same source (International Energy Agency) shows growth in global IC= T > > energy usage, despite the efficiency gains. (see attached) > > > > > > > > And ITU recommended in 2020 to =E2=80=9Creduce ICT GHG emissions by 45%= by 2030=E2=80=9D > > > https://www.itu.int/en/mediacentre/Pages/PR04-2020-ICT-industry-to-reduce= -greenhouse-gas-emissions-by-45-percent-by-2030.aspx > > > > So, may I suggest that we focus on how to achieve these goals? > > > > And furthermore, it might NOT be possible to "reduce emissions while > > keeping the same quality of service" -- and my position is that it is > > more important to reduce the emissions, even if that means _planned_ > > lowering of the quality of service -- to avoid worse consequences in th= e > > future, or in the other part of the world. > > > > > > Vesna > > > > > -- > E-impact mailing list > E-impact@ietf.org > https://www.ietf.org/mailman/listinfo/e-impact > --00000000000002079205fb72ab8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks=C2=A0Brian,
You help answer one o= f my questions in my response to Jari's State of Metrics email.

The other question=C2=A0is rela= ted to the type networks IETF is intetested in to define these metrics.

Hesham

On Thu, May 11,= 2023, 2:09 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
On 12-May-23 02:50, Vesna Manojlovic wrote:
> Rudolf, all,
>
> On 11/05/2023 12:24, Rudolf van der Berg wrote:
>> kWh/GB is one of the most misleading and scientifically incorrect<= br> >> ways of describing the energy use of networks.
>
> What is a better way to describe the energy use?

I very much doubt that there is a simple answer to that. Lars ask for
metrics (plural) and that is probably the right question.

For example, for a given technology, we could ask: what is the ratio
between energy consumed when doing nothing and energy consumed when
operating at full capacity? How do we maximize that ratio?

For a given protocol, we could ask: what is the minimum rate of keep-alives=
for acceptable performance?

It gets more complicated when you consider (for example) compression.
Does compression (for a given protocol) save more energy during transmissio= n
than it costs during compression and decompression at each end?

How does an encoding like CBOR compare to traditional TLVs, considering
both energy for transmission and energy for encoding and decoding?
How much energy does SCHC save?

(Did 6LOWPAN, LPWAN or ROLL already analyse such questions?)

> And, more importantly, how are we going to decrease the energy use?
We, the IETF, need some design guidelines for our protocols. And we
should stick to that and not try to discuss more general aspects,
because that will get us nowhere, IMHO.

=C2=A0 =C2=A0 =C2=A0Brian

> Because: there are many recommendations, and even regulations, to do s= o:
>
> https://www.i= ea.org/reports/data-centres-and-data-transmission-networks
>
> "ICT companies should set ambitious efficiency and CO2 emission t= argets
> and implement concrete measures to track progress and achieve these > goals. This includes alignment with the ICT industry=E2=80=99s science= -based
> target to reduce GHG emissions by 45%=E2=80=AFbetween 2020 and 2030.= =C2=A0 "
>
> The same source (International Energy Agency) shows growth in global I= CT
> energy usage, despite the efficiency gains. (see attached)
>
>
>
> And ITU recommended in 2020 to =E2=80=9Creduce ICT GHG emissions by 45= % by 2030=E2=80=9D
> https://www.itu.int/en/mediacentre= /Pages/PR04-2020-ICT-industry-to-reduce-greenhouse-gas-emissions-by-45-perc= ent-by-2030.aspx
>
> So, may I suggest that we focus on how to achieve these goals?
>
> And furthermore, it might NOT be possible to "reduce emissions wh= ile
> keeping the same quality of service" -- and my position is that i= t is
> more important to reduce the emissions, even if that means _planned_ > lowering of the quality of service -- to avoid worse consequences in t= he
> future, or in the other part of the world.
>
>
> Vesna
>
>
--
E-impact mailing list
E= -impact@ietf.org
https://www.ietf.org/mailman/listinfo/e-imp= act
--00000000000002079205fb72ab8a--