Re: Network Energy Management

[Phillip Hallam-Baker <[e-mail]>]

I did my part, just think how many petabytes of data are being saved every
day because the referer field only has one r.

On Sun, Aug 7, 2022 at 10:20 AM Christian Huitema <[e-mail]>
wrote:

> 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
>
>