Subject: Re: [6tisch] 6tisch Digest, Vol 9, Issue 19

From: Martin Turon <[email-masked]>
Date: Thu, 12 Jun 2014 22:24:33 -0700

Hi All,

Another thing to consider besides the TelosB SPI speed issue is whether the
various platforms can handle the time slot size when security is on.  Can
the HW perform the necessary AES encryption/decryption on the largest 127
byte packet in time for the highly synchronized ACK?

Perhaps a generating a matrix would help, and use crowd source the OpenWSN
community to fill it out:

  PLATFORM   15ms    15ms w/security   10ms   10ms w/security
  TelosB (MSP430)   Y   ?   N   N
  OpenMote (M3)   Y   ?   ?   ?
  M0 based         
  8051 based       
  Š                

Networks with different slot sizes aren¹t going to be interoperable, so the
hope is that one of these slot sizes will ³win².  If there is a compelling
case that 10ms w/security is feasible on the lion share of platforms (both
SoC and MCU+RF), then it makes sense to switch now before it is too lateŠ

Martin

________________________________________

Martin Turon  |  Nest Labs

---------- Forwarded message ----------
From: Xavier Vilajosana <[email-masked]>
To: Kris Pister <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Rene Struik <[email-masked]>
Date: Thu, 12 Jun 2014 05:24:42 +0200
Subject: Re: [6tisch] minimal slot length
Hi,
my 5 cents... 

the only consideration that I see is if when reducing the slot size to 10ms
we are discarding some widely used 8bit and 16bit micro-controllers that
cannot run so fast *to check which ones and see the impact*. The workaround
might be to indicate in the draft that it is recommended to use 10ms slots
but in very constrained or slow devices this can be changed to other values
bearing in mind that thiese devices would not be able to inter-operate with
faster ones if slotframe size is not advertised.

what do you think?

X

---

From: "Turner, Randy" <[email-masked]>
Date: Fri, 13 Jun 2014 06:03:46 +0000

15.4g can support the IPv6 min mtu of 1280 bytes (and a bit larger) which is what most future chipsets will support so the worst case processing latency is larger than 127 bytes

Randy

On Jun 13, 2014, at 1:24 AM, "Martin Turon" <[email-masked]<mailto:[email-masked]>> wrote:

Hi All,

Another thing to consider besides the TelosB SPI speed issue is whether the various platforms can handle the time slot size when security is on.  Can the HW perform the necessary AES encryption/decryption on the largest 127 byte packet in time for the highly synchronized ACK?

Perhaps a generating a matrix would help, and use crowd source the OpenWSN community to fill it out:

PLATFORM

15ms

15ms w/security

10ms

10ms w/security

TelosB (MSP430)

Y

?

N

N

OpenMote (M3)

Y

?

?

?

M0 based

8051 based

...

Networks with different slot sizes aren't going to be interoperable, so the hope is that one of these slot sizes will "win".  If there is a compelling case that 10ms w/security is feasible on the lion share of platforms (both SoC and MCU+RF), then it makes sense to switch now before it is too late...

Martin

Martin Turon  |  Nest Labs

---------- Forwarded message ----------
From: Xavier Vilajosana <[email-masked]<mailto:[email-masked]>>
To: Kris Pister <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Rene Struik <[email-masked]<mailto:[email-masked]>>
Date: Thu, 12 Jun 2014 05:24:42 +0200
Subject: Re: [6tisch] minimal slot length
Hi,
my 5 cents...

the only consideration that I see is if when reducing the slot size to 10ms we are discarding some widely used 8bit and 16bit micro-controllers that cannot run so fast *to check which ones and see the impact*. The workaround might be to indicate in the draft that it is recommended to use 10ms slots but in very constrained or slow devices this can be changed to other values bearing in mind that thiese devices would not be able to inter-operate with faster ones if slotframe size is not advertised.

what do you think?

X

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.

---

From: Martin Turon <[email-masked]>
Date: Thu, 12 Jun 2014 23:06:43 -0700

Ok, well that would be an argument for keeping the slot size longer I think.
My understanding is that a 10ms slot would be optimized for ³classic 2.4GHz
15.4²: 250kbs with 127 byte maximum packet size.

