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

Hi Hannes,

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

Please find a few inline replies:

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

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

Agreed. We can provide information regarding these aspects.

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

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)?

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

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?

> As an example, the text about Bluetooth Low Energy (which has been
> 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
> 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).

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.

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

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

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

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.

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

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

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

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.

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

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
> Lwip@ietf.org
> https://www.ietf.org/mailman/listinfo/lwip
>