Re: Network Energy Management

[Hesham ElBakoury <[e-mail]>]

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 <[e-mail]>
wrote:

>
> Tim Bray <[e-mail]> 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 <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
>