I have seen several IETF drafts describing ideas to make the network more energy efficient. Why these drafts did not progress in IETF ? Is it because of lack of service providers support?
Hesham
On Fri, Aug 5, 2022, 7:59 AM Michael Richardson <mcr+ietf@xxxxxxxxxxxx> wrote:
Tim Bray <tbray@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxx> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