Martin Turon  |  Nest Labs

From:  "Turner, Randy" <[email-masked]>
Date:  Thursday, June 12, 2014 at 11:03 PM
To:  Martin Turon <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  Re: [6tisch] 6tisch Digest, Vol 9, Issue 19

15.4g can support the IPv6 min mtu of 1280 bytes (and a bit larger) which is
what most future chipsets will support so the worst case processing latency
is larger than 127 bytes

Randy

On Jun 13, 2014, at 1:24 AM, "Martin Turon" <[email-masked]> wrote:

> various platforms can handle the time slot size when security is on.  Can the
> HW perform the necessary AES encryption/decryption on the largest 127 byte
> packet in time for the highly synchronized ACK?
> 
> PLATFORM15ms 15ms w/security10ms10ms w/security
> TelosB (MSP430)Y?NN
> OpenMote (M3)Y???
> M0 based    
> 8051 based    
> Š    
> 
> case that 10ms w/security is feasible on the lion share of platforms (both SoC
> and MCU+RF), then it makes sense to switch now before it is too lateŠ
> 
> Martin
> 
> the only consideration that I see is if when reducing the slot size to 10ms we
> are discarding some widely used 8bit and 16bit micro-controllers that cannot
> run so fast *to check which ones and see the impact*. The workaround might be
> to indicate in the draft that it is recommended to use 10ms slots but in very
> constrained or slow devices this can be changed to other values bearing in
> mind that thiese devices would not be able to inter-operate with faster ones
> if slotframe size is not advertised.
> 
> what do you think?
> 
> X
> 
> 
> 
> 
>> [email-masked]
> This e-mail (including any attachments) is confidential and may be legally
> privileged. If you are not an intended recipient or an authorized
> representative of an intended recipient, you are prohibited from using,
> copying or distributing the information in this e-mail or its attachments. If
> you have received this e-mail in error, please notify the sender immediately
> by return e-mail and delete all copies of this message and any attachments.
> Thank you. 
> 
>

---

From: anand <[email-masked]>
Date: Fri, 13 Jun 2014 13:17:21 +0530

Hi,

When we tried Brian Gladman's public domain AES encryption 
implementation on TelosB mote few years back, we found that 
encryption/decryption took 10s of ms of time. Of course, we may have to 
repeat this exercise to ascertain this, but gives an idea on what to expect.

On another note, we also need to consider task/scheduler implementation 
of the OS, that runs on the stack limited mote platforms.  The 
synchronized ACK mechanism calls for real-time guarantees from an 
implementation, which could mean task pre-emption, interrupt handling 
issues, race conditions and so forth. It is scary and challenging :) 
Perhaps there is nothing new I am stating here, but nevertheless  
important from the OS architecture point of view.

Anand

On 06/13/2014 10:54 AM, Martin Turon wrote:
> Hi All,
>
> Another thing to consider besides the TelosB SPI speed issue is 
> whether the various platforms can handle the time slot size when 
> security is on.  Can the HW perform the necessary AES 
> encryption/decryption on the largest 127 byte packet in time for the 
> highly synchronized ACK?
>
> *PLATFORM*
> *15ms *
> *15ms w/security*
> *10ms*
> *10ms w/security*
> Networks with different slot sizes aren't going to be interoperable, 
> so the hope is that one of these slot sizes will "win".  If there is a 
> compelling case that 10ms w/security is feasible on the lion share of 
> platforms (both SoC and MCU+RF), then it makes sense to switch now 
> before it is too late...
>
> Martin
>
> the only consideration that I see is if when reducing the slot size to 
> 10ms we are discarding some widely used 8bit and 16bit 
> micro-controllers that cannot run so fast *to check which ones and see 
> the impact*. The workaround might be to indicate in the draft that it 
> is recommended to use 10ms slots but in very constrained or slow 
> devices this can be changed to other values bearing in mind that 
> thiese devices would not be able to inter-operate with faster ones if 
> slotframe size is not advertised.
>
> what do you think?
>
> X
>
>
>
>
>
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: Kris Pister <[email-masked]>
Date: Fri, 13 Jun 2014 10:32:53 -0700

