Subject: [6tisch] minimal slot length

From: Kris Pister <[email-masked]>
Date: Wed, 11 Jun 2014 11:46:23 -0700

I've had quite a few discussions with implementers, and it seems that 
there is a broad
desire to go to a 10ms time slot for the minimal draft, rather than 15ms.

The obvious advantage is more available bandwidth.
The obvious disadvantage is that it is harder to implement.

It would be convenient to use the default timeslot from 15.4e (10ms), 
which saves 24 bytes [1].
On the other hand, my understanding is that the TelosB platform, one of 
the ancient relics
(~2004) of the Berkeley motes project and still a workhorse in academic 
WSN labs,
can't run much faster than a 15ms timeslot with a 4MHz clock.

Comments?  Opinions?

ksjp

[1] From section 5.2.4.15 in the ieee standard:
The full time-slot template may be omitted from the enhanced beacon to 
ensure that the beacon does not
exceed aMaxPHYPacketSize. In this case only the template ID is carried, 
and the length of the IE is 1 octet.
If the full time-slot template is carried inline, the element is 25 
octets and corresponds to the PIB attributes
in Table 52e.

---

From: Rene Struik <[email-masked]>
Date: Wed, 11 Jun 2014 15:30:03 -0400

Hi Kris:

Just curious:
Suppose down the road implementers want to introduce a new slotframe 
that has timeslots of 15ms, in addition to the default slotframe with 
10ms timeslots you suggest (perhaps, they want to use both, or want to 
use only the 15 ms one, after having run a system with 10ms timeslots 
for a while [reasons for their motivations are not that important for my 
questions]). Would this be technically possible?

I had some trouble parsing the numbers and seeing what the maximum 
enhanced ACK size would be for slightly out of synch devices after 
receipt of a maximum-size 802.15.4e frame, while respecting time delays 
and other parms in Table 52e.

Best regards, Rene

On 6/11/2014 2:46 PM, Kris Pister wrote:
> On the other hand, my understanding is that the TelosB platform, one 
> of the ancient relics
> (~2004) of the Berkeley motes project and still a workhorse in 
> academic WSN labs,
> exceed aMaxPHYPacketSize. In this case only the template ID is 
> carried, and the length of the IE is 1 octet.
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Kris Pister <[email-masked]>
Date: Wed, 11 Jun 2014 13:58:45 -0700

Yes, I think that would be technically possible.  You'd need a different 
ASN counter among
other things, but it should be possible.

ksjp

On 6/11/2014 12:30 PM, Rene Struik wrote:
> for a while [reasons for their motivations are not that important for 
> my questions]). Would this be technically possible?
>
> receipt of a maximum-size 802.15.4e frame, while respecting time 
> delays and other parms in Table 52e.
>
> Best regards, Rene
>
>
>> The full time-slot template may be omitted from the enhanced beacon 
>> to ensure that the beacon does not

---

From: Xavier Vilajosana <[email-masked]>
Date: Thu, 12 Jun 2014 05:24:42 +0200

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

2014-06-11 22:58 GMT+02:00 Kris Pister <[email-masked]>:

>> Suppose down the road implementers want to introduce a new slotframe that
>> has timeslots of 15ms, in addition to the default slotframe with 10ms
>> timeslots you suggest (perhaps, they want to use both, or want to use only
>> the 15 ms one, after having run a system with 10ms timeslots for a while
>> [reasons for their motivations are not that important for my questions]).
>> Would this be technically possible?
>>
>> enhanced ACK size would be for slightly out of synch devices after receipt
>> of a maximum-size 802.15.4e frame, while respecting time delays and other
>> parms in Table 52e.
>>
>> Best regards, Rene
>>
>>

---

From: "Brett, Patricia (PA62)" <[email-masked]>
Date: Thu, 12 Jun 2014 05:05:36 +0000

10ms would be certainly be attractive for WirelessHART implementers, but ISA100.11a permits a flexible timeslot, so having a flexible time slot in minimal is very important.

-----Original Message-----
From: 6tisch [mailto:[email-masked]] On Behalf Of Kris Pister
Sent: Wednesday, June 11, 2014 2:46 PM
To: [email-masked]
Subject: [6tisch] minimal slot length

I've had quite a few discussions with implementers, and it seems that there is a broad desire to go to a 10ms time slot for the minimal draft, rather than 15ms.

It would be convenient to use the default timeslot from 15.4e (10ms), which saves 24 bytes [1].
On the other hand, my understanding is that the TelosB platform, one of the ancient relics
(~2004) of the Berkeley motes project and still a workhorse in academic WSN labs, can't run much faster than a 15ms timeslot with a 4MHz clock.

Comments?  Opinions?

ksjp

[1] From section 5.2.4.15 in the ieee standard:
The full time-slot template may be omitted from the enhanced beacon to ensure that the beacon does not exceed aMaxPHYPacketSize. In this case only the template ID is carried, and the length of the IE is 1 octet.
If the full time-slot template is carried inline, the element is 25 octets and corresponds to the PIB attributes in Table 52e.

---

From: Pieter De Mil <[email-masked]>
Date: Thu, 12 Jun 2014 10:52:49 +0200

If we choose to support multiple timeslots, it might be a good idea to choose 10ms (default, smallest_timeslot) and 20ms (instead of 15ms), because 10ms and 20ms timeslots can be aligned easier with each other. 

10ms: |—|—|—|—|
15ms: |— -|— -| — -|
20ms: |— —|— —|

Flexibility in timeslots is OK, but we should limit the options:
 timeslot_lenght n = smallest_timeslot_lenght x 2^(n-1)

10ms, 20ms, 40ms, 80ms, 160ms, etc.

Best,
Pieter

On 11 Jun 2014, at 22:58, Kris Pister <[email-masked]> wrote:

> Yes, I think that would be technically possible.  You'd need a different ASN counter among
>> Suppose down the road implementers want to introduce a new slotframe that has timeslots of 15ms, in addition to the default slotframe with 10ms timeslots you suggest (perhaps, they want to use both, or want to use only the 15 ms one, after having run a system with 10ms timeslots for a while [reasons for their motivations are not that important for my questions]). Would this be technically possible?
>> 
>> I had some trouble parsing the numbers and seeing what the maximum enhanced ACK size would be for slightly out of synch devices after receipt of a maximum-size 802.15.4e frame, while respecting time delays and other parms in Table 52e.
>> 
>> Best regards, Rene
>> 
>> 
>>> I've had quite a few discussions with implementers, and it seems that there is a broad
>>> (~2004) of the Berkeley motes project and still a workhorse in academic WSN labs,
>>> The full time-slot template may be omitted from the enhanced beacon to ensure that the beacon does not
>>> exceed aMaxPHYPacketSize. In this case only the template ID is carried, and the length of the IE is 1 octet.

---

From: Xavier Vilajosana <[email-masked]>
Date: Thu, 12 Jun 2014 18:27:46 +0200

Hi,

I think that from the minimal draft point of view we want to stick to the
simplest case without closing any door to possible extended configurations.
So I propose what Kris says, to recommend (MAY?) an slot length of 10ms,
but enable any other time slot size, and outline the benefits of having a
configuration such the one proposed by Pieter. However I do not want to
complicate things in that draft.

would that work?
X

2014-06-12 10:52 GMT+02:00 Pieter De Mil <[email-masked]>:

> If we choose to support multiple timeslots, it might be a good idea to
> choose 10ms (default, smallest_timeslot) and 20ms (instead of 15ms),
> because 10ms and 20ms timeslots can be aligned easier with each other.
>
> 10ms: |—|—|—|—|
> 15ms: |— -|— -| — -|
> 20ms: |— —|— —|
>
> that has timeslots of 15ms, in addition to the default slotframe with 10ms

---

From: Kris Pister <[email-masked]>
Date: Thu, 12 Jun 2014 10:12:42 -0700

Xavi - the concern about 8- and 16-bit microcontrollers is well-founded, 
but (I think) only for
"two chip" solutions, which will be increasingly rare.
The problem on TelosB is the communication bandwidth between the MSP430 
and the
cc2420.
For an integrated radio+microcontroller chip (e.g. those sold by Atmel, 
Dust, Freescale, SiLabs,
ST, TI, ...), I don't think that the processor/radio bandwidth will be a 
problem, even for a slow
8051.
In my discussions with implementers, the only platform that has come up 
as being a problem
is the TelosB.  Anyone designing a new product today shouldn't have this 
problem.

If I'm wrong, and there are people interested in doing interop and/or 
products who just can't
get to 10ms on their hardware, please let us know.

ksjp

