Re: [E-impact] kWh/GB should be banned and the IETF should warn against its use

[Toerless Eckert <[e-mail]>]

Pascal,


On Fri, May 12, 2023 at 06:24:42AM +0000, Pascal Thubert (pthubert) wrote:
> Hello Brian and Carsten 
> 
> >> (Did 6LOWPAN, LPWAN or ROLL already analyse such questions?)
> > 
> > The WGs I don’t know, but the literature looks at power use a lot, because that is a measurable quantity and therefore great for getting graphs into research papers.
> 
> ROLL analyzed the energy performance of existing protocols before designing its own. We showed that existing protocols did not meet the needs of constrained LLN devices. The document did not make RFC but it is still there. 

If you could find the name of that draft, that would be a great find 
to add to draft-eckert-ietf-and-energy-overview.

> RPL (RfC 6550) was born with a collection of design points aimed at saving energy. For instance: anisotropic routing P2MP and MP2P, routing stretch for least used routes, Trickle, proactive route installation but lazy/reactive route maintenance. RPL demonstrates that a protocol can really be designed with energy in mind. It’s really sad that homenet decided to ignore it, a missed opportunity when both energy and sensor connectivity should have been considered in the use cases.
> 
> Same goes for 6LoWPAN. While compression was the low hanging fruit, compression alone could never be enough to meet the energy goals for long lasting battery operated IPv6 devices. 
> 
> To save energy, the communication interfaces must be offline as much as possible when not in use for data transfer. Meaning that there cannot be asynchronous messages anytime that the device must respond on the spot. Which sadly is the case of DAD and NS lookup in RFC 4861. So the basic operation of IPv6 ND had to be revisited. This is why 6LoWPAN came up with a new protocol operation for ND that minimizes the use of broadcast with RFCs 6775 / 8505. That was not a low hanging fruit and is one the most important outcomes of the IoT efforts in INT area.

And if i remember the history correctly, these ND challenges with
way-too-often waking up all hosts was also recognized to be a
battery-lifetime challenge for much higher powered mobile phones on
WiFi networks.  Especially in LANs with a lot of hosts, such as the wifi
during the IETF meetings themselves.

So IMHO, it seems to be a good idea to proactively track what low-power
environments are working out as problems/solution, and even if you do not
work in low-power environments, try to extrapolate if/how these problems
might also reflect in your own environments.

Cheers
    Toerless

> Another angle of the same issue is at the MAC layer how to arrange a rdv point for a sender and a listener to be both active at the same time. 6TiSCH provides a full architecture of how to do IPv6 over a time synchronized MAC, which is harder to achieve but best of breed for energy savings. RAW is now extending that work to provide DetNet type of redundancy while optimizing spectrum and battery.
> 
> Bottom line is that, yes, we can design with energy in mind. We’ve done a lot of that in those groups. It is my hope that we do not replicate the homenet failure at 6MAN and we effectively generalize the 6LoWPAN ND approach to networks like Ethernet and WiFi. Because even if energy is available, wasting it in bad protocol designs at the scale of IPv6 devices is irresponsible in the face of the challenges of sustainability and climate.
> 
> All the best,
> 
> Pascal
> 
> > Le 12 mai 2023 à 02:32, Carsten Bormann <[e-mail]> a écrit :
> > 
> > 
> >> 
> >> 
> >> For example, for a given technology, we could ask: what is the ratio
> >> between energy consumed when doing nothing and energy consumed when
> >> operating at full capacity? How do we maximize that ratio?
> > 
> > By increasing the energy consumed when operating at full capacity, of course.
> > 
> > I think we’ll need a different approach at rating idle power consumption.
> > 
> > Assuming that P = ax + b, where x is the amount of service used:
> > 
> > People who are deciding whether to consume a specific service at any specific point in time are interested in `a` only (marginal cost), because their decision impacts only the linear component until the service reaches capacity (at which time both the stairstep effect and the effect of reduced power consumption by scale and innovation are felt).
> > People have argued that `a` is generally surprisingly small.
> > 
> > People who are deciding whether to invest in a service offering (literally by funding it or by subscribing to it, possibly at a flat rate turning their direct `a` to zero) will also want to look at `b`.
> > 
> >> For a given protocol, we could ask: what is the minimum rate of keep-alives
> >> for acceptable performance?
> > 
> > That is then part of `b` (and reduces `a`!).
> > 
> >> It gets more complicated when you consider (for example) compression.
> >> Does compression (for a given protocol) save more energy during transmission
> >> than it costs during compression and decompression at each end?
> > 
> > That, however, should be easy to measure for a specific service environment.
> > (It also is likely irrelevant except for the cases below, because most traffic is video and video already is heavily compressed.  That is actually getting better, contributing to the overall reduction in power need.)
> > 
> >> How does an encoding like CBOR compare to traditional TLVs, considering
> >> both energy for transmission and energy for encoding and decoding?
> >> How much energy does SCHC save?
> > 
> > If all power is the same cost (monetary and environmentally), probably negligible (see video argument above).
> > However, constrained environments often have multiple orders of magnitude more energy cost (environmental impact of primary batteries and the work needed to change them vs. mains power), so it does make sense to optimize those more.
> > 
> >> (Did 6LOWPAN, LPWAN or ROLL already analyse such questions?)
> > 
> > The WGs I don’t know, but the literature looks at power use a lot, because that is a measurable quantity and therefore great for getting graphs into research papers.
> > 
> >>> And, more importantly, how are we going to decrease the energy use?
> >> 
> >> We, the IETF, need some design guidelines for our protocols. And we
> >> should stick to that and not try to discuss more general aspects,
> >> because that will get us nowhere, IMHO.
> > 
> > I think that guideline will mostly reduce to “don’t do more premature pessimization” ([1] is one paper arguing for an easy win in many environments; I’m sure there are many more of those wins of this kind).
> > 
> > And maybe 7322bis can introduce an “environmental considerations” section, with the understanding that this usually will discuss impacts on power consumption.
> > 
> > Grüße, Carsten
> > 
> > [1]: https://raw.githubusercontent.com/intarchboard/e-impact-workshop-public/main/papers/Moran-Birkholz-Bormann_Sustainability-considerations-for-networking-equipment.pdf.pdf
> > 
> > -- 
> > E-impact mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/e-impact
> -- 
> E-impact mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/e-impact

-- 
---
[e-mail]