IETF Logo Mail Archive

Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03

Philip Levis <pal@cs.stanford.edu> Sat, 02 August 2014 21:41 UTC

Return-Path: <pal@cs.stanford.edu>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF6C1B29CB; Sat, 2 Aug 2014 14:41:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.302
X-Spam-Level:
X-Spam-Status: No, score=-0.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_CIALIS_LEO3=3.899, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=no
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 99jRnVlc69u2; Sat, 2 Aug 2014 14:41:14 -0700 (PDT)
Received: from smtp2.cs.Stanford.EDU (smtp2.cs.Stanford.EDU [171.64.64.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15F0A1B29DB; Sat, 2 Aug 2014 14:41:14 -0700 (PDT)
Received: from [76.14.66.110] (port=61141 helo=[192.168.0.103]) by smtp2.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <pal@cs.stanford.edu>) id 1XDh3A-0007pH-7T; Sat, 02 Aug 2014 14:41:14 -0700
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <6439.1407007393@sandelman.ca>
Date: Sat, 02 Aug 2014 14:41:12 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <06C4F090-4731-4917-84F1-7C5798574F42@cs.stanford.edu>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <53DB675C.9000502@tm.uka.de> <CAMsDxWTGG1MMaYPTcQqsBb78GuzsPun_k7r6Qi29fELp=z-mKA@mail.gmail.com> <53DB88B7.80205@tm.uka.de> <CAMsDxWROddNcfcWATpr4wmM+iMGhn4xMGO77f6hGvmRB9+Ow6g@mail.gmail.com> <B80833DA-CF92-4F84-91FA-A45A74B4D03D@cs.stanford.edu> <6439.1407007393@sandelman.ca>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
X-Mailer: Apple Mail (2.1510)
X-Scan-Signature: 127ff6e1eac6b45a32dc112250ed777d
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/rPYaT5s72xqNpKE9QJoK2RupJJc
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Aug 2014 21:41:15 -0000

On Aug 2, 2014, at 12:23 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

> 
> Philip Levis <pal@cs.stanford.edu> wrote:
>> The paper is very helpful, thanks! Can you comment on what is a typical
>> idle slot configuration in a TiSCH network? Can you provide some
>> insight on what fraction of energy is spent in data communication
>> versus control and idle listening?
> 
> Here is a recent post with some real numbers:
>  https://mailarchive.ietf.org/arch/msg/ipsec/TsI1OPGL-84AjZGB_RMyhqOPucY
> it concerns diet-ESP, but the numbers are correct.

Michael,

I'm confused on what this email message is supposed to be providing: the energy cost of sending a bit? That's pretty simple to calculate. The tradeoff between CPU and network is also very well known, going back to Pottie's "Every bit transmitted brings a sensor node one moment closer to death." If you look at the behavior of most micro controller based devices, the MCU is insignificant -- and 95% of its energy is spent handling interrupts (per-byte, over an SPI bus) for the radio. Yes, unless you're doing something quite silly, the CPU cost of compression is almost always absolutely worth the benefit in terms of reduced transmission energy.

My question related to the fraction of radio energy in TSCH that is consumed by data transmission/reception versus everything else (idle listening, guard periods, control frames, etc.

To give you a data point -- early low-power link layers continually transmitted a packet (or wakeup frame) until receiving an acknowledgement from the intended receiver. Receivers periodically wake up, listen if there's energy on the channel, and if so, stay awake for 2 packet times (in case they woke up just after the preamble of a packet). If there's no coordination between receiver and sender, this means a sender must send on average for 1/2 of a wakeup interval to deliver a packet. E.g., 0.5s. Clearly in such a protocol a few extra bytes doesn't matter in terms of energy. Of course, TSCH is much, much better than this, I only mention this protocol as a simple explanatory example -- but what's the actual number?

Phil

v2.23.0 | Report a Bug | By Email