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

[Hesham ElBakoury <[e-mail]>]

Here is a paper on "*Routing Protocols for Low Power and Lossy Networks in
Internet of Things Applications"* [https://www.mdpi.com/1424-8220/19/9/2144]

This paper concludes as follows:
"Although the RoLL working group has defined RPL as the standard routing
protocol for LLNs, several works have shown that the solution presents
severe limitations and drawbacks. Thus, various new solutions studied in
the course of this document have emerged in recent years trying to mitigate
the existent routing issues. The currently-proposed enhancements are
designed, in general, to solve problems related to P2P and mobility
support, multicast data forwarding, energy efficiency, and QoS improvement.
However, it is important to note that these new routing solutions are for
the IoT/LLN
network, as they are not limited to RPL enhancements. LOADng and its
advances have emerged as a potential solution, especially for P2P
communication, though it is much less studied than RPL in the
recent literature."

Hesham


On Fri, May 12, 2023, 8:22 AM Pascal Thubert (pthubert) <pthubert=
[e-mail]> wrote:

> 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]
> --
> E-impact mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/e-impact
>