Re: [core] sleepy to sleepy communication I-Ds

Jari Arkko <jari.arkko@piuha.net> Mon, 05 March 2012 09:16 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745B021F85FD for <core@ietfa.amsl.com>; Mon, 5 Mar 2012 01:16:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.526
X-Spam-Level:
X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjXVCmTVPKIW for <core@ietfa.amsl.com>; Mon, 5 Mar 2012 01:16:53 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 8E96F21F867F for <core@ietf.org>; Mon, 5 Mar 2012 01:16:53 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 961C62DA06; Mon, 5 Mar 2012 11:16:51 +0200 (EET)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8JEbS-3vfkw; Mon, 5 Mar 2012 11:16:51 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id C1EA22CC3C; Mon, 5 Mar 2012 11:16:50 +0200 (EET)
Message-ID: <4F548482.9070707@piuha.net>
Date: Mon, 05 Mar 2012 11:16:50 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0
MIME-Version: 1.0
To: "Angelo P. Castellani" <angelo@castellani.net>
References: <9032C193-A015-4F41-B441-4D1D47594FC9@koanlogic.com> <4F53E746.7050401@piuha.net> <9B51E46C-D03D-4911-8D00-65B56DE48F63@koanlogic.com> <CAPxkH3jC3iznkVTRnYneVw2dny=HvS0gn3PaQ2KHJ-jmX55s0A@mail.gmail.com>
In-Reply-To: <CAPxkH3jC3iznkVTRnYneVw2dny=HvS0gn3PaQ2KHJ-jmX55s0A@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Cc: core WG <core@ietf.org>
Subject: Re: [core] sleepy to sleepy communication I-Ds
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Mar 2012 09:16:55 -0000

Angelo,

> Indeed sensor networks support sleeping using radio duty cycling at
> lower layers, this turns out in having the sleeping functionality
> without any loss of communication at the upper layers.
>

We discussed this a couple of IETFs back. Since then I've been doing some talking to our researchers who measure and improve power usage in radios.

First, duty cycling is already pretty widely used for radio technology. All cellular systems, for instance, turn off the radio except in during the time they listen for possible incoming paging signals, system information necessary to stay in contact at all, or when they have been granted a time slot to send.

Secondly and more importantly, per their measurements, even after all the above techniques, periodic listening for possibly incoming messages is the biggest consumer of energy in applications where we'd like to have a long battery life, such as in sensors. That power usage dwarfs everything else, so it has to come down, somehow, to make an improvement.

So if we want to achieve significantly longer battery lifetimes (and I claim we need those) we need to change some things. Obviously a lot of the link layers can be tuned better, implementing simply longer paging frequencies, for instance. My hypothesis is that we'll have to go longer than what typical application protocol timeouts are today, so the change would be something that is visible to applications. We could change some of the timeouts, but it is not clear that network buffers and all underlying mechanisms deployed today support those without changes. And in general, I think it is better to fit the communication model to the problem at hand than vice versa. As a result, I personally believe that we need to build applications that natively communicate in ways that make sleep modes easy. Such as publish-subscribe instead of direct request-response from anyone who needs the information. But like I said, this is a hypothesis and I'd love to be proven wrong.

Jari