Re: [Lwip] draft-ietf-lwig-energy-efficient-00
"Carles Gomez Montenegro" <carlesgo@entel.upc.edu> Fri, 18 July 2014 19:25 UTC
Return-Path: <carlesgo@entel.upc.edu>
X-Original-To: lwip@ietfa.amsl.com
Delivered-To: lwip@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38791A008F for <lwip@ietfa.amsl.com>; Fri, 18 Jul 2014 12:25:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.1
X-Spam-Level:
X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edGSuQME-ILf for <lwip@ietfa.amsl.com>; Fri, 18 Jul 2014 12:25:49 -0700 (PDT)
Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3CEF1B2A28 for <lwip@ietf.org>; Fri, 18 Jul 2014 12:25:48 -0700 (PDT)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id s6IJPhr6022289; Fri, 18 Jul 2014 21:25:43 +0200
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id CE1CA2CBD0E; Fri, 18 Jul 2014 21:25:42 +0200 (CEST)
Received: from 81.39.211.168 by webmail.entel.upc.edu with HTTP; Fri, 18 Jul 2014 21:25:43 +0200
Message-ID: <45f1eac6891c8a6595d3ab1b6a56be86.squirrel@webmail.entel.upc.edu>
In-Reply-To: <53B51313.9020406@gmx.net>
References: <53B51313.9020406@gmx.net>
Date: Fri, 18 Jul 2014 21:25:43 +0200
From: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Mail-Scanned: Criba 2.0 + Clamd
X-Greylist: ACL matched, not delayed by milter-greylist-4.4.3 (violet.upc.es [147.83.2.51]); Fri, 18 Jul 2014 21:25:43 +0200 (CEST)
Archived-At: http://mailarchive.ietf.org/arch/msg/lwip/xha9uKkgb2WDWGf0svwYQHvCMvw
Cc: lwip@ietf.org
Subject: Re: [Lwip] draft-ietf-lwig-energy-efficient-00
X-BeenThere: lwip@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Lightweight IP stack <lwip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lwip>, <mailto:lwip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lwip/>
List-Post: <mailto:lwip@ietf.org>
List-Help: <mailto:lwip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lwip>, <mailto:lwip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Jul 2014 19:25:53 -0000
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 >
- [Lwip] draft-ietf-lwig-energy-efficient-00 Hannes Tschofenig
- Re: [Lwip] draft-ietf-lwig-energy-efficient-00 Carles Gomez Montenegro