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

Thomas Watteyne <watteyne@eecs.berkeley.edu> Sun, 03 August 2014 03:37 UTC

Return-Path: <twatteyne@gmail.com>
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 3C94D1A00ED; Sat, 2 Aug 2014 20:37:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.622
X-Spam-Level: **
X-Spam-Status: No, score=2.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FB_CIALIS_LEO3=3.899, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-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 pP8hnxkJxyPs; Sat, 2 Aug 2014 20:37:05 -0700 (PDT)
Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA80D1A00EA; Sat, 2 Aug 2014 20:37:04 -0700 (PDT)
Received: by mail-pd0-f173.google.com with SMTP id w10so7695384pde.4 for <multiple recipients>; Sat, 02 Aug 2014 20:37:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=cswJ6EWhfSEatvVaLn4TLLDysFyCRVAS/unDHT5MEYk=; b=E/mBRPsg/frVzFmhSFOXlb0QE3hsfCRpy+keeGAwOZ7k1TJOrcBI+C6Z4CmW2BTQOF DOVwLuFHJEhmlTnB3QG3lqHNrKtC7NmL69EqwvLjmUmW3PIneTQsGKOiiwrNMBl4OOHG 29kbNfnt7WOCWnOhAuom0Qo3tl3nOh+GVgLzT22i+DI+34spFJC2uJB0PCGZKPkZqwEP upUDRF32jV6jYxNDJLuaSS97ufwAk7jbwolZlYOzaZUM5lJybCzuzlXD8LwrRog1kTh5 ABvxDispjuC/HlsSyQOzH/JbT5t1rfEJmubRN0wRUStzQduUsSrrzGzFejf6PX3+03bJ w9Xw==
X-Received: by 10.68.68.207 with SMTP id y15mr16122177pbt.25.1407037024445; Sat, 02 Aug 2014 20:37:04 -0700 (PDT)
MIME-Version: 1.0
Sender: twatteyne@gmail.com
Received: by 10.66.144.1 with HTTP; Sat, 2 Aug 2014 20:36:44 -0700 (PDT)
In-Reply-To: <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> <06C4F090-4731-4917-84F1-7C5798574F42@cs.stanford.edu>
From: Thomas Watteyne <watteyne@eecs.berkeley.edu>
Date: Sat, 02 Aug 2014 20:36:44 -0700
X-Google-Sender-Auth: odZ7zxR-YZSv4h907uuVZUeYPCo
Message-ID: <CADJ9OA_=FnuaaR_On_AJoqSVHfvUtcsxcM7WyLMR41AwQA5B-A@mail.gmail.com>
To: Philip Levis <pal@cs.stanford.edu>
Content-Type: multipart/alternative; boundary="001a11381772072a7504ffb156ea"
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/RvxgnfFAY268qG_zFw5stVFcPvs
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, "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: Sun, 03 Aug 2014 03:37:07 -0000

Phil,

There are two parts in answering your question. Let me describe both, I
will then justify why the answer is "it depends".

*a single slot*

Let's consider for starters only a single TSCH slot: mote A sends a packet
to mote B, which replies with an ACK. This timeslot is depicted below
(borrowed from [1])


      /------------------- Time Slot duration --------------------/
      |                                        /tsShortGT/        |
      |            |                              | | |           |
      |------------+-----------------+--------------+------+------|
   TX |            |    TX-Packet    |              |RX Ack|      |
      |------------+-----------------+--------------+------+------|
      |/tsTxOffset/|                 |              |      |      |
      |            |                 |              |      |      |
      |------------+-----------------+--------------+------+------|
   RX |         |  |  | RX-Packet    |              |TX Ack|      |
      |---------+--+--+--------------+--------------+------+------|
      |         |  |  |              |              |      |      |
      |        /tsLongGT/            |/TsTxAckDelay/|      |      |
     Start                                                       End
      of                                                          of
     Slot                                                        Slot


Let's assume that the IEEE802.15.4 frame is 127B long, i.e. full length.
Let's assume, finally, that you are using the default 10ms timeslot
template from the IEEE802.15.4e-2012 standard [2] (Table 52e), no CCA. This
is the radio-on time on both A and B:

   - mote A
      - transmitting the data packet: 4256us
      - listening for ACK during the guard time (i.e. idle listening): 200us
      - receiving the ACK (~15B long): 480us
   - mote B:
      - listening for data during the guard time (i.e. idle listening):
      1000us
      - receiving data: 4256us
      - transmitting the ACK: 480us

>From an energy point of view, you also need to account for the time is
takes to switch the radio on/off and for the possible energy consumed
between the data and ack, in case the radio is kept in a state allowing it
to TX/RX fast. Good embedded engineers will reduce this overhead through
firmware and hardware wizardry.

Considering only time, the radio on-time budget can hence be cut into:

   - total: 10672us
   - transmission of data: 8512us (~80%)
   - desynchronization overhead (i.e. idle listening during guard time):
   1200us (~10%)
   - ACK overhead: 960us (~10%)

>From these numbers, you see that the actual data transmission accounts for
~80% of the radio-on time budget.

Of course, this timeslot template is the default one. If you are very good
at keeping synchronized, you might be able to shorten the guard times and
reduce the desynchronization overhead.

*full network*

Now the fun part.

In a TSCH network, the communication schedule indicates to every mote what
to do: transmit, listen or sleep. You can tune the TSCH communication
schedule any way you want. In fact, the 6TiSCH WG was created to define
mechanisms for centralized and distributed managements of this schedule.

Your goal should be to match the amount of bandwidth in your schedule (i.e.
the cells used for transmission and reception) to what is needed by the
network. If every cell you schedule is used, the single slot results from
above carry over to a full network. If, however, you schedule has too many
cells, some might be unused. In that case, the transmitter will keep its
radio off (i.e. consume no energy), while the receiver will have to listen
for a full guard time, or 2ms when using the default timeslot template.

So there you go: it depends. In the best possible case, the portion of
radio on-time spent of exchanging actual useful data can be very high
(80%+), but it's easy to mess things up, resulting in a large number of
over-provisioned cells.

For a (hopefully clear) overview of IEEE802.15.4e TSCH, take a look at
http://tools.ietf.org/html/draft-ietf-6tisch-tsch-01.

Thomas

[1] http://tools.ietf.org/html/draft-ietf-6tisch-minimal-02
[2] http://standards.ieee.org/getieee802/download/802.15.4e-2012.pdf


On Sat, Aug 2, 2014 at 2:41 PM, Philip Levis <pal@cs.stanford.edu> wrote:

> 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
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>