Re: Network Energy Management

Phillip Hallam-Baker <phill@hallambaker.com> Sat, 06 August 2022 04:37 UTC

Return-Path: <hallam@gmail.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 63F7AC19E0EB for <ietf@ietfa.amsl.com>; Fri, 5 Aug 2022 21:37:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.412
X-Spam-Level:
X-Spam-Status: No, score=-1.412 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no autolearn_force=no
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 LwLe2WZ-b1fO for <ietf@ietfa.amsl.com>; Fri, 5 Aug 2022 21:37:32 -0700 (PDT)
Received: from mail-oi1-f181.google.com (mail-oi1-f181.google.com [209.85.167.181]) (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 B13B6C19E0E7 for <IETF@ietf.org>; Fri, 5 Aug 2022 21:37:32 -0700 (PDT)
Received: by mail-oi1-f181.google.com with SMTP id n133so4703343oib.0 for <IETF@ietf.org>; Fri, 05 Aug 2022 21:37:32 -0700 (PDT)
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=/+E/CSNWEQsyL3yXBlt75uzsx1vAsXqm35fXF8APd2g=; b=qvwYkfOmX0mlQjo16pivy3mr+zPQKqzR6df26WnysYfwfTqww4w5XZrbxDPOPtJ5aJ 1oANWlGtAv+Juou9uw6ViiAZY9RrOJnPyb8kpkTkJBwCe62mvg3i62fxYcDe09v5Gb1M HdYD2bHk6l7dxL2fIjUCVNTZ7E21pqNGH7UL22LnJ+m7ChUCP+cxVULgVf4IxkPNNTQb Y3RaULR+IbVEAEK6+V5PJ0L1GW7Yjx39Y+1Q1bmUmPpfUOf754mMNWoq8viB59zquMrn xAuCAQj8YHhHcfqf4na9GuHdxnfjP2ENvLMTOnDMrG6mrPOLw1P/h/kjvP1KyFLfn6XD wwCQ==
X-Gm-Message-State: ACgBeo13BN0r4Mi2AvVoiGhe0ZcKNxRE6tpug2QLAXKlDQfqdtRGSA2W pegYK4Q+2XDyophgNFIPAyliJo7Ubx1mPcGYjCE=
X-Google-Smtp-Source: AA6agR6oLyifHou6B6O14oeQOmmbKOuf/NKUsbQUUZe+upO29J54bqzY9ia+Nj8NKK+6T4hXrNUODeOGJCzku7IYv28=
X-Received: by 2002:a05:6808:124d:b0:322:3600:d84a with SMTP id o13-20020a056808124d00b003223600d84amr7555424oiv.108.1659760651721; Fri, 05 Aug 2022 21:37:31 -0700 (PDT)
MIME-Version: 1.0
References: <8FBAF87A-2690-4543-9713-0F22D1423B8E@gmail.com> <A8687A4E-BA7A-4375-B7E2-C57ADD396842@gmail.com> <CAFvDQ9r-G8O8dzYBvrdzorVHyAE=Edbb7FZkCzrhTzLh98DyAQ@mail.gmail.com> <8f308769-ad04-8f97-7a84-5f98ba27afee@joelhalpern.com>
In-Reply-To: <8f308769-ad04-8f97-7a84-5f98ba27afee@joelhalpern.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Sat, 06 Aug 2022 00:37:16 -0400
Message-ID: <CAMm+LwjrMwoB0Divd_LJx67KHjJY57A3ceDfLWg_wNw-5ad8XA@mail.gmail.com>
Subject: Re: Network Energy Management
To: Joel Halpern <jmh@joelhalpern.com>
Cc: Hesham ElBakoury <helbakoury@gmail.com>, Fred Baker <fredbaker.ietf@gmail.com>, IETF <IETF@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000ee0c805e58b24b4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/eMJPcUk8byirQPp5CFuAtb7TOa8>
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: Sat, 06 Aug 2022 04:37:33 -0000

On Fri, Aug 5, 2022 at 7:23 PM Joel Halpern <jmh@joelhalpern.com> wrote:

> I can't speak for Fred, but I don't think we as a community even know what
> "energy efficient protocol" means.  Much less how that trades off against
> all the other aspects of protocol design.
>

We do however know what a chronically wasteful protocol is.

BitCoin DELENDA EST!

I am serious. We should make sure that nothing the IETF does gives any
credibility to the people peddling proof of waste in any form. They are
using a greater quantity of electricity than some really large countries
and every kWh used for BitCoin, Ethereum etc. increases demand for
electricity and every kWh of additional demand is by definition met by
dispatchable sources which are all fossil fuels.

I am really, really fed up of the gaslighting and lies and especially the
greenwashing coming from the Criminal Currency community.

IETF could provide a notary chain scheme that does not depend on proof of
waste in any form. Cross notarization is more powerful than proof of work
which is a brittle approach based on faulty assumptions which I believe are
likely to be tested in the near future.

We do consider message size and frequency when we design protocols.  We
> consider those aspects along with lots of others.  if that is "designing
> energy efficient protocols" then we already do so.  On the other hand,
> design for issues such as to to partially wake up a sleeping device is
> generally outside our remit and skill set.  And is meaningless for many of
> our devices.
>
+1

There is a limit to what we can do at our layer of the stack and
particularly at this stage of the transition to zero fossil fuels. Not
least because electricity used by IT is really not that large considering
the impact on people's lives.

Where we can help is by delivering the technologies that the smart grid is
going to be needing as renewables capacity starts to saturate demand. At
that point the ability to offload demand from peak demand is going to be
really important for appliances like dishwashers, washing machines, BEVs
etc.

Another area that we might have a role in is verifying carbon offsets. Now
yes, there is an utterly stupid and offensive Ponzi currency 'carbon
credits' scheme which uses vast amounts of electricity. I mean a carbon
offset validation scheme that doesn't cause more carbon emissions than are
traded on it.


Offsets need not reduce quality of life. For example, roughly the same
quantity of kerosene that is used for aviation is used for lighting.
Hurricane lanterns are still widely used and they are inferior to LEDs in
every possible way; cost, health, safety, light output. Now imagine if each
time you book air travel with Expedia, you can check a box and a solar
rechargeable hurricane lantern costing a couple of bucks to make is
supplied to folk in Sudan/ Ghana etc. etc.