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

[Hesham ElBakoury <[e-mail]>]

There are many publications about energy efficient protocol design for
wireless sensor networks. We can benefit from the ideas in these
publications when we design protocols for other type of networks.

Hesham

On Tue, May 16, 2023, 8:46 AM Manner Jukka <[e-mail]> wrote:

> Hi, I agree this is a hard case to solve, but something that needs to be
> done, over time.
>
> Your point about the same solution for constrained/unconstrained networks
> is very good, and nicely put.
>
> My latest works (years ago) were related to NSIS and RSVP, and in
> particular in NSIS (as in many other protocols), there was the baseline and
> extensions, binary encoded.
>
> Encoding is one thing, keep-alives and other such continuous signalling is
> another.
>
> I could see that there could be a place for a BCP that would discuss
> administrative, architectural and configuration topics that could lower at
> least a little bit the energy consumption and load in the networks.
>
> br,
> Jukka
>
> > On 16. May 2023, at 17.50, Toerless Eckert <[e-mail]> wrote:
> >
> > I hope we would have a hard time finding someone in the community to
> disagree
> > with these as principles. Alas, once we get to actual ideas what we could
> > still do beyond all that we have already done, work gets a lot harder.
> >
> > For example, is it really worthwhile for energy saving to ask the whole
> > JSON application layer world/standards we have to evolve to CBOR
> (binary) ?
> >
> > I think the energy saving in high-speed networks would be negligible and
> > likely outweight by the energy spent by the additional IETF efforts
> > meeting time, travel, brains involved,... do add CBOR definitions for
> > all the existing JSON work. And figure out interop.
> >
> > On the other hand, we are re-doing many protocols as "low-power" IoT
> > protocols after they've already been defined in high-speed networks,
> > so we already know (and hate) the drill. And alas, it is not only just
> > procedural but constrained networks/nodes/deployments do have additional
> > impacts on the protocols.
> >
> > So, maybe the question would be if we could reduce the amount of
> > duplicated work by requiring future non-constraineed protocol work to
> also
> > be built to support constrained environments from day 1. Which alas
> > today means that we need to bring communities within the IETF together
> > that so far haveworked often in separate silos. And that may have
> different
> > goals anyhow.
> >
> > Aka: This is certainly something that looks for an IETF strategy and/or
> > at least experiments.
> >
> > I bring up this example, because it was also raised several times
> > in the IAB workshop - and of course in my own working group we're also
> > redoing a lot of work across constrained/unconstrained networks, and
> > so i am always pondering if/how we could have done, or can do better
> > to avoid duplication ...
> >
> > Any good recent success stories from other WGs welcome - e.g.: where has
> > work that wanted to originally to be done unconstrained also taken
> > requirements from constrained networks into account ?
> >
> > Cheers
> >    Toerless
> >
> > On Tue, May 16, 2023 at 11:03:54AM +0300, Jari Arkko wrote:
> >> I just wanted to say that I agree with Jukka below:
> >>
> >>> Fundamentally, if networking equipment would have better scalability
> in terms of energy use per traffic and even sleeping modes, the IETF could
> at least
> >>>
> >>> a) look into making protocols and the signalling use less bytes, and
> >>> b) not prohibit hardware to go to sleep if no user traffic is being
> transmitted.
> >>>
> >>> For point a, I have not done the analysis, but expect that fy far most
> of the protocols are binary encoded, so already almost there. HTTP is not,
> for example. For point b, for example broadcasting and various keep-alives
> may prohibit sleep modes in hardware.
> >>>
> >>> This discussion should probably be moved to another thread, and not
> discussed under this debate on one metric.
> >>
> >> (There’s of course some additional things that we do discuss as well,
> such as measurements/awareness.)
> >>
> >> Jari
> >>
> >
> >> --
> >> 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
>