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 > [email protected] > https://www.ietf.org/mailman/listinfo/lwip > _______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
