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

Philip Levis <pal@cs.stanford.edu> Sun, 03 August 2014 17:28 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 0EAA91A0AF7; Sun, 3 Aug 2014 10:28:40 -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 HnbD7IcV_Kj5; Sun, 3 Aug 2014 10:28:38 -0700 (PDT)
Received: from smtp1.cs.Stanford.EDU (smtp1.cs.Stanford.EDU [171.64.64.25]) (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 4B6531A0AF6; Sun, 3 Aug 2014 10:28:38 -0700 (PDT)
Received: from [76.14.66.110] (port=62544 helo=[192.168.0.103]) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <pal@cs.stanford.edu>) id 1XDzaG-00057V-MZ; Sun, 03 Aug 2014 10:28:38 -0700
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <CADJ9OA_=FnuaaR_On_AJoqSVHfvUtcsxcM7WyLMR41AwQA5B-A@mail.gmail.com>
Date: Sun, 3 Aug 2014 10:28:39 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <9A525A33-FC53-4574-86F9-0FC4E8E5EC43@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> <CADJ9OA_=FnuaaR_On_AJoqSVHfvUtcsxcM7WyLMR41AwQA5B-A@mail.gmail.com>
To: Thomas Watteyne <watteyne@eecs.berkeley.edu>
X-Mailer: Apple Mail (2.1510)
X-Scan-Signature: e2fb03075b2557fb7882065b4eb34aa8
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/zndKI9Saf24zenoIxL2ibjvwvvc
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 17:28:40 -0000

Thomas,

This is great, thank you! Precise, technical statements. What I conclude from your text (correct me if I'm wrong):

1) If 802.15.4e uses maximum sized frames (127 bytes), the data communication time (reception or transmission) within a transmit slot is 80% of the total radio-on time. I appreciate that you separate the costs of the two sides (e.g., idle listening guard period on receive).

2) Following Xavier's analysis, using 127-byte frames means the RPL option increases data communication time by 4%. This means, from 1), that it will increase energy consumption by ~3.5%. Or, supposing his 8% number is correct (I still don't understand how he reached it), the energy consumption is increased by ~6.5%.

3) For smaller frames (e.g., the 50 bytes Xavier suggested), the idle listening on the receiver takes a larger fraction of the radio-on time, so his 10% number is too high.

4) None of these calculations consider the control overhead or, as you point out, inefficiencies in slot assignment. E.g., if you have a low-bandwidth, low-delay network, then you will allocate slots (for low latency) that you do not use (low bandwidth). For networks that are perfectly tuned, as you suggest, you can approach the transmission slot gains in 1) and 2). But they do not consider the costs and time of beacons or management time slots. Or radio wakeup overhead (dead time): my understanding is that on modern chips this is about 300us? I think your ACK timing considers RX/TX turnaround time. So in that way, 1) and 2) represent the absolute *best* savings this might give you. 

So my conclusion from this data is that, in the absolute best case -- assuming the radio is all of the system energy, you have a perfectly tuned TSCH schedule, etc., etc., using the flow label will save <10%, and often on the order of 5%. For simpler, less efficient and tuned MAC layers, the savings will be less.

5% or 10% isn't huge, but it is significant and valuable. I've just been a bit confused as to why this proposal has been trotted around for 4 years and yet no-one had yet even done this simple calculation, so WG members could make an informed engineering decision. IMO, a 5-10% savings in already highly tuned networks is above the bar and worth it. In most networks, the savings will be much less, but the benefits of reduced memory pressure and larger application payloads without fragmentation are more than sufficient motivation and justification of the value of the approach.

Phil



On Aug 2, 2014, at 8:36 PM, Thomas Watteyne <watteyne@eecs.berkeley.edu> wrote:

> 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
> --------------------------------------------------------------------
>