Re: Network Energy Management

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux