Re: Network Energy Management

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 05 August 2022 14:59 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 3113FC1907DE for <ietf@ietfa.amsl.com>; Fri, 5 Aug 2022 07:59:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.707
X-Spam-Level:
X-Spam-Status: No, score=-1.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=sandelman.ca
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 4ks7SkwdrJBe for <ietf@ietfa.amsl.com>; Fri, 5 Aug 2022 07:59:26 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 376B9C1388D2 for <ietf@ietf.org>; Fri, 5 Aug 2022 07:59:25 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 3EEEB389AD; Fri, 5 Aug 2022 11:18:15 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1NtZFSgMgGEs; Fri, 5 Aug 2022 11:18:14 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 8478D389AC; Fri, 5 Aug 2022 11:18:14 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1659712694; bh=lLbUGaCZowWX/vU2RyH9Wzu57OYEBLpwYxqDrKyhtVY=; h=From:To:Subject:In-Reply-To:References:Date:From; b=3YksjSrUSnTDQghc5xDXtfQxdbho3tFsbj701A4BXhUH308QYQBCO22qHTN0wLZcF +TBPSE2D1XcF5M5E/0eiV+sbQLQQm4Z+b9amYCzm5vdhASAj2UzDreoYh6QKmTvv7v xyqBOkCKXwafehsvMdRvEArj9X7FQ+KFAt+tNN4WAPB7GlM+DY08EpWw71vrx6Uny/ RZIEiVoMZ+cw5c0JUaMZs7Ys2LfVmzf8DSABW9ZjGvG9uo8/1n5CCtp5OjV1KrjiK/ imBs3zGv1PdGbM9VBLXdpuGi8wf0tRiLCDROELGMeMg8Aoe1D4bQizW9Su/F0e986c UWB22gfBZLzCw==
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DA157189; Fri, 5 Aug 2022 10:59:21 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Tim Bray <tbray@textuality.com>, Hesham ElBakoury <helbakoury@gmail.com>, IETF <ietf@ietf.org>
Subject: Re: Network Energy Management
In-Reply-To: <CAHBU6ivx0uQeM_Ug2Hfa2QMWp-toxqz=v=_+BM_41-yYSViX2Q@mail.gmail.com>
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> <CAHBU6ivx0uQeM_Ug2Hfa2QMWp-toxqz=v=_+BM_41-yYSViX2Q@mail.gmail.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 27.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Fri, 05 Aug 2022 10:59:21 -0400
Message-ID: <2720.1659711561@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/z4C93Xq0SlizCIOyY4tm-P0DjGA>
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 14:59:31 -0000

Tim Bray <tbray@textuality.com> wrote:
    > 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.

What about the edge/cloud computation mix.
I can see that AWS can't do a lot to reduce it's compute cost, but if your
AWS bill is a proxy for carbon load, then is it always better to send the
computation to the cloud in the first place?  I don't really expect AWS to
work on reducing it's revenue, but it seems that there might be a bigger
analysis here.

    > 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

+10.
Having read this thread, and considered the impact of turning off interfaces,
I come to some thoughts:
  a) I'd really like all interfaces to have a very low power mode in order to
  support RFC8994 ACPs for management.  (If only Rogers had such a thing)

  b) DTN, and CDN.  Mobile phones already practice a lot of delayed gratification to
  avoid LTE bills, preferring Wifi for big uploads/downloads.  There is no
  feedback from the network as to whether the phone has picked a good time,
  energy, congestion and disk bandwidth-wise for it to upload the latest
  selfie-fest to the cloud.   Imagine if the network and the end points could
  communicate about their expected future bandwidth needs.

  We do this at the per-packet TCP level, but maybe we should be doing this
  at a higher-level.

  We had this kind of thing in the stateful ATM VC world of the 1990s, but that was mostly
  driven by a desire to bill individual bits, which the settlement-free world
  of IP thought was dumb.

  c) more use of BT and PANs.  I tend to post my twitter, facebook, and
  emailed pictures from my laptop/desktop.  (why? because phones have no
  useful keyboards.  They remain largely consumption-only
  devices. Harumph. Crackberry/G1 please...)
  Yet I took them from my phone.

  To get the picture in... my phone uploads to cloud, my computer downloads
  from cloud, my computer them attaches and uploads to foo.  All this despite
  extensive OAUTH2 infrastructure from all parties, and all sorts of amazing
  URL schemes like ni: and did: that could probably do better.
  Eliminating two of those data transfers would be a big deal.

So I actually disagree with many on the thread: there is significant work for
the IETF to do.  1) measuring what the energy costs are (YANG..),
2) mapping the energy costs into actual flows so that users can get feedback
(a new TCP option? Maybe),  3) scalling number and (re-)active state of
interfaces to needed bandwidth need, 4) deferring/rescheduling transfers to
times of lower impact energy, 5) eliminating redundant transfers.

This all fits into 5Rs: refuse, reduce, reuse, repurpose, recycle.


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide