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
- Network Energy Management Hesham ElBakoury
- Re: Network Energy Management George Michaelson
- Re: Network Energy Management shogunx
- RE: Network Energy Management Tianran Zhou
- Re: Network Energy Management Hesham ElBakoury
- RE: Network Energy Management Tianran Zhou
- Re: Network Energy Management Joel Halpern
- RE: Network Energy Management Tianran Zhou
- Re: Network Energy Management George Michaelson
- Re: Network Energy Management Hesham ElBakoury
- Re: Network Energy Management George Michaelson
- Re: Network Energy Management Hesham ElBakoury
- Re: Network Energy Management Tim Bray
- Re: Network Energy Management Stewart Bryant
- Re: Network Energy Management Michael Richardson
- Re: Network Energy Management Hesham ElBakoury
- Re: Network Energy Management Hesham ElBakoury
- Re: Network Energy Management Fred Baker
- Re: Network Energy Management Michael Richardson
- Re: Network Energy Management Hesham ElBakoury
- Re: Network Energy Management Joel Halpern
- Re: Network Energy Management Brian E Carpenter
- Re: Network Energy Management Hesham ElBakoury
- Re: Network Energy Management shogunx
- Re: Network Energy Management Hesham ElBakoury
- Re: Network Energy Management Phillip Hallam-Baker
- Re: Network Energy Management Hesham ElBakoury
- Re: Network Energy Management Stewart Bryant
- Re: Network Energy Management - research paper Joel Halpern
- Re: Network Energy Management - research paper Hesham ElBakoury
- Re: Network Energy Management Nevil Brownlee
- Re: Network Energy Management Christian Huitema
- Re: Network Energy Management Phillip Hallam-Baker
- Re: Network Energy Management - research paper Simon Pietro Romano