Martin -
  I think that all 802.15.4 RF chips include a hardware AES accelerator, so
the computational overhead of security is minimal.

As far as filling in the table, the row of interest is really "TelosB at 
4MHz", in which case
there's an N for the 10ms slot.  The same hardware gets a Y at 8MHz, 
even with security
and 10ms.  We did that at Dust around 2006 before we had our own silicon.

TelosB, 4MHz: YYNN
TelosB, 8MHz: YYYY
Openmote: YYYY
Any single-chip 802.15.4 chip, even with an 8051: YYYY ?  I assert that 
this is true, and
haven't seen any evidence to the contrary.  But that's what why I asked 
the question.

ksjp

---

From: Kris Pister <[email-masked]>
Date: Fri, 13 Jun 2014 10:42:56 -0700

Randy -
  I'd love to see a draft on  "4e/4g minimal", which would probably have 
a big impact.

Xavi and my draft is specific to the original 2.4GHz 15.4-2006 PHY.

ksjp

On 6/12/2014 11:03 PM, Turner, Randy wrote:
> 15.4g can support the IPv6 min mtu of 1280 bytes (and a bit larger) 
> which is what most future chipsets will support so the worst case 
> processing latency is larger than 127 bytes
>
> Randy
>
>
>
>> so the hope is that one of these slot sizes will "win".  If there is 
>> a compelling case that 10ms w/security is feasible on the lion share 
>> of platforms (both SoC and MCU+RF), then it makes sense to switch now 
>> before it is too late...
>>
>> Martin
>>
>> To: Kris Pister <[email-masked] <mailto:[email-masked]>>
>> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] 
>> <mailto:[email-masked]>>, Rene Struik <[email-masked] 
>> <mailto:[email-masked]>>
>> the only consideration that I see is if when reducing the slot size 
>> to 10ms we are discarding some widely used 8bit and 16bit 
>> micro-controllers that cannot run so fast *to check which ones and 
>> see the impact*. The workaround might be to indicate in the draft 
>> that it is recommended to use 10ms slots but in very constrained or 
>> slow devices this can be changed to other values bearing in mind that 
>> [email-masked] <mailto:[email-masked]>
> This e-mail (including any attachments) is confidential and may be 
> legally privileged. If you are not an intended recipient or an 
> authorized representative of an intended recipient, you are prohibited 
> from using, copying or distributing the information in this e-mail or 
> its attachments. If you have received this e-mail in error, please 
> notify the sender immediately by return e-mail and delete all copies 
> of this message and any attachments. Thank you.
>
>
>

---

From: "Turner, Randy" <[email-masked]>
Date: Fri, 13 Jun 2014 18:32:14 +0000

Me too :)  I can probably follow up with something that I think would be more forward-looking based on 4g/4e, which from my biased perspective (AMI, SmartGrid, etc.) is much more IPv6 and fragmentation friendly

My gut feeling is a 10ms default is going to be difficult to live with...just a few years ago, embedded linux (by default) used a 10ms thread scheduling quantum, so it might be difficult to have a consistent 10ms granularity of slot scheduling on some systems.

Randy

From: 6tisch [mailto:[email-masked]] On Behalf Of Kris Pister
Sent: Friday, June 13, 2014 1:43 PM
To: [email-masked]
Subject: Re: [6tisch] 6tisch Digest, Vol 9, Issue 19

Randy -
 I'd love to see a draft on  "4e/4g minimal", which would probably have a big impact.

ksjp

Randy

PLATFORM

15ms

15ms w/security

10ms

10ms w/security

TelosB (MSP430)

Y

?

N

N

OpenMote (M3)

Y

?

?

?

M0 based

8051 based

...

Martin

Martin Turon  |  Nest Labs

---------- Forwarded message ----------
From: Xavier Vilajosana <[email-masked]<mailto:[email-masked]>>
To: Kris Pister <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Rene Struik <[email-masked]<mailto:[email-masked]>>
Date: Thu, 12 Jun 2014 05:24:42 +0200
Subject: Re: [6tisch] minimal slot length
Hi,
my 5 cents...

what do you think?

X

6tisch mailing list