Re: Network Energy Management

[Christian Huitema <[e-mail]>]

The IETF per se may or may not have experience in energy management. 
Many of us, on the other hand, have experience in a related field, 
performance optimization, and specifically performance optimization of 
software systems. That experience has taught us a set of simple rules 
and methods:

1) Avoid early optimization.

2) Measure

3) Find the hot spots.

4) Fix the hot spots

5) Repeat 2-4 until satisfied.

I could think how a similar methodology would be used to manage energy 
consumption. The IETF should of course avoid gross mistakes in 
specification, but mostly the problem is in the hands of people 
implementing and developing systems. They are the ones capable of 
measuring consumption and of finding hot spots.

In most cases, performance issues can be fixed locally. But in some 
cases the issue can be traced to the specification. That will probably 
be true for energy consumption as well. In most cases, it won't be about 
the specification, but in some cases it might. And in those cases, the 
IETF will have to quickly fix the specification.

-- Christian Huitema


On 8/6/2022 5:15 PM, Nevil Brownlee wrote:
> Ahem, the IETF did have an Energy Management WG, eman, which published
> several RFCs.  Of those, 6988 Requirements for Energy Management, and
> 7326 Energy Management Framework, seem relevant to this thread.
> Of course, eman focussed on device management rather than protocol 
> design - but that now seems important too.
> Cheers, Nevil
> On Sat, Aug 6, 2022 at 11:43 AM Brian E Carpenter 
> <[e-mail]> wrote:
>
>     Two points:
>
>     1. It might be worth an effort to see if there are existing knobs
>     to tweak for sustainability. For example, every recommended
>     repetition rate for discovery or refresh messages, especially
>     multicast, could be reviewed to see if it can usefully be slowed
>     down. Every link-local protocol could be reviewed for
>     compatibility with wake-on-LAN.
>
>     2. Network Energy Management could be a good topic for an IAB
>     workshop or program.
>
>     Not a joke: before investing much effort in this topic, we should
>     consider whether that effort (e.g. convening a workshop) will
>     consume more energy than it saves.
>
>     Regards
>         Brian
>
>     On 06-Aug-22 11:22, Joel Halpern wrote:
>     > I can't speak for Fred, but I don't think we as a community even
>     know what "energy efficient protocol" means. Much less how that
>     trades off against all the other aspects of protocol design.
>     >
>     > We do consider message size and frequency when we design
>     protocols.  We consider those aspects along with lots of others.
>     if that is "designing energy efficient protocols" then we already
>     do so.  On the other hand, design for issues such as to to
>     partially wake up a sleeping device is generally outside our remit
>     and skill set.  And is meaningless for many of our devices.
>     >
>     > Yours,
>     >
>     > Joel
>     >
>     > On 8/5/2022 7:18 PM, Hesham ElBakoury wrote:
>     >> Hi Fred,
>     >> Do you think  IETF engineers have the skill sets to design
>     energy efficient protocols or enhance existing ones to be more
>     energy efficient ?
>     >>
>     >> Thanks,
>     >> Hesham
>     >>
>     >> On Fri, Aug 5, 2022, 1:22 PM Fred Baker
>     <[e-mail]> wrote:
>     >>
>     >>     Echoing a previous post, I’m not sure sustainability is
>     part of our skill set. If we were to try to forcibly add it, I
>     suspect we’d get the same level of response security originally
>     got: “sustainability is not specified in this document”.
>     >>
>     >>     Sent using a machine that autocorrects in interesting ways...
>     >>
>     >>     > On Aug 5, 2022, at 2:26 AM, Stewart Bryant
>     <[e-mail]> wrote:
>     >>     >
>     >>     > Perhaps it is time for a new mandatory section in RFCs:
>     sustainability?
>     >>
>
>
>
> -- 
> -----------------------------------
> Nevil Brownlee, Taupo, NZ