Re: [E-impact] kWh/GB should be banned and the IETF should warn against its use

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 11 May 2023 21:09 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 BD662C1522C2 for <e-impact@ietfa.amsl.com>; Thu, 11 May 2023 14:09:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 IrNHG6cY0SiW for <e-impact@ietfa.amsl.com>; Thu, 11 May 2023 14:09:13 -0700 (PDT)
Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 9D035C1519B9 for <e-impact@ietf.org>; Thu, 11 May 2023 14:09:13 -0700 (PDT)
Received: by mail-pl1-x62a.google.com with SMTP id d9443c01a7336-1aaf70676b6so65197525ad.3 for <e-impact@ietf.org>; Thu, 11 May 2023 14:09:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683839353; x=1686431353; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=rjRToqBlpda0/Nfy+C+zJeCJxYSPPBpaWXMrZs8Y/8s=; b=Yi4u2+C4k3S/0CzXkdavlPgP7tPojpRdpbrTipqn9EX4+MczGQVVJZ5YV80udKxpUz yHY3xnNTV5G5v8tyoWvAAufjH4X1dPQJNElK2M2x5ENPKmMjA3UDb8f6tw77id5+eFOP FeLefKXacH3a2iadYknIbPyZZ1FA+cUph83HYb/kLbJ7x80GLQKXylex3y3d1InzK0i6 rCktz4W7Rqr7jsXcUxjApm9Bq/2O8LRWovpsdFT/ZUa+G5PGEBxQssU/+yD04ozCIi07 3iEhU6x6vieDcd0YnSWmUApy+xSKPjWHXGgsqBLyTsF7szbio8/Bcv8jl5HgD6M/YdYV hbWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683839353; x=1686431353; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=rjRToqBlpda0/Nfy+C+zJeCJxYSPPBpaWXMrZs8Y/8s=; b=evrhwm3BugvARedf/7aqfXfwlnsF7A9z3HLWidG3+ZqME0A7MS26lw9o6uGyUowjeb Nzdsw7a6L4p661G3iy9n6gsAFigJ2iG2bD2pJW9Xs8AH6vl4OhG8p3rlVX8RmkCx/Je9 2fR9ELU9m1kTUgLuN/yJ9HBjAs1ea1KOe6WlxLmjC7w/rTKbZLIGtMgYcSj1Q59cWrjG bmgDaE/0zV0R1gc9DSPbmEGhM2UTdw9XTKuldpOy7yMYoemdGAeX8DFA7uMPiwRCz/p4 kEIhcQEzl3Wopg79LM/96Ru4cwXn5VM1lBuaUWvKIuvjZ7BaF0+XrAu7FcsxThlJD1FD lL+g==
X-Gm-Message-State: AC+VfDxIVLAUmpu/3R92jxtBlU7fe/DcY9TTAGwLlWI0G2vPnUDGkYH9 ojhWsY+xJuLBnuNO16g49+w=
X-Google-Smtp-Source: ACHHUZ4vLGnTrInFDuW/GuV5RjbQl25LdJQrYILv4jyRM2qJ8d+LIPmjIEbhyIpUxZohIyTK7ZHhuA==
X-Received: by 2002:a17:903:41d0:b0:1ad:55e6:16fe with SMTP id u16-20020a17090341d000b001ad55e616femr7530167ple.15.1683839352705; Thu, 11 May 2023 14:09:12 -0700 (PDT)
Received: from ?IPV6:2406:e003:1184:f001:abb6:ea4f:cf8e:1d0d? ([2406:e003:1184:f001:abb6:ea4f:cf8e:1d0d]) by smtp.gmail.com with ESMTPSA id b9-20020a170902650900b001a6dc4f4a8csm6442776plk.73.2023.05.11.14.09.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 May 2023 14:09:12 -0700 (PDT)
Message-ID: <841c38f0-cf9e-a1d1-b3a7-48e70f2b090a@gmail.com>
Date: Fri, 12 May 2023 09:09:06 +1200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
To: Vesna Manojlovic <BECHA@ripe.net>, e-impact@ietf.org
References: <CAPWZuKmxP3KEh0VQnEMz=-o8x1kuEdxUpLqifYvV8XGNh8kasA@mail.gmail.com> <f5464e05-ff18-05b9-b30a-95572daeaa4c@ripe.net>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <f5464e05-ff18-05b9-b30a-95572daeaa4c@ripe.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/e-impact/JZkCrLTorAM0Cd2_CEcDK3dXSyc>
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 <e-impact.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/e-impact>, <mailto:e-impact-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/e-impact/>
List-Post: <mailto:e-impact@ietf.org>
List-Help: <mailto:e-impact-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/e-impact>, <mailto:e-impact-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 May 2023 21:09:17 -0000

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-alives
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’s science-based
> target to reduce GHG emissions by 45% between 2020 and 2030.  "
> 
> The same source (International Energy Agency) shows growth in global ICT
> energy usage, despite the efficiency gains. (see attached)
> 
> 
> 
> And ITU recommended in 2020 to “reduce ICT GHG emissions by 45% by 2030”
> 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 the
> future, or in the other part of the world.
> 
> 
> Vesna
> 
>