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 publishedseveral RFCs. Of those, 6988 Requirements for Energy Management, and7326 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, NevilOn Sat, Aug 6, 2022 at 11:43 AM Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> 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 <fredbaker.ietf@xxxxxxxxx> 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 <stewart.bryant@xxxxxxxxx> wrote:
>> >
>> > Perhaps it is time for a new mandatory section in RFCs: sustainability?
>>
--
-----------------------------------
Nevil Brownlee, Taupo, NZ
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 <huitema@xxxxxxxxxxx> wrote:
