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

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 03 Jul 2014 10:23:47 +0200

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

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Fri, 18 Jul 2014 21:25:43 +0200

Hi Hannes,

First of all, thanks for your review, comments and suggestions.

Please find a few inline replies:

> well.

There exist several other studies (some of which involve coauthors of the
draft). I agree that a wider range of studies should be considered in
order to derive common issues and important details which might be
generalized, as well as aspects that might not.

> It is also heavily focused on energy consumption of networking

Agreed. We can provide information regarding these aspects.

> parameters also assumes that you understand the radio technique very well.

I don't think we are trying to do a comparison. Nevertheless, which kind
of details do you feel would be needed? When you talk about parameters, do
you mean parameters of the radio technologies (i.e. mainly PHY/MAC
parameters)?

> anyway. Why did you pick those three radios and not others?

I believe the description of the radios can be extended.

Regarding your (good) question, I think other relevant radios can very
well be added to Section 3, and actually the draft is in progress. I am
not sure to what extent Section 3 has to be comprehensive technology-wise.
Of course, technologies considered in the 6lo WG are candidates. However,
there are two approaches: i) being comprehensive, or ii) trying to cover
what seem to be the most common low-power techniques used by these radios.
What would the WG prefer?

> renamed to Bluetooth Smart)

(Yes, the Bluetooth SIG has introduced these trademarks, while the recent
Bluetooth 4.1 specification still uses the name "Bluetooth Low Energy".)

> does not provide the reader much insight

The section about BT-LE tries to focus on the layers relevant for using IP
over BT-LE. As per draft-ietf-6lo-btle-02, the 6LoWPAN layer is placed on
top of a stack composed of L2CAP (which in BLE provides upper layer
multiplexing and fragmentation/reassembly), Link Layer and Physical Layer.
>From these layers, the main configurable parameters with a highly
significant impact on energy (and other parameters) performance are those 
from the Link Layer which the section focuses on.

Also, the master/slave terminology has its nature at the Link Layer (and
corresponds to the central and peripheral GAP roles), but is key to
understand the role of a device in a BT-LE network.

> wireless communication more or less replaces cables.

Well, we are trying to change that with draft-ietf-6lo-btle, as well as
with the other efforts of the 6lo WG. ;)

> empty. It is also not clear whether you will be able to say too much

Agreed. Although some information about possible cross-layer interactions
is already in some of these sections, more information in this area would
provide a lot of value to the draft.

> you can use to fine-tune but there will always be tradeoffs.

Probably, the point is to highlight those tradeoffs, and which are the
parameters controlling them, which may provide useful information to
designers/developers.

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

Probably it is, but I think a key aspect is to show which cross-layer
interactions take place in this space. I was not a coauthor of the first
versions of the draft, but I believe one of the goals was to offer an RFC
3819-like approach, in an inverse way: how radio technologies affect and
interact with possible upper layers.

> energy consumption. Would it be useful to cover other publications as

Yes, I think so, at least, to see whether there are relevant commonalities
and differences accross using different platforms/technologies.

Best regards,

Carles

> Ciao
> Hannes
>
>
>
> _______________________________________________
> Lwip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lwip
>