On 6/11/2014 8:24 PM, Xavier Vilajosana wrote:
> 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
>
>
>
>
> 2014-06-11 22:58 GMT+02:00 Kris Pister <[email-masked] 
> <mailto:[email-masked]>>:
>
>         Suppose down the road implementers want to introduce a new
>         slotframe that has timeslots of 15ms, in addition to the
>         default slotframe with 10ms timeslots you suggest (perhaps,
>         they want to use both, or want to use only the 15 ms one,
>         after having run a system with 10ms timeslots for a while
>         [reasons for their motivations are not that important for my
>         I had some trouble parsing the numbers and seeing what the
>         maximum enhanced ACK size would be for slightly out of synch
>         devices after receipt of a maximum-size 802.15.4e frame, while
>         respecting time delays and other parms in Table 52e.
>
>         Best regards, Rene
>
>
>             The full time-slot template may be omitted from the
>             enhanced beacon to ensure that the beacon does not
>             exceed aMaxPHYPacketSize. In this case only the template
>             ID is carried, and the length of the IE is 1 octet.
>             If the full time-slot template is carried inline, the
>             element is 25 octets and corresponds to the PIB attributes
>             in Table 52e.
>
>             [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Kris Pister <[email-masked]>
Date: Thu, 12 Jun 2014 10:19:08 -0700

Patricia -
  15.4e and 6TiSCH certainly do and will permit flexible time slots, 
like ISA100.11a.
For the minimal draft, the goal is to define a minimal set of 
capabilities to enable
interoperability.  This is not meant to constrain more advanced future 
designs, which
can certainly specify whatever timeslot format they want, at the expense 
of another
25 bytes in each EB.

For now though, "minimal" means to me that we should pick a single 
timeslot length.
Does that seem reasonable?

ksjp

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 12 Jun 2014 19:56:35 +0000

Works for me. We meed to keep it configurable ...

Pascal

Le 12 juin 2014 à 18:27, "Xavier Vilajosana" <[email-masked]<mailto:[email-masked]>> a écrit :

Hi,

I think that from the minimal draft point of view we want to stick to the simplest case without closing any door to possible extended configurations. So I propose what Kris says, to recommend (MAY?) an slot length of 10ms, but enable any other time slot size, and outline the benefits of having a configuration such the one proposed by Pieter. However I do not want to complicate things in that draft.

would that work?
X

2014-06-12 10:52 GMT+02:00 Pieter De Mil <[email-masked]<mailto:[email-masked]>>:
If we choose to support multiple timeslots, it might be a good idea to choose 10ms (default, smallest_timeslot) and 20ms (instead of 15ms), because 10ms and 20ms timeslots can be aligned easier with each other.

10ms: |—|—|—|—|
15ms: |— -|— -| — -|
20ms: |— —|— —|

Best,
Pieter

On 11 Jun 2014, at 22:58, Kris Pister <[email-masked]<mailto:[email-masked]>> wrote:

>>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

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

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

---

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

+1 to Pieter¹s power of two alignment

Martin Turon  |  Nest Labs

From:  "Pascal Thubert (pthubert)" <[email-masked]>
Date:  Thursday, June 12, 2014 at 12:56 PM
To:  Xavier Vilajosana <[email-masked]>
Cc:  Kris Pister <[email-masked]>, "[email-masked]" <[email-masked]>,
Pieter De Mil <[email-masked]>, Rene Struik <[email-masked]>
Subject:  Re: [6tisch] minimal slot length

Pascal

Le 12 juin 2014 à 18:27, "Xavier Vilajosana" <[email-masked]>
a écrit :

> simplest case without closing any door to possible extended configurations. So
> I propose what Kris says, to recommend (MAY?) an slot length of 10ms, but
> enable any other time slot size, and outline the benefits of having a
>> If we choose to support multiple timeslots, it might be a good idea to choose
>> 10ms (default, smallest_timeslot) and 20ms (instead of 15ms), because 10ms
>> and 20ms timeslots can be aligned easier with each other.
>> 
>> 10ms: |‹|‹|‹|‹|
>> 15ms: |‹ -|‹ -| ‹ -|
>> 20ms: |‹ ‹|‹ ‹|
>>

---

From: "Brett, Patricia (PA62)" <[email-masked]>
Date: Wed, 18 Jun 2014 13:32:54 +0000

Hi Kris,  

This discussion also was the basis of a disagreement between WiHART (which did pick 10ms), and ISA100.11a, which needed greater flexibility.

ISA100.11a allows use of 10ms, but it does not require it.  The decision regarding slot length belongs to the network management application.

To answer your other question, yes, there is existing hardware that does not support using 10ms.

A test case using 10ms slot time for validation maybe worthwhile, but I cannot see including it as a requirement for minimal set of capabilities required of all devices.

Regards,
Pat

-----Original Message-----
From: Kris Pister [mailto:[email-masked]] 
Sent: Thursday, June 12, 2014 1:19 PM
To: Brett, Patricia (PA62); [email-masked]
Subject: Re: [6tisch] minimal slot length

Patricia -
  15.4e and 6TiSCH certainly do and will permit flexible time slots, like ISA100.11a.
For the minimal draft, the goal is to define a minimal set of capabilities to enable interoperability.  This is not meant to constrain more advanced future designs, which can certainly specify whatever timeslot format they want, at the expense of another
25 bytes in each EB.

For now though, "minimal" means to me that we should pick a single timeslot length.
Does that seem reasonable?

ksjp

---

From: "Brett, Patricia (PA62)" <[email-masked]>
Date: Wed, 18 Jun 2014 14:47:04 +0000

Hi again Kris,

Regarding the time slot that is being designed for 6TiSCH ... is it correct to assume that it will be able to support duo-cast as ISA100.11a supports?

Thanks,
Pat

-----Original Message-----
From: Brett, Patricia (PA62) 
Sent: Wednesday, June 18, 2014 9:33 AM
To: Kris Pister; [email-masked]
Cc: Brett, Patricia (PA62)
Subject: RE: [6tisch] minimal slot length

Hi Kris,  

Regards,
Pat

-----Original Message-----
From: Kris Pister [mailto:[email-masked]]
Sent: Thursday, June 12, 2014 1:19 PM
To: Brett, Patricia (PA62); [email-masked]
Subject: Re: [6tisch] minimal slot length

Patricia -

ksjp

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 19 Jun 2014 14:54:26 +0000

I read that discussion as there is no fits-it-all slot duration. 15ms may be a waste of bandwidth and 10ms would be short for the lower power devices, or variations on the MAC with e.g. duocast that implies room for a double ack.

In my mind, this is again a discussion on applicability, a question that we did not resolve. If minimal is to be used as a ship in the night, e.g.  in homes and cars, then any length will do, and if there's plenty f bandwidth then the 15ms has more chances to accommodate all parties.

OTOG, if it is meant to be deployed together with existing variations of the 802.15.4e MAC, then the slot duration for minimal becomes important as a parameter to improve coexistence - at least benefit from the slotted aspect of slotted aloha to reduce overlaps.

I am in the camp that believes that there is a need for an always-on mesh for management, time distribution and recovery regardless of the 6TiSCH deployment. I hope that we could use minimal for that purpose in a very general fashion. This means that minimal should be able to adapt its slot duration to the one used predominantly in its environment. 

If the environment is predominantly using Wireless HART then the minimal should be able to align to that slot duration. If it is something else it should be able to adapt too, and ISA100 allows for configurable durations.

All in all, my vote would go to a configurable duration, with a range that will be adapted to the technology we use at the MAC layer.

My question to Pat (and Pat) is whether the current 802.15.4e specification allows to align the slot duration to any duration of an ISA100.11a slot, or if, due to units or whatnot, this cannot be achieved at all?

Cheers,

Pascal

> Sent: jeudi 12 juin 2014 19:19
> For the minimal draft, the goal is to define a minimal set of capabilities to
> enable interoperability.  This is not meant to constrain more advanced
> future designs, which can certainly specify whatever timeslot format they
> want, at the expense of another
> 25 bytes in each EB.
> 
> > 10ms would be certainly be attractive for WirelessHART implementers, but
> ISA100.11a permits a flexible timeslot, so having a flexible time slot in
> minimal is very important.
> >
> there is a broad desire to go to a 10ms time slot for the minimal draft, rather
> than 15ms.
> >
> WSN labs, can't run much faster than a 15ms timeslot with a 4MHz clock.
> >
> > Comments?  Opinions?
> >
> > ksjp
> >
> ensure that the beacon does not exceed aMaxPHYPacketSize. In this case
> only the template ID is carried, and the length of the IE is 1 octet.
> > If the full time-slot template is carried inline, the element is 25 octets and
> corresponds to the PIB attributes in Table 52e.
> >

---

From: "Brett, Patricia (PA62)" <[email-masked]>
Date: Thu, 19 Jun 2014 15:08:53 +0000

Thanks, Pascal.
I defer to Pat Kinney to answer your quest.

Also, I would like to suggest that the the wording in the architecture document should be enhanced to indicate the 15.4e is the base as extensions to it may be required for some applications.  Please refer to the text in the architecture document, clause 3:
"... in particular with the use of the IEEE802.15.4e TSC MAC ..." rather should be something like
" .... in particular based on the use of the IEEE802.15.4e MAC ..."

This suggestion reflects my understanding that while IEEE802.15.4e includes features necessary for process control, it does not include all features needed by process control applications in general.  Examples of such features would be those additions contained in ISA100.11a.

Regards,
Pat B.

-----Original Message-----
From: 6tisch [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Thursday, June 19, 2014 10:54 AM
To: Kris Pister; Brett, Patricia (PA62); [email-masked]
Subject: Re: [6tisch] minimal slot length

Cheers,

Pascal

> capabilities to enable interoperability.  This is not meant to 
> constrain more advanced future designs, which can certainly specify 
> whatever timeslot format they want, at the expense of another
> 25 bytes in each EB.
> 
> ISA100.11a permits a flexible timeslot, so having a flexible time slot 
> in minimal is very important.
> >
> there is a broad desire to go to a 10ms time slot for the minimal 
> draft, rather than 15ms.
> >
> > academic
> > to
> > octets and

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 19 Jun 2014 15:40:26 +0000

I'm OK with this change, Pat, and will wait for more advice.

All in all, 15.4e is our reference for the current work but everything we do above 6top and hopefully a lot of the 6top work as well should be easily portable to other MAC/PHY, including DECT ULE, BTLE, 4/5G or WiFi if the required adaptation work is done to enable Time Sensitive transmissions on those technologies.

Cheers,

Pascal

> From: Brett, Patricia (PA62) [mailto:[email-masked]]
> Sent: jeudi 19 juin 2014 17:09
> To: Pascal Thubert (pthubert); Kris Pister; [email-masked]
> Also, I would like to suggest that the the wording in the architecture
> document should be enhanced to indicate the 15.4e is the base as
> extensions to it may be required for some applications.  Please refer to the
> text in the architecture document, clause 3:
> "... in particular with the use of the IEEE802.15.4e TSC MAC ..." rather should
> be something like " .... in particular based on the use of the IEEE802.15.4e
> MAC ..."
> 
> This suggestion reflects my understanding that while IEEE802.15.4e includes
> features necessary for process control, it does not include all features
> needed by process control applications in general.  Examples of such
> features would be those additions contained in ISA100.11a.
> 
> Regards,
> Pat B.
> 
> I read that discussion as there is no fits-it-all slot duration. 15ms may be a
> waste of bandwidth and 10ms would be short for the lower power devices,
> or variations on the MAC with e.g. duocast that implies room for a double
> ack.
> 
> In my mind, this is again a discussion on applicability, a question that we did
> not resolve. If minimal is to be used as a ship in the night, e.g.  in homes and
> cars, then any length will do, and if there's plenty f bandwidth then the
> 15ms has more chances to accommodate all parties.
> 
> OTOG, if it is meant to be deployed together with existing variations of the
> 802.15.4e MAC, then the slot duration for minimal becomes important as a
> parameter to improve coexistence - at least benefit from the slotted aspect
> of slotted aloha to reduce overlaps.
> 
> I am in the camp that believes that there is a need for an always-on mesh for
> management, time distribution and recovery regardless of the 6TiSCH
> deployment. I hope that we could use minimal for that purpose in a very
> general fashion. This means that minimal should be able to adapt its slot
> duration to the one used predominantly in its environment.
> 
> If the environment is predominantly using Wireless HART then the minimal
> should be able to align to that slot duration. If it is something else it should
> be able to adapt too, and ISA100 allows for configurable durations.
> 
> All in all, my vote would go to a configurable duration, with a range that will
> be adapted to the technology we use at the MAC layer.
> 
> My question to Pat (and Pat) is whether the current 802.15.4e specification
> allows to align the slot duration to any duration of an ISA100.11a slot, or if,
> due to units or whatnot, this cannot be achieved at all?
> 
> Cheers,
> 
> Pascal
> 
>

---

From: Kris Pister <[email-masked]>
Date: Thu, 19 Jun 2014 12:00:44 -0700

I don't think that anyone would argue against configurable duration for 
6TiSCH networks.
Duo-cast is also a neat feature.
But do they belong in the *minimal* draft?  My vote is no, that's not 
what minimal is for.

If someone wants to write the "simple, flexible, and yet 
high-performance" draft, then by
all means please do so.

ksjp

---

From: "Brett, Patricia (PA62)" <[email-masked]>
Date: Thu, 19 Jun 2014 19:30:39 +0000

Minimal should be considering the communication needs of devices in use today.
If one considers supporting existing products today, they most certainly are in use.

I don't see how to fairly select any particular value. 
Certainly the value of 10ms would not be acceptable since that would very clearly advantage a particular set of vendors, and very significantly disadvantage others.

Regards,
Pat

-----Original Message-----
From: Kris Pister [mailto:[email-masked]] 
Sent: Thursday, June 19, 2014 3:01 PM
To: Pascal Thubert (pthubert); Brett, Patricia (PA62); [email-masked]
Subject: Re: [6tisch] minimal slot length

I don't think that anyone would argue against configurable duration for 6TiSCH networks.
Duo-cast is also a neat feature.
But do they belong in the *minimal* draft?  My vote is no, that's not what minimal is for.

If someone wants to write the "simple, flexible, and yet high-performance" draft, then by all means please do so.

ksjp

On 6/19/2014 7:54 AM, Pascal Thubert (pthubert) wrote:
>> ISA100.11a permits a flexible timeslot, so having a flexible time 
>> slot in minimal is very important.
>> ensure that the beacon does not exceed aMaxPHYPacketSize. In this 
>> case only the template ID is carried, and the length of the IE is 1 octet.

---

From: Kris Pister <[email-masked]>
Date: Thu, 19 Jun 2014 12:58:41 -0700

> Certainly the value of 10ms would not be acceptable since that would very clearly advantage a particular set of vendors, and very significantly disadvantage others.
Patricia - I'm having a hard time understanding this.  Back in the bad 
old days with battles between
the industrial giants, there were limited hardware choices.  Today, 
there are at least a half dozen
vendors (probably more like a dozen) who sell single chip solutions that 
can easily handle 10ms
time slots.
6TiSCH is not backward compatible with WirelessHART or ISA100.11a, so I 
don't understand
how the skeletons of those battles could be haunting this discussion.

ksjp

---

From: Kris Pister <[email-masked]>
Date: Thu, 19 Jun 2014 13:12:49 -0700

On 6/19/2014 7:54 AM, Pascal Thubert (pthubert) wrote:
> If the environment is predominantly using Wireless HART then the minimal should be able to align to that slot duration.
Pascal - it's not clear to me that this is technically sound.  I can't 
picture a scenario where a new
6TiSCH network is synchronous with the existing (multiple, asynchronous) 
wirelses HART networks.
The result is that there will be a very slow Moire effect as the 
networks slide by each other in time.
This is optimally bad for both networks.
If we really are worried that the world is filled with wirelessHART 
networks (...sigh...if only it were
so), then we would want to pick a slot length at least 5-10% different 
from 10ms.  That way the
collisions will look more random, and won't cause a slow cyclical 
overlap that could be bad for
both old and new networks.

But the world is NOT filled with wirelessHART or ISA networks. Hopefully 
soon it will be filling with
6TiSCH networks, and we should design 6TiSCH to be the best standard 
that we can.  We should
use the lessons learned from industrial deployments, but not let 
ourselves be saddled with
backward compatibility with a market that is, by IETF standards, old and 
slow with very few
deployments.

ksjp

---

From: "Brett, Patricia (PA62)" <[email-masked]>
Date: Thu, 19 Jun 2014 20:59:26 +0000

Hi Kris.  
You can call me Pat.

This is not a question of backward compatibility.  This is about a business concern regarding the impact such a decision can have on adoption of the technology due to real-life product development impacts and lost opportunities due to extended time to market.

By any particular value decision, if some vendors are likely to have to undergo redesign, implementation, test, certification activities, etc. while other vendors would not, it can very easily become a problem.  The potential additional costs which could be incurred for a redesign activity as I'm sure you know, are not insignificant. 

The suggestion for a variable value was made with the intent of establishing a fair and level playing field.  
I've been working in standards since about 1987, and if there is one thing I have learned, it is if there is not a level playing field created, the result is a business situation which could, at best delay adoption, and a worse result in seeking to establish an alternate solution(s). 

If you have another alternative other than permitting variable slot times which achieves the same level of fairness, I am very interested to learn about it.

Regards,
Pat

-----Original Message-----
From: Kris Pister [mailto:[email-masked]] 
Sent: Thursday, June 19, 2014 3:59 PM
To: Brett, Patricia (PA62); Pascal Thubert (pthubert); [email-masked]
Subject: Re: [6tisch] minimal slot length

> Certainly the value of 10ms would not be acceptable since that would very clearly advantage a particular set of vendors, and very significantly disadvantage others.
Patricia - I'm having a hard time understanding this.  Back in the bad old days with battles between the industrial giants, there were limited hardware choices.  Today, there are at least a half dozen vendors (probably more like a dozen) who sell single chip solutions that can easily handle 10ms time slots.
6TiSCH is not backward compatible with WirelessHART or ISA100.11a, so I don't understand how the skeletons of those battles could be haunting this discussion.

ksjp

---

From: Kris Pister <[email-masked]>
Date: Thu, 19 Jun 2014 15:36:31 -0700

Pat - I still don't understand what you're talking about.  This is not 
Honeywell and Emerson fighting
for industrial process automation anymore.
There are at least six low-cost chips from six different vendors that 
run open source software
from several different universities that can all handle 10ms time 
slots.  That is about as level
a playing field as you can find.

Who exactly is going to get an unfair advantage from a 10ms time slot?  
Is Emerson going to
quickly re-engineer their HART products to run 6TiSCH?  That is 
laughable for a variety of reasons.
Is HART going to quickly change the standard to be 6TiSCH compatible?  
No way.
Is Dust going to re-engineer it's SmartMesh IP product line to use 
10ms?  Well, they're already
running at ~7ms, so I guess that they could slow things down and get 
worse performance, but
nothing in that product line speaks 6top, or CoAP, or any DICE, or any 
of the other standards
that are going to make up the stack that everyone is working to define.  
It will be a complete
re-design, and completely non-interoperable with anything that anyone 
was had before.

 >  if some vendors are likely to have to undergo redesign, 
implementation, test, certification
 > activities, etc. while other vendors would not,

*Every* single vendor is going to have to undergo redesign, 
implementation, and test.  There are no
vendors who have implemented the standard that we are developing, let 
alone who sell it.
Everyone is on the same playing field, and it's flat.

10ms is the default in the IEEE standard.  It saves energy and bandwidth 
in EBs.  It provides
more network bandwidth for scheduling.  It's the easiest choice. But it 
doesn't have to be
the choice for everyone.  If there is some reason why you want something 
other than
10ms, then by all means please write that draft.  If there are other 
people who want to interop
with you, then no one is going to stand in your way.  That's the beauty 
of the IETF.

ksjp

---

From: Pieter De Mil <[email-masked]>
Date: Fri, 20 Jun 2014 00:51:04 +0200

+10 
;-)

> Op 20-jun.-2014 om 00:36 heeft Kris Pister <[email-masked]> het volgende geschreven:
> 
> Pat - I still don't understand what you're talking about.  This is not Honeywell and Emerson fighting
> There are at least six low-cost chips from six different vendors that run open source software
> from several different universities that can all handle 10ms time slots.  That is about as level
> Who exactly is going to get an unfair advantage from a 10ms time slot?  Is Emerson going to
> quickly re-engineer their HART products to run 6TiSCH?  That is laughable for a variety of reasons.
> Is HART going to quickly change the standard to be 6TiSCH compatible?  No way.
> Is Dust going to re-engineer it's SmartMesh IP product line to use 10ms?  Well, they're already
> running at ~7ms, so I guess that they could slow things down and get worse performance, but
> nothing in that product line speaks 6top, or CoAP, or any DICE, or any of the other standards
> that are going to make up the stack that everyone is working to define.  It will be a complete
> re-design, and completely non-interoperable with anything that anyone was had before.
> 
> >  if some vendors are likely to have to undergo redesign, implementation, test, certification
> *Every* single vendor is going to have to undergo redesign, implementation, and test.  There are no
> vendors who have implemented the standard that we are developing, let alone who sell it.
> 10ms is the default in the IEEE standard.  It saves energy and bandwidth in EBs.  It provides
> more network bandwidth for scheduling.  It's the easiest choice. But it doesn't have to be
> the choice for everyone.  If there is some reason why you want something other than
> 10ms, then by all means please write that draft.  If there are other people who want to interop
> with you, then no one is going to stand in your way.  That's the beauty of the IETF.
> 
> ksjp
>

---

From: [email-masked]
Date: Fri, 20 Jun 2014 08:04:24 +0530

If 6tisch's main objective  is to work strictly on 15.4e, and if 15.4e
requires 10ms, there is no scope for flexibility what so ever. The
requirement is very similar to other IEEE MAC protocols.

For taking the benefits of time slotted channel hopping to many other uses
cases that need not use 15.4e, there 6tisch is better off in making itself
flexible and do not impose itself the 15.4e restriction. Actually 15.4e
becomes one of the options.

Anand

> Certainly the value of 10ms would not be acceptable since that would very
> clearly advantage a particular set of vendors, and very significantly
> disadvantage others.
>
> Regards,
> Pat
>
>> I read that discussion as there is no fits-it-all slot duration. 15ms
>> may be a waste of bandwidth and 10ms would be short for the lower power
>> devices, or variations on the MAC with e.g. duocast that implies room
>> for a double ack.
>>
>> In my mind, this is again a discussion on applicability, a question that
>> we did not resolve. If minimal is to be used as a ship in the night,
>> e.g.  in homes and cars, then any length will do, and if there's plenty
>> f bandwidth then the 15ms has more chances to accommodate all parties.
>>
>> OTOG, if it is meant to be deployed together with existing variations of
>> the 802.15.4e MAC, then the slot duration for minimal becomes important
>> as a parameter to improve coexistence - at least benefit from the
>> slotted aspect of slotted aloha to reduce overlaps.
>>
>> I am in the camp that believes that there is a need for an always-on
>> mesh for management, time distribution and recovery regardless of the
>> 6TiSCH deployment. I hope that we could use minimal for that purpose in
>> a very general fashion. This means that minimal should be able to adapt
>> its slot duration to the one used predominantly in its environment.
>>
>> should be able to align to that slot duration. If it is something else
>> it should be able to adapt too, and ISA100 allows for configurable
>> durations.
>>
>> All in all, my vote would go to a configurable duration, with a range
>> that will be adapted to the technology we use at the MAC layer.
>>
>> My question to Pat (and Pat) is whether the current 802.15.4e
>> specification allows to align the slot duration to any duration of an
>> ISA100.11a slot, or if, due to units or whatnot, this cannot be achieved
>> at all?
>>
>> Cheers,
>>
>> Pascal
>>
>>
> This message has been scanned for viruses and
> dangerous content by MailScanner, 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: Thomas Watteyne <[email-masked]>
Date: Thu, 19 Jun 2014 20:08:52 -0700

Anand,

IEEE802.15.4e-2012 TSCH gives your the flexibility to pick your the
timeslot duration. If you pick 10ms, the EBs are shorter. If you pick
something different, you must carry the different durations in your EB
explicitly, which is ~24B of extra data.

Thomas

On Thu, Jun 19, 2014 at 7:34 PM, <[email-masked]> wrote:

> what
> > minimal is for.
> high-performance"
> > draft, then by all means please do so.
> >
> > ksjp
> >

---

From: [email-masked]
Date: Fri, 20 Jun 2014 08:50:35 +0530

Thomas,

Thanks. Since the standard gives the flexibility inherently I am puzzled
why there is so much debate. It is understood that in the implementations
that use values other than 10ms, those extra bytes will result. I am sure
compressed versions of EB will be invented in future. This last statement
is simple hand waving.

Anand

>> > Minimal should be considering the communication needs of devices in
>> use
>> > today.
>> > If one considers supporting existing products today, they most
>> certainly
>> > are in use.
>> >
>> >>>> 10ms would be certainly be attractive for WirelessHART
>> implementers,
>> >>>> but

---

From: Xavier Vilajosana <[email-masked]>
Date: Fri, 20 Jun 2014 05:40:33 +0200

Hi Anand,

I think that the debate appears because although 15.4e enables any timeslot
length, we are indicating that a minimal configuration for this networks
will be using by default this 10ms slots. This of course can be changed,
however having this 10ms would be a requirement to be strictly compliant
with a minimal implementation.

Note that 15.4e is so widely configurable that we want to define this
minimal mode of operation so 6tisch implementers can start with something
and be able to inter-operate, also as a fallback mode or super simple best
effort mode.

What is important to understand is that this discussion and this draft does
not restrict any other mode of operation of 15.4e TSCH, including the
possibility of having multiple slotframes with different slotsizes, duo
cast, or super optimized scheduling approaches. However, IMHO, this will
come in other drafts.

regards,
Xavi

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 20 Jun 2014 07:04:11 +0000

I can imagine that moire effect, Kris.

My hope was effectively to be able to synchronize multiple meshes, and then to have the best effort wait enough (like guard time) to ensure that deterministic packets are not being sent on a time slot. If that's none of that is possible, then I agree there's no point in aligning the minimal schedule with existing standards, and I agree to keep discussions on other standards out of scope.

Still, minimal will have to coexist with more beefy versions of 6TiSCH. I'm struggling to figure how a single device could participate to a schedule that is not based on 10ms and to minimal at the same time. It seems that implementation is a lot easier if all the slotframes have a same slot duration and a same epoch, even if the length of the slotframe varies.

OTOH if we hardcode 10ms in minimal, don't we bar the capability to have a device participate to a network that would have a different slot duration?

Pascal

> Sent: jeudi 19 juin 2014 22:13
> should be able to align to that slot duration.
> Pascal - it's not clear to me that this is technically sound.  I can't picture a
> scenario where a new 6TiSCH network is synchronous with the existing
> (multiple, asynchronous) wirelses HART networks.
> The result is that there will be a very slow Moire effect as the networks slide
> by each other in time.
> If we really are worried that the world is filled with wirelessHART networks
> (...sigh...if only it were so), then we would want to pick a slot length at least
> 5-10% different from 10ms.  That way the collisions will look more random,
> and won't cause a slow cyclical overlap that could be bad for both old and
> new networks.
> 
> soon it will be filling with 6TiSCH networks, and we should design 6TiSCH to
> be the best standard that we can.  We should use the lessons learned from
> industrial deployments, but not let ourselves be saddled with backward
> compatibility with a market that is, by IETF standards, old and slow with very
> few deployments.
> 
> ksjp

---

From: "S.V.R.Anand" <[email-masked]>
Date: Fri, 20 Jun 2014 13:33:58 +0530

Hi Xavi,

If 10ms is what is going to be widely acceptable to the industry, and
therefore being proposed as a starting point to begin with, I think we
should stick to this as minimal slot length. After all, we have to respect
the amount of implementation experience would have gone into, before
arriving at this number.

Any dilution to this seemingly strict requirement to accommodate wider
user-base has the danger of isolating, perhaps, a major chunk of industry
that wants to deploy 6TiSCH that really want 10ms. If this puts stringent
demand on the platforms, so be it, let us make them. Industry requirements
are expected to be harsh.

Anand

>> >> > Certainly the value of 10ms would not be acceptable since that
>> would
>> >> very
>> >> >> In my mind, this is again a discussion on applicability, a
>> question
>> >> that
>> >> >> OTOG, if it is meant to be deployed together with existing
>> variations
>> >> of
>> >> >> 6TiSCH deployment. I hope that we could use minimal for that
>> purpose
>> >> in
>> >> >>> case only the template ID is carried, and the length of the IE is
>> 1
>> >> >>> octet.

---

From: Martin Turon <[email-masked]>
Date: Fri, 20 Jun 2014 12:37:02 -0700

Hi All,

It would be ideal if the time slot length is chosen to be inclusive of
existing deployments of 15.4 radios, so an upgrade the 6tsch is possible
for existing hardware in the field.

While 32-bit Cortex-M nodes are quickly becoming the norm, many
high-volume 15.4 based products have been shipped (or continue to ship)
with slower 8-bit 8051 cores.  6tsch will have a much cleaner upgrade
story if it can work on 100% of existing products rather than a subset of
³new only².  What is clear is that in order for a device to participate in
a 6tsch network, it must be able to meet the timing requirements of the
time slot + security calculations.  If minimal makes those timing
requirements too stringent, it won¹t get the wide adoption we all hope it
will have.

As such, it would be helpful to generate a matrix of which platform
classes could be included, and which could not for 10ms and 15ms
(including security) and make an informed decision.

Considerations of multiple networks with different time slot sizes
interoperating seems far out of scope at this point.  Lets worry about
getting the minimal to work well with as wide a net of platforms as
possible.

Martin
________________________________________

Martin Turon  |  Nest Labs

On 6/20/14, 1:03 AM, "S.V.R.Anand" <[email-masked]> wrote:

>>> >> For taking the benefits of time slotted channel hopping to many
>>>other
>>> >> uses
>>> >> > I don't think that anyone would argue against configurable
>>>duration
>>> >> for
>>> >> > 6TiSCH networks.
>>> >> >> specification allows to align the slot duration to any duration
>>>of
>>> an
>>> >> >>>> I've had quite a few discussions with implementers, and it
>>>seems
>>> >> >>>> that
>>> >> >>>> On the other hand, my understanding is that the TelosB
>>>platform,
>>> >> one
>>> >> >>>> of the ancient relics
>>> >> >>>> If the full time-slot template is carried inline, the element
>>>is
>>> 25
>>> >> >>>> octets and

---

From: Rene Struik <[email-masked]>
Date: Fri, 20 Jun 2014 16:03:55 -0400

Hi Martin:

Quick question: In your note below, you refer to security being 
potentially a limiting factor. This makes me wonder: are there any 
high-volume 15.4-based shipping products that implement AES-128 with a 
throughput of less than 2.304 Mbps (or roughly 10x the raw 250kbps data 
rate)? If so, what throughput does AES-128 have in those shipped 
products? If you have some insight you could share (either to the list 
or privately), e.g., in terms of throughput/percentile of mass shipping, 
that would be great. (If, in your reference to shipped products, you 
include those that may only implement AES in software, it would be nice 
to treat those as separate category, and provide metrics there as well. 
If this is the empty set, that would also be good to mention.)

Best regards, Rene

---

From: Martin Turon <[email-masked]>
Date: Fri, 20 Jun 2014 13:18:32 -0700

Hi Rene,

I think it is reasonable to limit scope of 6tsch minimal to hw with AES-128
acceleration -- such hw has been standard on 15.4 chipsets for at least 10
years.

My main point is that we precisely map out what the minimal hw requirements
for minimal tsch are, and that we be inclusive of the 8-bit cores if
possible (as they have been for better, or worse, quite widely deployed).

Your minimal AES-128 throughput requirement of "2.304 Mbps" is a good
start.  Those are the kind of hard numbers I think we need to make the
decision between a 10ms or 15ms time size.  Is that the throughput
requirement for a 10ms slot or a 15ms slot?

I think the main time slot timing requirement is that a RX device be able
to decrypt a maximum length 127 byte packet, parse the contents, and
respond with an ACK within TsTxAckDelay.

#TsTxAckDelay
<https://openwsn.atlassian.net/wiki/display/OW/Timing+Constants#TimingConstants-TsTxAckDelay>

4000us

Martin

On Fri, Jun 20, 2014 at 1:03 PM, Rene Struik <[email-masked]> wrote:

> rate)? If so, what throughput does AES-128 have in those shipped products?
> If you have some insight you could share (either to the list or privately),
> e.g., in terms of throughput/percentile of mass shipping, that would be
> great. (If, in your reference to shipped products, you include those that
> may only implement AES in software, it would be nice to treat those as
> separate category, and provide metrics there as well. If this is the empty
> set, that would also be good to mention.)
>
> Best regards, Rene
>
>> łnew only˛.  What is clear is that in order for a device to participate in
>> requirements too stringent, it wonšt get the wide adoption we all hope it
>> will have.
>>

---

From: Rene Struik <[email-masked]>
Date: Fri, 20 Jun 2014 16:50:11 -0400

Hi Martin:

Please note that my 2.304 Mbps throughput number is based on some crude 
calculations I did on an (orange-colored Brazil world cup) beer coaster, 
without necessarily taking into account all parameters of TSCH. If you 
have parameter sets for various settings, it is not that hard to make 
this more precise. Where does your TsTxAckDelay figure of 4ms come from?

It would be good to have some more detailed insight on the AES 
throughput/percentile distribution for mass-shipped products, where, one 
should perhaps add some other metrics per product in addition to crypto 
numbers as well (e.g., clock rate, RAM/ROM on the chip, etc., and which 
version of 802.15.4 it implements). The latter would allow an assessment 
on feasibility, irrespective of whatever timeslot numbers one can dream up.

Best regards, Rene

On 6/20/2014 4:18 PM, Martin Turon wrote:
> Hi Rene,
>
> I think it is reasonable to limit scope of 6tsch minimal to hw with 
> AES-128 acceleration -- such hw has been standard on 15.4 chipsets for 
> at least 10 years.
>
> My main point is that we precisely map out what the minimal hw 
> requirements for minimal tsch are, and that we be inclusive of the 
> 8-bit cores if possible (as they have been for better, or worse, quite 
> widely deployed).
>
> I think the main time slot timing requirement is that a RX device be 
> able to decrypt a maximum length 127 byte packet, parse the contents, 
> and respond with an ACK within TsTxAckDelay.
>
> #TsTxAckDelay 
> On Fri, Jun 20, 2014 at 1:03 PM, Rene Struik <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Martin:
>
>     high-volume 15.4-based shipping products that implement AES-128
>     with a throughput of less than 2.304 Mbps (or roughly 10x the raw
>     250kbps data rate)? If so, what throughput does AES-128 have in
>     those shipped products? If you have some insight you could share
>     (either to the list or privately), e.g., in terms of
>     throughput/percentile of mass shipping, that would be great. (If,
>     in your reference to shipped products, you include those that may
>     only implement AES in software, it would be nice to treat those as
>     separate category, and provide metrics there as well. If this is
>     the empty set, that would also be good to mention.)
>
>     Best regards, Rene
>
>         ?new only?.  What is clear is that in order for a device to
>         participate in
>         requirements too stringent, it wons(t get the wide adoption we
>         all hope it
>         will have.
>
>         On 6/20/14, 1:03 AM, "S.V.R.Anand" <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>             Hi Xavi,
>

---

From: Martin Turon <[email-masked]>
Date: Fri, 20 Jun 2014 13:54:39 -0700

The 4ms TsTxAckDelay came from OpenWSN site, which is currently implementing
a 15ms slot:
https://openwsn.atlassian.net/wiki/display/OW/Timing+Constants  (15ms
timing)
      https://openwsn.atlassian.net/wiki/display/OW/State+Machine  (generic
slot timing)

I’m not sure what the proposed TsTxAckDelay would be for a 10ms slot.

Martin

Martin Turon  |  Nest Labs

From:  Rene Struik <[email-masked]>
Date:  Friday, June 20, 2014 at 1:50 PM
To:  Martin Turon <[email-masked]>
Cc:  Pascal Thubert <[email-masked]>, "S.V.R.Anand"
<[email-masked]>, Thomas Watteyne <[email-masked]>,
Xavier Vilajosana <[email-masked]>, Kris Pister
<[email-masked]>, "Brett, Patricia (PA62)"
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject:  Re: [6tisch] AES throughput in high-volume legacy shipments

Hi Martin:
 
 Please note that my 2.304 Mbps throughput number is based on some crude
calculations I did on an (orange-colored Brazil world cup) beer coaster,
without necessarily taking into account all parameters of TSCH. If you have
parameter sets for various settings, it is not that hard to make this more
precise. Where does your TsTxAckDelay figure of 4ms come from?
 
 It would be good to have some more detailed insight on the AES
throughput/percentile distribution for mass-shipped products, where, one
should perhaps add some other metrics per product in addition to crypto
numbers as well (e.g., clock rate, RAM/ROM on the chip, etc., and which
version of 802.15.4 it implements). The latter would allow an assessment on
feasibility, irrespective of whatever timeslot numbers one can dream up.
 
 Best regards, Rene
 
 On 6/20/2014 4:18 PM, Martin Turon wrote:

> for minimal tsch are, and that we be inclusive of the 8-bit cores if possible
> (as they have been for better, or worse, quite widely deployed).
>  
> 
>  
>  
> Your minimal AES-128 throughput requirement of "2.304 Mbps" is a good start.
> Those are the kind of hard numbers I think we need to make the decision
> between a 10ms or 15ms time size.  Is that the throughput requirement for a
> 10ms slot or a 15ms slot?
>  
> 
>  
>  
> I think the main time slot timing requirement is that a RX device be able to
> decrypt a maximum length 127 byte packet, parse the contents, and respond with
> an ACK within TsTxAckDelay.
>  
>  
> 
>    
>   #TsTxAckDelay 
> <https://openwsn.atlassian.net/wiki/display/OW/Timing+Constants#TimingConstant
> s-TsTxAckDelay>    4000us
>  
>  
> 
>  
>  
> Martin
>  
> 
>  
>  
>>  Quick question: In your note below, you refer to security being potentially
>> a limiting factor. This makes me wonder: are there any high-volume 15.4-based
>> shipping products that implement AES-128 with a throughput of less than 2.304
>> Mbps (or roughly 10x the raw 250kbps data rate)? If so, what throughput does
>> AES-128 have in those shipped products? If you have some insight you could
>> share (either to the list or privately), e.g., in terms of
>> throughput/percentile of mass shipping, that would be great. (If, in your
>> reference to shipped products, you include those that may only implement AES
>> in software, it would be nice to treat those as separate category, and
>> provide metrics there as well. If this is the empty set, that would also be
>> good to mention.)
>>  
>>  Best regards, Rene
>>  
> [email-masked]://www.ietf.org/mailman/listinfo/6tisch
>  
>  
>  
>  
> --

---

From: Rene Struik <[email-masked]>
Date: Fri, 20 Jun 2014 17:12:07 -0400

Hi Martin:

Thanks for the pointers to the OpenWSN website. Are these the 
mass-shipped products you refer to, or is this just an example of 
instantiations of 802.15.4e that use 15 ms timeslots?

BTW - I had a brief look at the OpenWSN website, but could not find the 
AES throughput numbers (or other metrics, such as RAM/ROM, clockspeed) I 
was curious about. I did see some confusing language in the section 
called "Adding Security" 
(https://openwsn.atlassian.net/wiki/display/OW/Adding+Security), which 
suggested that one uses a very inefficient decryption procedure with 
OpenWSN. From a (very!) cursory view, it seems one can perhaps do a 
factor 2x better. (Please let me know offline whether you want to 
discuss this more.)

For a technical discussion, it would be really good to provide some hard 
evidence re AES numbers (so as to avoid beauty contests of whatever 
timeslot figure people are familiar with). Hence, my email earlier this 
afternoon, in an attempt to quantify where potential issues may be and 
to see which issues are perceived and which are real.

The TsTxACKdelay in Table 52e of the 802.15.4e specification seems to be 
1ms.

Best regards, Rene

On 6/20/2014 4:54 PM, Martin Turon wrote:
>
> The 4ms TsTxAckDelay came from OpenWSN site, which is currently 
> implementing a 15ms slot:
> ------------------------------------------------------------------------
> Martin Turon  |  Nest Labs
>
>
> From: Rene Struik <[email-masked] <mailto:[email-masked]>>
> To: Martin Turon <[email-masked] <mailto:[email-masked]>>
> Cc: Pascal Thubert <[email-masked] <mailto:[email-masked]>>, 
> "S.V.R.Anand" <[email-masked] 
> <mailto:[email-masked]>>, Thomas Watteyne 
> <[email-masked] <mailto:[email-masked]>>, 
> Xavier Vilajosana <[email-masked] 
> <mailto:[email-masked]>>, Kris Pister 
> <[email-masked] <mailto:[email-masked]>>, "Brett, Patricia 
> (PA62)" <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> Please note that my 2.304 Mbps throughput number is based on some 
> crude calculations I did on an (orange-colored Brazil world cup) beer 
> coaster, without necessarily taking into account all parameters of 
> TSCH. If you have parameter sets for various settings, it is not that 
> hard to make this more precise. Where does your TsTxAckDelay figure of 
> 4ms come from?
>
> throughput/percentile distribution for mass-shipped products, where, 
> one should perhaps add some other metrics per product in addition to 
> crypto numbers as well (e.g., clock rate, RAM/ROM on the chip, etc., 
> and which version of 802.15.4 it implements). The latter would allow 
> an assessment on feasibility, irrespective of whatever timeslot 
> numbers one can dream up.
>
> Best regards, Rene
>
>> AES-128 acceleration -- such hw has been standard on 15.4 chipsets 
>> for at least 10 years.
>>
>> 8-bit cores if possible (as they have been for better, or worse, 
>> quite widely deployed).
>>
>> start.  Those are the kind of hard numbers I think we need to make 
>> the decision between a 10ms or 15ms time size.  Is that the 
>> throughput requirement for a 10ms slot or a 15ms slot?
>>
>>     potentially a limiting factor. This makes me wonder: are there
>>     any high-volume 15.4-based shipping products that implement
>>     AES-128 with a throughput of less than 2.304 Mbps (or roughly 10x
>>     the raw 250kbps data rate)? If so, what throughput does AES-128
>>     have in those shipped products? If you have some insight you
>>     could share (either to the list or privately), e.g., in terms of
>>     only implement AES in software, it would be nice to treat those
>>     as separate category, and provide metrics there as well. If this
>>     is the empty set, that would also be good to mention.)
>>
>>     Best regards, Rene
>>
> email:[email-masked]  | Skype: rstruik

---

From: "Brett, Patricia (PA62)" <[email-masked]>
Date: Fri, 20 Jun 2014 23:46:24 +0000

Hi Kris.

Let me try again, and this time I'll try to be more specific because we seem to be talking apples and oranges.

The redesign, etc of primary concern relates to the application. Slot times need to support the needs of the application.  (Note: Application here is intended to mean software that is "above" the 6TiSCH stack, and which 6TiSCH is not defining.) 

The slot time and the application(s) supported are related.
Unquestionably, some applications will work with a 10ms slot time, but others will not.

6TiSCH is described in the architecture document as intended to support a variety of industries and presumably also then the variety of applications used in those industries.  The list in the architecture document may not even be all inclusive.  
 
My point is that 6TiSCH should be entirely application neutral, and by entirely neutral this includes definition for "minimal".  This should be one of the beauties of 6TiSCH.  

You mentioned that IEEE uses 10ms as a default. 
Defining a default value is not the same as stating a requirement. 
A default value represents the option to be taken if and only if no alternative value has been specified by the application, or even in some situations by the user.

Placing 10ms as a requirement for "minimal" devices doesn't seem to be consistent with a "default" approach, or promoting application neutrality.  

Hopefully this explanation was better.

Regards,
Pat

-----Original Message-----
From: 6tisch [mailto:[email-masked]] On Behalf Of Kris Pister
Sent: Thursday, June 19, 2014 6:37 PM
To: [email-masked]
Subject: Re: [6tisch] minimal slot length

Pat - I still don't understand what you're talking about.  This is not Honeywell and Emerson fighting for industrial process automation anymore.
There are at least six low-cost chips from six different vendors that run open source software from several different universities that can all handle 10ms time slots.  That is about as level a playing field as you can find.

Is Dust going to re-engineer it's SmartMesh IP product line to use 10ms?  Well, they're already running at ~7ms, so I guess that they could slow things down and get worse performance, but nothing in that product line speaks 6top, or CoAP, or any DICE, or any of the other standards that are going to make up the stack that everyone is working to define.  

 >  if some vendors are likely to have to undergo redesign, implementation, test, certification  > activities, etc. while other vendors would not,

*Every* single vendor is going to have to undergo redesign, implementation, and test.  There are no vendors who have implemented the standard that we are developing, let alone who sell it.
Everyone is on the same playing field, and it's flat.

10ms is the default in the IEEE standard.  It saves energy and bandwidth in EBs.  It provides more network bandwidth for scheduling.  It's the easiest choice. But it doesn't have to be the choice for everyone.  If there is some reason why you want something other than 10ms, then by all means please write that draft.  If there are other people who want to interop with you, then no one is going to stand in your way.  That's the beauty of the IETF.

ksjp

---

From: "Brett, Patricia (PA62)" <[email-masked]>
Date: Sat, 21 Jun 2014 03:54:11 +0000

Xavi:

I probably would be arguing less with Kris if "Minimal" wasn't called that and was more descriptive of the applications it is aiming to support instead, e.g. "10ms fixed time-slot Mode".

"Minimal" is just a set of agreements about what to put in a document.
E.g. 10ms fixed timeslots or 15ms timeslots  ... whatever is chosen becomes the definition in "Minimal".

The term "Minimal" however has a connotation of being the least possible means of operating. 
But it is only the least IF the Minimal suffices for application use.
We may need better explanatory text in Minimal and/or architecture about what is/isn't supported by Minimal.

Anand:
I understand your proposal as saying:

"Because the experience of applications not using 10ms fixed timeslots is considered less significant than the experience of applications using 10ms fixed timeslots  [why is that?], 6TiSCH expects 10ms will be widely accepted.  [No independent market analysis provided].  Therefore 6TiSCH does not provide application neutrality in the Minimal specification, but rather focuses on the requirements for 10ms fixed timeslot applications. Minimal definition is driven by a particular chunk of a particular industry.  [which chunk of which industry?] This approach may create additional burden to applications which cannot use minimal in a) other chunks of the same industry which cannot use Minimal, as well as to b) other industries.

If that's the case, then the architecture document should
a) explicitly state it as a specific goal;
b) characterize "Minimal" as such only within the context of the goal - i.e. not all applications will be able to use it; 
c) indicate the particular chunk of the particular industry driving the goal & def. of Minimal; and
d) indicate non-Minimal applications / chunks / industries can use 6TiSCH (future work?), but Minimal will not suffice.
(e.g. we could define "Upgraded 6TiSCH" for use by apps that can't use "Minimal 6TiSCH")

What do you think?

Pat

-----Original Message-----
From: S.V.R.Anand [mailto:[email-masked]] 
Sent: Friday, June 20, 2014 4:04 AM
To: Xavier Vilajosana
Cc: [email-masked]; Thomas Watteyne; Kris Pister; Pascal Thubert; Brett, Patricia (PA62); [email-masked]
Subject: Re: [6tisch] minimal slot length

Hi Xavi,

If 10ms is what is going to be widely acceptable to the industry, and therefore being proposed as a starting point to begin with, I think we should stick to this as minimal slot length. After all, we have to respect the amount of implementation experience would have gone into, before arriving at this number.

Any dilution to this seemingly strict requirement to accommodate wider user-base has the danger of isolating, perhaps, a major chunk of industry that wants to deploy 6TiSCH that really want 10ms. If this puts stringent demand on the platforms, so be it, let us make them. Industry requirements are expected to be harsh.

Anand

> Hi Anand,
>
> I think that the debate appears because although 15.4e enables any 
> timeslot length, we are indicating that a minimal configuration for 
> this networks will be using by default this 10ms slots. This of course 
> can be changed, however having this 10ms would be a requirement to be 
> strictly compliant with a minimal implementation.
>
> minimal mode of operation so 6tisch implementers can start with 
> something and be able to inter-operate, also as a fallback mode or 
> super simple best effort mode.
>
> What is important to understand is that this discussion and this draft 
> does not restrict any other mode of operation of 15.4e TSCH, including 
> the possibility of having multiple slotframes with different 
> slotsizes, duo cast, or super optimized scheduling approaches. 
> However, IMHO, this will come in other drafts.
>
> regards,
> Xavi
>
>
>
>
>
>
>> Thanks. Since the standard gives the flexibility inherently I am 
>> puzzled why there is so much debate. It is understood that in the 
>> implementations that use values other than 10ms, those extra bytes 
>> will result. I am sure compressed versions of EB will be invented in 
>> future. This last statement is simple hand waving.
>>
>> Anand
>>
>>
>> > Anand,
>> >
>> > timeslot duration. If you pick 10ms, the EBs are shorter. If you 
>> > pick something different, you must carry the different durations in 
>> > your EB explicitly, which is ~24B of extra data.
>> >
>> > Thomas
>> >
>> >
>> >> other uses cases that need not use 15.4e, there 6tisch is better 
>> >> off in making itself flexible and do not impose itself the 15.4e 
>> >> restriction. Actually
>> 15.4e
>> >> > But do they belong in the *minimal* draft?  My vote is no, 
>> >> > that's
>> not
>> >> what
>> >> > minimal is for.
>> >> >
>> >> >> may be a waste of bandwidth and 10ms would be short for the 
>> >> >> lower
>> >> power
>> >> >> devices, or variations on the MAC with e.g. duocast that 
>> >> >> implies
>> room
>> >> >> for a double ack.
>> >> >>
>> >> >> e.g.  in homes and cars, then any length will do, and if 
>> >> >> there's
>> >> plenty
>> >> >> as a parameter to improve coexistence - at least benefit from 
>> >> >> the slotted aspect of slotted aloha to reduce overlaps.
>> >> >>
>> >> >> mesh for management, time distribution and recovery regardless 
>> >> >> of
>> the
>> >> >> a very general fashion. This means that minimal should be able 
>> >> >> to
>> >> adapt
>> >> >> If the environment is predominantly using Wireless HART then 
>> >> >> the
>> >> minimal
>> >> >> should be able to align to that slot duration. If it is 
>> >> >> something
>> >> else
>> >> >> it should be able to adapt too, and ISA100 allows for 
>> >> >> configurable durations.
>> >> >>
>> >> >>> ISA100.11a permits a flexible timeslot, so having a flexible 
>> >> >>> time slot in minimal is very important.
>> >> >>>> seems that
>> >> >>> there is a broad desire to go to a 10ms time slot for the 
>> >> >>> minimal draft, rather than 15ms.
>> >> >>> WSN labs, can't run much faster than a 15ms timeslot with a 
>> >> >>> 4MHz
>> >> clock.
>> >> >>>> Comments?  Opinions?
>> >> >>>>
>> >> >>>> ksjp
>> >> >>>>
>> >> >>> ensure that the beacon does not exceed aMaxPHYPacketSize. In 
>> >> >>> this case only the template ID is carried, and the length of 
>> >> >>> the IE is
>> 1
>> >> >>> octet.
>> >> > This message has been scanned for viruses and dangerous content 
>> >> > by MailScanner, and is believed to be clean.
>> >> >
>> >>
>> >>
>> >> --
>> >> This message has been scanned for viruses and dangerous content by 
>> >> MailScanner, and is believed to be clean.
>> >>
>> > This message has been scanned for viruses and dangerous content by 
>> > MailScanner, and is believed to be clean.
>> >
>> This message has been scanned for viruses and dangerous content by 
>> MailScanner, and is believed to be clean.
>>
> This message has been scanned for viruses and dangerous content by 
> MailScanner, 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: Xavier Vilajosana <[email-masked]>
Date: Sat, 21 Jun 2014 11:50:55 +0200

Dear all,

as discussed in the group meeting. Here is the current text describing slot
length for minimal. As we said, the focus is recommendation and enables
other slot lengths. Comments please? My plan is to close this asap so we
can publish the new version of the draft before the cut-off date.

 -------------------------

" The  present document recommends the use of a default slot duration set to
   10ms, however other time slot durations MAY be supported.  If one
   uses a timeslot duration different than 10ms, it is RECOMMENDED to
   use a power-of-two of 10ms (i.e. 20ms, 40ms, 80ms, etc.).  In this
   case, EBs MUST contain the complete TimeSlot IE as described in
   Section 2.4."

...

Section 2.4

...

"A 10ms time slot length is the default value defined by
   [IEEE802154e].  Section 6.4.3.3.3 of the [IEEE802154e] defines a
   default macTimeslotTemplate, i.e. the different duration within the
   slot.  These values are summarized in the following table and MUST be
   used when utilizing the default time slot duration.  In this case,
   the Timeslot IE only transports the macTimeslotTemplateId (0x00) as
   the timing values are well-known.  If a timeslot template other than
   the default is used, the EB MUST contain a TimeSlot IE, which
   requires 25 extra bytes."

2014-06-21 5:54 GMT+02:00 Brett, Patricia (PA62) <
[email-masked]>:

> Xavi:
>
> I probably would be arguing less with Kris if "Minimal" wasn't called that
> and was more descriptive of the applications it is aiming to support
> instead, e.g. "10ms fixed time-slot Mode".
>
> "Because the experience of applications not using 10ms fixed timeslots is
> considered less significant than the experience of applications using 10ms
> fixed timeslots  [why is that?], 6TiSCH expects 10ms will be widely
> accepted.  [No independent market analysis provided].  Therefore 6TiSCH
> does not provide application neutrality in the Minimal specification, but
> rather focuses on the requirements for 10ms fixed timeslot applications.
> Minimal definition is driven by a particular chunk of a particular
> industry.  [which chunk of which industry?] This approach may create
> additional burden to applications which cannot use minimal in a) other
> chunks of the same industry which cannot use Minimal, as well as to b)
> other industries.
>
> b) characterize "Minimal" as such only within the context of the goal -
> i.e. not all applications will be able to use it;
> d) indicate non-Minimal applications / chunks / industries can use 6TiSCH
> (future work?), but Minimal will not suffice.
> Cc: [email-masked]; Thomas Watteyne; Kris Pister; Pascal
> Thubert; Brett, Patricia (PA62); [email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 21 Jun 2014 12:42:00 +0000

Not exactly there Xavi:

My wording is that :

To be complient with this spec, a device ShOULD support the 15.4e timeslot ie as specified in ieee802.15.4e and it SHOULD interpret the absence of the ie in the frame as the default settings, all as specified in 15.4e.

It is RECOMMENDED for a device to support 10ms slot duration and a device that does not should indicate its supported values clearly.

It is RECOMMENDED for a deployment to use the 4e default values in macTimeslotTemplate which includes a timeslot duration of 10ms as well as a number of other settings such as time intervals.

If those default values cannot be ueed, e.g. they are not compatible with the policies, the application requirements or the devices capability, then a given deployment MAY use other settings.

Makes sense ?

Pascal

Le 21 juin 2014 à 11:51, "Xavier Vilajosana" <[email-masked]<mailto:[email-masked]>> a écrit :

Dear all,

as discussed in the group meeting. Here is the current text describing slot length for minimal. As we said, the focus is recommendation and enables other slot lengths. Comments please? My plan is to close this asap so we can publish the new version of the draft before the cut-off date.

...

Section 2.4

...

2014-06-21 5:54 GMT+02:00 Brett, Patricia (PA62) <[email-masked]<mailto:[email-masked]>>:
Xavi:

Anand:

What do you think?

Pat

-----Original Message-----
From: S.V.R.Anand [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, June 20, 2014 4:04 AM
To: Xavier Vilajosana
Cc: [email-masked]<mailto:[email-masked]>; Thomas Watteyne; Kris Pister; Pascal Thubert; Brett, Patricia (PA62); [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] minimal slot length

Hi Xavi,

Anand

> 2014-06-20 5:20 GMT+02:00 <[email-masked]<mailto:[email-masked]>>:
>
>> Thomas,
>>
>> > On Thu, Jun 19, 2014 at 7:34 PM, <[email-masked]<mailto:[email-masked]>> wrote:
>> >
>> >> > From: Kris Pister [mailto:[email-masked]<mailto:[email-masked]>]
>> >> > To: Pascal Thubert (pthubert); Brett, Patricia (PA62);
>> >> >>> From: 6tisch [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
>> >> >>> Kris Pister
>> >> >>> To: Brett, Patricia (PA62); [email-masked]<mailto:[email-masked]>
>> >> >>>> From: 6tisch [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
>> >> >>>> Kris Pister
>> >> >>>> To: [email-masked]<mailto:[email-masked]>

---

From: "S.V.R.Anand" <[email-masked]>
Date: Sat, 21 Jun 2014 22:20:01 +0530

Pat,

My mail is intended to be a cautionary note, although strongly worded, 
on the value we set as minimal.

I think the subsequent mails from all of you have already addressed this 
issue.

Thanks

Anand

---

From: "Timothy J. Salo" <[email-masked]>
Date: Sat, 21 Jun 2014 11:56:29 -0500

On 6/21/2014 7:42 AM, Pascal Thubert (pthubert) wrote:
> My wording is that :
>
> To be complient with this spec, a device ShOULD support the 15.4e
> timeslot ie as specified in ieee802.15.4e and it SHOULD interpret the
> absence of the ie in the frame as the default settings, all as specified
> in 15.4e.
>
> It is RECOMMENDED for a device to support 10ms slot duration and a
> device that does not should indicate its supported values clearly.
>
> It is RECOMMENDED for a deployment to use the 4e default values in
> macTimeslotTemplate which includes a timeslot duration of 10ms as well
> as a number of other settings such as time intervals.
>
> If those default values cannot be ueed, e.g. they are not compatible
> with the policies, the application requirements or the devices
> capability, then a given deployment MAY use other settings.
>
> Makes sense ?

Does that mean that two implementations that are compliant with
a spec containing this language might not interoperate?

I'm a big fan of "interoperability" meaning that any device
that conforms to the specification interoperates with any other
conformant device, without the need for manual configuration.
Yes, I understand that is a pretty strong requirement, and that it
isn't always observed within the IETF.  But, we all expect that
we can walk into a coffee shop and that our laptops will connect
to the Internet, without the need for any manual IP configuration.
Shouldn't that be the objective here?

-tjs

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 21 Jun 2014 19:32:31 +0000

Hello Timothy:

It means that if there is a lower denominator then a given deployment may use it.

How is that different for 15.4e? 

Pascal

> Le 21 juin 2014 à 18:56, "Timothy J. Salo" <[email-masked]> a écrit :
>

---

From: Xavier Vilajosana <[email-masked]>
Date: Sun, 22 Jun 2014 07:29:51 +0200

Hi,

indeed, interoperability is guaranteed as networks not using a default
value will be advertising their configuration so others can learn it and
join the network.

X

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 23 Jun 2014 13:45:38 +0000

Forwarding from Dan,

-----Original Message-----
From: Sexton, Daniel W (GE Global Research) [mailto:[email-masked]] 
Sent: lundi 23 juin 2014 14:51
To: 6tisch
Subject: RE: [6tisch] minimal slot length

Hi All, 

I have not chimed in on the 10msec time slot issue or anything else 6tisch but thought it was time. First let me thank you for all the great work you are doing, I look forward to the conclusion and hope that it will be useful in our applications. 

I have to agree with Timothy's example of WiFi in a coffee shop, this type of plug and play is almost expected today. But for WiFI this does not happen because the standards for it make it happen, it happens because the standards have the options to allow  it to be possible and it is the WiFi Alliance that not only certifies that a device conforms to the standards but also conforms to a profile or operating modes established by the WiFi Alliance that assure interoperability across multiple Phys. In my opinion this is how 6tsch should work, there are many 15.4 phys and they are used for many applications. GE has 15.4 applications in industrial, medical, and commercial that use a variety of time slots based solely on their application needs. It is impractical for them to all support 10 msec or any other fixed time slot. 

As you may know, GE uses a 15.4 radio in street lighting applications, Large municipalities like the San Diego are covered with thousands of nodes. These are not operating on 10msec. In the future we would definitely consider a standard protocol like 6tsch in this application depending on how it evolves. Most of our applications do not need or want the "coffee shop" ubiquitous connectivity but we do want the ability for vendor interoperability given a particular application profile (like one defined by an industry Alliance). 

My opinion in this case would be to leave it flexible and allow the applications to determine what they need and to stay forward thinking by being able to accommodate the evolution of phys.

Great work - it is appreciated and I look forward to the conclusion and in making this a better connected world.

Daniel Sexton
GE Global Research
One Research Circle
Niskayuna, NY
12309
O: 518-387-4121
M:518-424-5728
DC:*833-4121

---

From: Qin Wang <[email-masked]>
Date: Mon, 23 Jun 2014 13:02:41 -0700

Hi Pascal,

I cannot understand "It is RECOMMENDED for a device to support 10ms slot duration and a device that does not should indicate its supported values clearly." very well. 

A 6tisch network is formed based on EB, Even the timeslot template is not notified in EB explicitly, the EB still carry the information about timeslot templet, i.e. default timeslot template is used. Right? Then my question is: how a device indicate its supported values clearly and why it is needed?

Thanks
Qin

On Saturday, June 21, 2014 8:42 PM, Pascal Thubert (pthubert) <[email-masked]> wrote:

Not exactly there Xavi:

My wording is that :

Makes sense ?

Pascal

Le 21 juin 2014 à 11:51, "Xavier Vilajosana" <[email-masked]> a écrit :

Dear all, 
>2014-06-21 5:54 GMT+02:00 Brett, Patricia (PA62) <[email-masked]>:
>
>Xavi:
>>
>>"Because the experience of applications not using 10ms fixed timeslots is considered less significant than the experience of applications using 10ms fixed timeslots  [why is that?], 6TiSCH expects 10ms will be widely accepted.  [No independent market analysis
 provided].  Therefore 6TiSCH does not provide application neutrality in the Minimal specification, but rather focuses on the requirements for 10ms fixed timeslot applications. Minimal definition is driven by a particular chunk of a particular industry.  [which
 chunk of which industry?] This approach may create additional burden to applications which cannot use minimal in a) other chunks of the same industry which cannot use Minimal, as well as to b) other industries.
>>If 10ms is what is going to be widely acceptable to the industry, and therefore being proposed as a starting point to begin with, I think we should stick to this as minimal slot length. After all, we have to respect the amount of implementation experience would
 have gone into, before arriving at this number.
>>
>>Any dilution to this seemingly strict requirement to accommodate wider user-base has the danger of isolating, perhaps, a major chunk of industry that wants to deploy 6TiSCH that really want 10ms. If this puts stringent demand on the platforms, so be it, let
 us make them. Industry requirements are expected to be harsh.

---

From: Qin Wang <[email-masked]>
Date: Wed, 25 Jun 2014 11:05:06 -0700

Hi Rene, Martin, and all,

For giving some quantitative idea about the computation time of AES and then CCM*, I present some evaluation result done by my students.

The setting is  Cortex-M3 MCU (STM32F103RE) plus IEEE 802.15.4 radio (AT86RF231ZU). Besides conventional implementation in software and hardware, my students invents a new software implementation of AES, called 1-Table scheme, which is also evaluated based on same setting.

Computation time ( unit: ms). Payload length is
80 Bytes.
Security level 1 2 3 4 5 6 7 
CCM* with software AES 15.005 15.005 15.010 10.115 23.300 23.005 23.320 
CCM* with hardware AES in separated RF chip 1.124 1.127 1.131 0.796 1.591 1.593 1.598 
CCM* with our 1-Table based AES software implementation 0.474 0.477 0.482 0.407 0.733 0.735 0.740 
 
The security level defined as follows in IEEE802.15.4.
Security level C data 
0 None 
1 MIC-32 
2 MIC-64 
3 MIC-128 
4 EncryptedPrivatePayloadfield 
5 EncryptedPrivatePayloadfield|| MIC-32 
6 EncryptedPrivatePayloadfield|| MIC-64 
7 EncryptedPrivatePayloadfield|| MIC-128 
Hope it is helpful.

Thanks
Qin

On Saturday, June 21, 2014 5:12 AM, Rene Struik <[email-masked]> wrote:

Hi Martin:

BTW - I had a brief look at the OpenWSN website, but could not
      find the AES throughput numbers (or other metrics, such as
      RAM/ROM, clockspeed) I was curious about. I did see some confusing
      language in the section called "Adding Security"
      (https://openwsn.atlassian.net/wiki/display/OW/Adding+Security), which suggested that one uses a very inefficient decryption procedure with OpenWSN. From a (very!) cursory view, it seems one can perhaps do a factor 2x better. (Please let me know offline whether you want to discuss this more.)

For a technical discussion, it would be really good to provide
      some hard evidence re AES numbers (so as to avoid beauty contests
      of whatever timeslot figure people are familiar with). Hence, my
      email earlier this afternoon, in an attempt to quantify where
      potential issues may be and to see which issues are perceived and
      which are real.

The TsTxACKdelay in Table 52e of the 802.15.4e specification seems
      to be 1ms.

Best regards, Rene

On 6/20/2014 4:54 PM, Martin Turon wrote:

>
>The 4ms TsTxAckDelay came from OpenWSN site, which is currently implementing a 15ms slot:
>https://openwsn.atlassian.net/wiki/display/OW/Timing+Constants  (15ms timing)
>      https://openwsn.atlassian.net/wiki/display/OW/State+Machine  (generic slot timing)
>
>
>________________________________
>
>Martin Turon  |  Nest Labs
>
>
>
>
>Cc:  Pascal Thubert <[email-masked]>, "S.V.R.Anand" <[email-masked]>, Thomas Watteyne <[email-masked]>, Xavier Vilajosana <[email-masked]>, Kris Pister <[email-masked]>, "Brett, Patricia (PA62)" <[email-masked]>, "[email-masked]" <[email-masked]>
Hi Martin:

Please note that my 2.304 Mbps throughput number is based
              on some crude calculations I did on an (orange-colored
              Brazil world cup) beer coaster, without necessarily taking
              into account all parameters of TSCH. If you have parameter
              sets for various settings, it is not that hard to make
              this more precise. Where does your TsTxAckDelay figure of
              4ms come from?

It would be good to have some more detailed insight on the
              AES throughput/percentile distribution for mass-shipped
              products, where, one should perhaps add some other metrics
              per product in addition to crypto numbers as well (e.g.,
              clock rate, RAM/ROM on the chip, etc., and which version
              of 802.15.4 it implements). The latter would allow an
              assessment on feasibility, irrespective of whatever
              timeslot numbers one can dream up.

Best regards, Rene

Hi Rene, 
>
>
>I think it is reasonable to limit scope of 6tsch minimal to hw with AES-128 acceleration -- such hw has been standard on 15.4 chipsets for at least 10 years.  
>
>
>My main point is that we precisely map out what the minimal hw requirements for minimal tsch are, and that we be inclusive of the 8-bit cores if possible (as they have been for better, or worse, quite widely deployed).
>
>
>Your minimal AES-128 throughput requirement of "2.304 Mbps" is a good start.  Those are the kind of hard numbers I think we need to make the decision between a 10ms or 15ms time size.  Is that the throughput requirement for a 10ms slot or a 15ms slot?
>
>
>I think the main time slot timing requirement is that a RX device be able to decrypt a maximum length 127 byte packet, parse the contents, and respond with an ACK within TsTxAckDelay.
>
>
>#TsTxAckDelay 4000us 
>
>
>Martin
>
>
>
>>Quick question: In your note below, you refer to
                      security being potentially a limiting factor. This
                      makes me wonder: are there any high-volume
                      15.4-based shipping products that implement
                      AES-128 with a throughput of less than 2.304 Mbps
                      (or roughly 10x the raw 250kbps data rate)? If so,
                      what throughput does AES-128 have in those shipped
                      products? If you have some insight you could share
                      (either to the list or privately), e.g., in terms
                      of throughput/percentile of mass shipping, that
                      would be great. (If, in your reference to shipped
                      products, you include those that may only
                      implement AES in software, it would be nice to
                      treat those as separate category, and provide
                      metrics there as well. If this is the empty set,
                      that would also be good to mention.)
>>>getting the minimal to work well with as wide a
                        net of platforms as
6tisch mailing list [email-masked]://www.ietf.org/mailman/listinfo/6tisch

---

From: Rene Struik <[email-masked]>
Date: Wed, 25 Jun 2014 15:06:37 -0400

Hi Qin:

Great! Your data seems to indicate that one can indeed complete 
cryptographic processing in software within 1 ms (for 80-octets payloads).

I would be curious about the "1-Table" algorithm you mentioned. If you 
have a paper or description of this, I would be happy to give this a 
read (you can send to me offline).

Just some analysis of your tables:

Your tables show that the computational time for modes with 
authentication (security levels #1, #2, #3) are more or less the same 
(which they should be, since main difference is a truncation of the 
authenticity tag to the indicated length at the end of the computation). 
The same observation holds for encryption and authentication modes 
(security levels #5, #6, and #7).

I would have expected the computational time for encryption and 
authentication to be more or less the sum of the corresponding figures 
for encryption-only (security level #4) and for authentication-only 
(e.g., time(#6) ~ time (#2) + time(#4), etc.). There is a small 
difference there of roughly 2ms (CCM* w/ software AES), 0.22ms (CCM* w/ 
HW AES in separate chip), and 0.15ms (CCM* w/ 1-Table approach). Would 
this by any chance correspond to roughly the time for a single AES 
operation? {If so, I speculate that your implementation computes one AES 
block in encryption-only mode and then simply throws this away (since 
authenticity tag would have length zero). From your data I speculate 
that formatted authenticated data corresponds to 9 AES blocks, of which 
5 blocks correspond to plaintext (the 80-byte payload you mentioned).}

Best regards, Rene

On 6/25/2014 2:05 PM, Qin Wang wrote:
> For giving some quantitative idea about the computation time of AES 
> and then CCM*, I present some evaluation result done by my students.
>
> The setting is Cortex-M3 MCU (STM32F103RE) plus IEEE 802.15.4 radio 
> (AT86RF231ZU). Besides conventional implementation in software and 
> hardware, my students invents a new software implementation of AES, 
> called 1-Table scheme, which is also evaluated based on same setting.
>
> Computation time ( unit: ms). Payload length is 80 Bytes.
> Security level
> 	
> 1
> 	
> 2
> 	
> 3
> 	
> 4
> 	
> 5
> 	
> 6
> 	
> 7
> CCM* with software AES
> 	
> 15.005
> 	
> 15.005
> 	
> 15.010
> 	
> 10.115
> 	
> 23.300
> 	
> 23.005
> 	
> 23.320
> CCM* with hardware AES in separated RF chip
> 	
> 1.124
> 	
> 1.127
> 	
> 1.131
> 	
> 0.796
> 	
> 1.591
> 	
> 1.593
> 	
> 1.598
> CCM* with our 1-Table based AES software implementation
> 	
> 0.474
> 	
> 0.477
> 	
> 0.482
> 	
> 0.407
> 	
> 0.733
> 	
> 0.735
> 	
> 0.740
>
> Security level
> C data
> 0
> None
> MIC-32
> 2
> MIC-64
> 3
> MIC-128
> 4
> EncryptedPrivatePayloadfield
> 5
> 	
> EncryptedPrivatePayloadfield|| MIC-32
> 6
> 	
> EncryptedPrivatePayloadfield|| MIC-64
> 7
> 	
> EncryptedPrivatePayloadfield|| MIC-128
>
>
> Hope it is helpful.
>
> Thanks
> Qin
>
>
>
> BTW - I had a brief look at the OpenWSN website, but could not find 
> the AES throughput numbers (or other metrics, such as RAM/ROM, 
> clockspeed) I was curious about. I did see some confusing language in 
> the section called "Adding Security" 
> For a technical discussion, it would be really good to provide some 
> hard evidence re AES numbers (so as to avoid beauty contests of 
> whatever timeslot figure people are familiar with). Hence, my email 
> earlier this afternoon, in an attempt to quantify where potential 
> issues may be and to see which issues are perceived and which are real.
>
> The TsTxACKdelay in Table 52e of the 802.15.4e specification seems to 
> be 1ms.
>
> Best regards, Rene
>
>> [email-masked]  <mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tisch
>
>
> -- 
> email:[email-masked]  <mailto:[email-masked]>  | Skype: rstruik
> email:[email-masked]  <mailto:[email-masked]>  | Skype: rstruik

---

From: Xavier Vilajosana <[email-masked]>
Date: Fri, 27 Jun 2014 05:42:57 +0200

Hi Pascal,

I integrated some of your text to the minimal draft: See the result:

"The present document RECOMMENDS the use of a default slot duration set to
   10ms and its corresponding default timeslot timings defined by the
IEEE802154e macTimeslotTemplate.
   The use of the default macTimeslotTemplate MUST be announced in the EB
by using the Timeslot IE containing only the default macTimeslotTemplateId.
   Other time slot durations MAY be supported and announced clearly. If one
   uses a timeslot duration different than 10ms, it is RECOMMENDED to
   use a power-of-two of 10ms (i.e. 20ms, 40ms, 80ms, etc.).  In this
   case, EBs MUST contain the complete TimeSlot IE as described in
   Section 2.4."

I skipped to describe the reasons why a setting might not want to use the
default ts values.

"e.g. they are not compatible with the policies, the application
requirements or the devices capability, then a given deployment MAY use
other settings. "

I think it is not necessary as it is already clear why someone does not
want to use the default value.
I also used MUST to indicate that the TimeSlot IE has to be used in the EB.

what do you think? Any other comments?

X

2014-06-21 14:42 GMT+02:00 Pascal Thubert (pthubert) <[email-masked]>:

> absence of the ie in the frame as the default settings, all as specified in
> 15.4e.
>
> macTimeslotTemplate which includes a timeslot duration of 10ms as well as a
> number of other settings such as time intervals.
>
> with the policies, the application requirements or the devices capability,
> then a given deployment MAY use other settings.
>
>  Makes sense ?
>
> Pascal
>
>  as discussed in the group meeting. Here is the current text describing
> slot length for minimal. As we said, the focus is recommendation and
> enables other slot lengths. Comments please? My plan is to close this asap
> so we can publish the new version of the draft before the cut-off date.
>
>> I probably would be arguing less with Kris if "Minimal" wasn't called
>> that and was more descriptive of the applications it is aiming to support

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 27 Jun 2014 05:34:53 +0000

Fine with me, Xavi !

Pascal

Le 27 juin 2014 à 05:43, "Xavier Vilajosana" <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Pascal,

"The present document RECOMMENDS the use of a default slot duration set to
   10ms and its corresponding default timeslot timings defined by the IEEE802154e macTimeslotTemplate.
   The use of the default macTimeslotTemplate MUST be announced in the EB by using the Timeslot IE containing only the default macTimeslotTemplateId.
   Other time slot durations MAY be supported and announced clearly. If one
   uses a timeslot duration different than 10ms, it is RECOMMENDED to
   use a power-of-two of 10ms (i.e. 20ms, 40ms, 80ms, etc.).  In this
   case, EBs MUST contain the complete TimeSlot IE as described in
   Section 2.4."

I skipped to describe the reasons why a setting might not want to use the default ts values.

"e.g. they are not compatible with the policies, the application requirements or the devices capability, then a given deployment MAY use other settings. "

I think it is not necessary as it is already clear why someone does not want to use the default value.
I also used MUST to indicate that the TimeSlot IE has to be used in the EB.

X

2014-06-21 14:42 GMT+02:00 Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>:
Not exactly there Xavi:

My wording is that :

Makes sense ?

Pascal

Dear all,

...

Section 2.4

...

Anand:

What do you think?

Pat

-----Original Message-----
From: S.V.R.Anand [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, June 20, 2014 4:04 AM
To: Xavier Vilajosana
Cc: [email-masked]<mailto:[email-masked]>; Thomas Watteyne; Kris Pister; Pascal Thubert; Brett, Patricia (PA62); [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] minimal slot length

Hi Xavi,

Anand

---

From: Kris Pister <[email-masked]>
Date: Fri, 27 Jun 2014 10:20:21 -0700

me too.

ksjp

On 6/26/2014 10:34 PM, Pascal Thubert (pthubert) wrote:
> Fine with me, Xavi !
>
> Pascal
>
> Le 27 juin 2014 à 05:43, "Xavier Vilajosana" 
> <[email-masked] <mailto:[email-masked]>> 
> a écrit :
>
>> Hi Pascal,
>>
>>    The use of the default macTimeslotTemplate MUST be announced in 
>> the EB by using the Timeslot IE containing only the default 
>> macTimeslotTemplateId.
>> requirements or the devices capability, then a given deployment MAY 
>> use other settings. "
>>
>> 2014-06-21 14:42 GMT+02:00 Pascal Thubert (pthubert) 
>> <[email-masked] <mailto:[email-masked]>>:
>>
>>     Not exactly there Xavi:
>>
>>     My wording is that :
>>
>>     timeslot ie as specified in ieee802.15.4e and it SHOULD interpret
>>     the absence of the ie in the frame as the default settings, all
>>     as specified in 15.4e.
>>
>>     It is RECOMMENDED for a device to support 10ms slot duration and
>>     a device that does not should indicate its supported values clearly.
>>
>>     It is RECOMMENDED for a deployment to use the 4e default values
>>     in macTimeslotTemplate which includes a timeslot duration of 10ms
>>     as well as a number of other settings such as time intervals.
>>
>>     If those default values cannot be ueed, e.g. they are not
>>     compatible with the policies, the application requirements or the
>>     devices capability, then a given deployment MAY use other settings.
>>
>>     Makes sense ?
>>
>>     Pascal
>>
>>     Le 21 juin 2014 à 11:51, "Xavier Vilajosana"
>>     <[email-masked]
>>     <mailto:[email-masked]>> a écrit :
>>
>>>     Dear all,
>>>
>>>     as discussed in the group meeting. Here is the current text
>>>     describing slot length for minimal. As we said, the focus is
>>>     recommendation and enables other slot lengths. Comments please?
>>>     My plan is to close this asap so we can publish the new version
>>>     of the draft before the cut-off date.
>>>
>>>     2014-06-21 5:54 GMT+02:00 Brett, Patricia (PA62)
>>>     <[email-masked]
>>>     <mailto:[email-masked]>>:
>>>
>>>         Xavi:
>>>
>>>         I probably would be arguing less with Kris if "Minimal"
>>>         wasn't called that and was more descriptive of the
>>>         applications it is aiming to support instead, e.g. "10ms
>>>         fixed time-slot Mode".
>>>
>>>         E.g. 10ms fixed timeslots or 15ms timeslots  ... whatever is
>>>         chosen becomes the definition in "Minimal".
>>>
>>>         We may need better explanatory text in Minimal and/or
>>>         architecture about what is/isn't supported by Minimal.
>>>
>>>
>>>         Anand:
>>>         "Because the experience of applications not using 10ms fixed
>>>         timeslots is considered less significant than the experience
>>>         of applications using 10ms fixed timeslots  [why is that?],
>>>         6TiSCH expects 10ms will be widely accepted.  [No
>>>         independent market analysis provided].  Therefore 6TiSCH
>>>         does not provide application neutrality in the Minimal
>>>         specification, but rather focuses on the requirements for
>>>         10ms fixed timeslot applications. Minimal definition is
>>>         driven by a particular chunk of a particular industry.
>>>          [which chunk of which industry?] This approach may create
>>>         additional burden to applications which cannot use minimal
>>>         in a) other chunks of the same industry which cannot use
>>>         Minimal, as well as to b) other industries.
>>>
>>>         b) characterize "Minimal" as such only within the context of
>>>         the goal - i.e. not all applications will be able to use it;
>>>         d) indicate non-Minimal applications / chunks / industries
>>>         can use 6TiSCH (future work?), but Minimal will not suffice.
>>>         Cc: [email-masked]
>>>         <mailto:[email-masked]>; Thomas Watteyne; Kris
>>>         Pister; Pascal Thubert; Brett, Patricia (PA62);
>>>         If 10ms is what is going to be widely acceptable to the
>>>         industry, and therefore being proposed as a starting point
>>>         to begin with, I think we should stick to this as minimal
>>>         slot length. After all, we have to respect the amount of
>>>         implementation experience would have gone into, before
>>>         arriving at this number.
>>>
>>>         Any dilution to this seemingly strict requirement to
>>>         accommodate wider user-base has the danger of isolating,
>>>         perhaps, a major chunk of industry that wants to deploy
>>>         6TiSCH that really want 10ms. If this puts stringent demand
>>>         on the platforms, so be it, let us make them. Industry
>>>         requirements are expected to be harsh.
>>>
>>>
>>>         Anand
>>>
>>>
>>>
>>>         > Hi Anand,
>>>         >
>>>         >> > On Thu, Jun 19, 2014 at 7:34 PM,
>>>         <[email-masked] <mailto:[email-masked]>>
>>>         wrote:
>>>         >> >
>>>         >> >> If 6tisch's main objective  is to work strictly on
>>>         15.4e, and if
>>>         >> 15.4e
>>>         >> >> > Minimal should be considering the communication
>>>         needs of devices
>>>         >> >> > in
>>>         >> >> use
>>>         >> >> > today.
>>>         >> >> >> I read that discussion as there is no fits-it-all
>>>         slot duration.
>>>         >> 15ms
>>>         >> >> >> we did not resolve. If minimal is to be used as a
>>>         ship in the
>>>         >> night,
>>>         >> >> >> f bandwidth then the 15ms has more chances to
>>>         accommodate all
>>>         >> >> parties.
>>>         >> >> >>
>>>         >> >> >> the 802.15.4e MAC, then the slot duration for
>>>         minimal becomes
>>>         >> >> important
>>>         >> >> >> I am in the camp that believes that there is a need
>>>         for an
>>>         >> always-on
>>>         >> >> >> All in all, my vote would go to a configurable
>>>         duration, with a
>>>         >> range
>>>         >> >> >> ISA100.11a slot, or if, due to units or whatnot,
>>>         this cannot be
>>>         >> >> achieved
>>>         >> >> >> at all?
>>>         >> >> >>
>>>         >> >> >> Cheers,
>>>         >> >> >>
>>>         >> >> >> Pascal
>>>         >> >> >>
>>>         >> >> >>
>>>         >> >> >>> From: 6tisch [mailto:[email-masked]
>>>         <mailto:[email-masked]>] On Behalf Of
>>>         >> >> >>> Kris Pister
>>>         <mailto:[email-masked]>
>>>         >> >> >>>  15.4e and 6TiSCH certainly do and will permit
>>>         flexible time
>>>         >> >> slots,
>>>         >> >> >>> like ISA100.11a.
>>>         >> >> >>> constrain more advanced future designs, which can
>>>         certainly
>>>         >> specify
>>>         >> >> >>> For now though, "minimal" means to me that we
>>>         should pick a
>>>         >> single
>>>         >> >> >>> timeslot length.
>>>         >> >> >>>> From: 6tisch [mailto:[email-masked]
>>>         <mailto:[email-masked]>] On Behalf Of
>>>         >> >> >>>> Kris Pister
>>>         >> >> >>>> To: [email-masked] <mailto:[email-masked]>
>>>         >> >> >>>> It would be convenient to use the default
>>>         timeslot from 15.4e
>>>         >> >> >>>> (10ms),
>>>         >> >> >>>> (~2004) of the Berkeley motes project and still a
>>>         workhorse
>>>         >> >> >>>> in academic
>>>         >> >> >>>> The full time-slot template may be omitted from
>>>         the enhanced
>>>         >> beacon
>>>         >> >> >>>> to
>>>         dangerous content
>>>         dangerous content by
>>>         This message has been scanned for viruses and dangerous
>>>         content by MailScanner, and is believed to be clean.
>>>
>>>
>>

---

From: "S.V.R.Anand" <[email-masked]>
Date: Fri, 27 Jun 2014 23:26:03 +0530

Hi Xavi,

Nicely worded. Fine with me too !

Anand

> <[email-masked]<mailto:[email-masked]>> a
> écrit :
>
> Hi Pascal,
>
> <[email-masked]<mailto:[email-masked]>>:
> Not exactly there Xavi:
>
> My wording is that :
>
> To be complient with this spec, a device ShOULD support the 15.4e timeslot
> ie as specified in ieee802.15.4e and it SHOULD interpret the absence of
> the ie in the frame as the default settings, all as specified in 15.4e.
>
> It is RECOMMENDED for a device to support 10ms slot duration and a device
> that does not should indicate its supported values clearly.
>
> macTimeslotTemplate which includes a timeslot duration of 10ms as well as
> a number of other settings such as time intervals.
>
> If those default values cannot be ueed, e.g. they are not compatible with
> the policies, the application requirements or the devices capability, then
> a given deployment MAY use other settings.
>
> Makes sense ?
>
> Pascal
>
> <[email-masked]<mailto:[email-masked]>> a
> écrit :
>
> Dear all,
>
> <[email-masked]<mailto:[email-masked]>>:
> Xavi:
>
> From: S.V.R.Anand
> [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: [email-masked]<mailto:[email-masked]>; Thomas
> Watteyne; Kris Pister; Pascal Thubert; Brett, Patricia (PA62);
>> 2014-06-20 5:20 GMT+02:00
>> <[email-masked]<mailto:[email-masked]>>:
>>
>>> Thomas,
>>>
>>> <[email-masked]<mailto:[email-masked]>> wrote:
>>> >
>>> >> > From: Kris Pister
>>> [mailto:[email-masked]<mailto:[email-masked]>]
>>> >> >>> From: 6tisch
>>> [mailto:[email-masked]<mailto:[email-masked]>]
>>> On Behalf Of
>>> >> >>> Kris Pister
>>> >> >>>> From: 6tisch
>>> [mailto:[email-masked]<mailto:[email-masked]>]
>>> On Behalf Of
>>> >> >>>> Kris Pister

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 27 Jun 2014 17:57:30 +0000

There might be some ambiguity that could be removed:
The use of the default macTimeslotTemplate MUST
Seems to indicate that we do not want to save the 25 bytes.

And
Other time slot durations MAY be supported and announced clearly.
Do you mean in the EB? If so then MUST be announced if it is non default.

 I meant that in any case what a product supports MUST be clearly announced (doc, packaging), in particular if the device does not support the recommended default...

Pascal

Le 27 juin 2014 à 19:19, "Kris Pister" <[email-masked]<mailto:[email-masked]>> a écrit :

me too.

ksjp

Pascal

Hi Pascal,

X

My wording is that :

Makes sense ?

Pascal

Dear all,

...

Section 2.4

...

Anand:

What do you think?

Pat

-----Original Message-----
From: S.V.R.Anand [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, June 20, 2014 4:04 AM
To: Xavier Vilajosana
Cc: [email-masked]<mailto:[email-masked]>; Thomas Watteyne; Kris Pister; Pascal Thubert; Brett, Patricia (PA62); [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] minimal slot length

Hi Xavi,

Anand

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 27 Jun 2014 10:58:38 -0700

+1, looks good Xavi

On Fri, Jun 27, 2014 at 10:56 AM, S.V.R.Anand <[email-masked]>
wrote:

> timeslot