[Lwip] draft-ietf-lwig-energy-efficient-00

[Hannes Tschofenig <[e-mail]>]

Hi all,

I took a quick look at this document. Clearly this is an important topic
but it is also challenging.

When this topic was brought up at the IAB smart object workshop I was
thinking about what guidelines I would offer and I came up with very few
ideas. So, I was very interested to see what the authors have to say
about this topic.

A few aspects came to my mind when reading the document:

a) The current discussion seems to focus on a single study only. I hope
that's not true and the authors have done some studies themselves as
well. It is also heavily focused on energy consumption of networking
only. RAM costs energy. Computations cost energy. Even sleeping costs
energy. For embedded hardware there is not just a binary sleep/awake
mode but many intermediate steps.

b) The comparison between different radio technologies would require far
more details to be useful since there are many parameters that have an
impact on the overall energy consumption. Selecting the right set of
parameters also assumes that you understand the radio technique very well.

c) This is mostly a non-IETF topic. The IETF does not design radio
technologies, nor does it impact the hardware design or focus on
implementations. I agree with the statement that it is good to know the
behaviors of lower layers. What would, however, then be needed is a
tutorial on various radio technologies since they are often written in a
way that is very different from IETF specifications and somewhat hard to
understand for IETF-minded folks. There is text in there in Section 3
about the different radios but it is too short to be understood by
someone who does not yet already know the specific radio technology
anyway. Why did you pick those three radios and not others?

As an example, the text about Bluetooth Low Energy (which has been
renamed to Bluetooth Smart) does not provide the reader much insight
into the implications for the protocol design. Bluetooth Smart is
different from Bluetooth and the specification defines an entire
protocol stack. The required energy of a device depends on the function
and on the parameter setting at each layer. Hence, it is a bit difficult
to just focus on master / slave (terminology used for only one layer).

It might also be worth pointing out that not all radio technologies used
today are actually using IP. Bluetooth Smart is a good example that
enjoys widespread deployment but there is almost no IP there since the
wireless communication more or less replaces cables.

d) The sections about routing protocols(Section 5), application layer
(Section 6) and Cross Layer Optimization (Section 7) are currently a bit
empty. It is also not clear whether you will be able to say too much
there either.

Summary Section

The document provides a summary section explaining the goals of the
document. That's good. Let me compare the goals outlined in the summary
section with the rest of the document.

  a.  All Internet protocols, which are in the scope of the IETF, are
       customers of the lower layers (PHY, MAC, and Duty-cycling).  In
       order to get a better service, the designers of higher layers
       should know them better.

--> The current document does not describe the different radio
technologies in a sufficient level of detail so that protocol designers
can take practical actions. Even if they know the radio technology
better what conclusions should be drawn? Most likely the answer is that
it depends what your product is going to do. You have some parameters
you can use to fine-tune but there will always be tradeoffs.

   b.  The IETF has developed multiple protocols for constrained
       networked devices.  A lot of implicit energy efficient design
       principles have been used in these protocols.

--> Do you think it is useful to provide a survey of the IETF IoT/smart
object work?

   c.  The power trace analysis of different protocol operations showed
       that for radio-duty-cycled networks broadcasts should be avoided.
       Saving unnecessary states maintenance is also an effective method
       to be energy-friendly.

--> There are a few recommendations for protocol designers but they are
all rather obvious:
  * don't use broadcast/multicast
  * don't communicate too often and communicate as little as possible
  * don't act as server (if you can) since listening costs money
  * sleep, sleep, sleep.

What the document currently also does is to summarize one publication on
energy consumption. Would it be useful to cover other publications as well?

Ciao
Hannes