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

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Toerless

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

True.
That was https://datatracker.ietf.org/doc/html/draft-ietf-roll-protocols-survey 
See also https://datatracker.ietf.org/doc/html/draft-levis-roll-overview-protocols

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

This is now captured here https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-over-wireless/ 

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

Exactly. Lessons learned etc...

Keep safe;

Pascal


> 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-pub
> > > lic/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]