Subject: [6tisch] More control of the minimal schedule

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 6 May 2014 13:55:50 +0000

Hello Xavi

I'm unsure what the status is for the various questions we had at the last IETF WRT the capability to tune the static schedule for minimal.

For instance Qin suggested to make the size of the slotframe adjustable to cope with larger networks.

It could also be interesting to have some additional control like which are the cells in use.
Say I run a number of such networks in a same room and I can get them synchronized through a backbone.
Maybe I'd be interested to run a minimal RPL network with the slotoffsets that you describe but vary the channel offset.
Or I'd vary the slotoffsets to be those you provide in the draft for the first network then the same + 10 for the second, etc...

There may be a need to make the bootstrap faster and allow for costly security exchanges, by having all slots active initially and the move to the reference slotframe after a certain time.

Maybe it would be good to make a status at the next Friday call if you are available?

Cheers,

Pascal

---

From: Xavier Vilajosana <[email-masked]>
Date: Tue, 6 May 2014 22:02:44 +0200

Hi Pascal,
the discussion is still open. We've been very busy with 6top.

On the one hand, I like your idea of being able to slide the cells in the
slot frame while keeping the minimal configuration. The slicing can be done
by specifying a slotOffset and a inter-cell offset which might be useful to
keep better synchronization.

On the other hand, I am afraid of breaking the concept of fallback mode and
minimal configuration equal for everyone.

Maybe we can discuss this in one of the following calls.

X

2014-05-06 15:55 GMT+02:00 Pascal Thubert (pthubert) <[email-masked]>:

>  Hello Xavi
>
>
>
> I’m unsure what the status is for the various questions we had at the last
> IETF WRT the capability to tune the static schedule for minimal.
>
>
>
> Maybe I’d be interested to run a minimal RPL network with the slotoffsets
> that you describe but vary the channel offset.
>
> Or I’d vary the slotoffsets to be those you provide in the draft for the
> first network then the same + 10 for the second, etc…
>
>
>
> There may be a need to make the bootstrap faster and allow for costly
> security exchanges, by having all slots active initially and the move to
> the reference slotframe after a certain time.
>
>
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: Kris Pister <[email-masked]>
Date: Tue, 06 May 2014 13:59:14 -0700

Pascal - I agree with Xavi.  I like the idea, but it is not "minimal".  
Minimal should really be
minimal.  There are many useful and obvious improvements that can be 
added to minimal...
but then it's not minimal.

ksjp

On 5/6/2014 1:02 PM, Xavier Vilajosana wrote:
> On the one hand, I like your idea of being able to slide the cells in 
> the slot frame while keeping the minimal configuration. The slicing 
> can be done by specifying a slotOffset and a inter-cell offset which 
> might be useful to keep better synchronization.
>
> On the other hand, I am afraid of breaking the concept of fallback 
> mode and minimal configuration equal for everyone.
>
> 2014-05-06 15:55 GMT+02:00 Pascal Thubert (pthubert) 
> <[email-masked] <mailto:[email-masked]>>:
>
>     Hello Xavi
>
>     I'm unsure what the status is for the various questions we had at
>     the last IETF WRT the capability to tune the static schedule for
>     minimal.
>
>     Maybe I'd be interested to run a minimal RPL network with the
>     slotoffsets that you describe but vary the channel offset.
>
>     Or I'd vary the slotoffsets to be those you provide in the draft
>     for the first network then the same + 10 for the second, etc...
>
>     There may be a need to make the bootstrap faster and allow for
>     costly security exchanges, by having all slots active initially
>     and the move to the reference slotframe after a certain time.
>
>     [email-masked] <mailto:[email-masked]>

---

From: Tom Phinney <[email-masked]>
Date: Tue, 06 May 2014 16:24:25 -0700

Perhaps there's a way to have both: to have a default fixed
truly-minimal configuration along with a means of indicating that
observing nodes should watch for and acquire information about an
extended-default mode that is parametrized in just a few bytes,
rather than the many bytes needed to communicate a more-specialized
schedule.

Having two mechanisms permits the best of both worlds at relatively
low cost: 1) a minimal schedule that uses very few resources, and 2)
a concisely-parametrized means of activating an extended default
schedule for those situations where many nodes are starting
concurrently (e.g., after somebody stops the jammers, or after the
tornado with its flying metal objects has passed), which would
facilitate more-rapid network rebuild/recovery than is possible with
just the minimal default schedule.

-Tom

====

On 2014.05.06 13:59, Kris Pister wrote:

Pascal - I agree with Xavi.  I like the idea, but it is not
"minimal".  Minimal should really be

minimal.  There are many useful and obvious improvements that can
be added to minimal...

ksjp

On 5/6/2014 1:02 PM, Xavier
Vilajosana wrote:

Hi Pascal,

the discussion is still open. We've been very busy with
6top.

On the one hand, I like your idea of being able to slide
the cells in the slot frame while keeping the minimal
configuration. The slicing can be done by specifying a
slotOffset and a inter-cell offset which might be useful to
keep better synchronization.

On the other hand, I am afraid of breaking the concept of
fallback mode and minimal configuration equal for everyone.

X

2014-05-06 15:55 GMT+02:00 Pascal
Thubert (pthubert) <[email-masked]>:

Hello Xavi

I’m unsure what the status is for
the various questions we had at the last IETF WRT
the capability to tune the static schedule for
minimal.

For instance Qin suggested to
make the size of the slotframe adjustable to cope
with larger networks.

It could also be interesting to
have some additional control like which are the
cells in use.

Say I run a number of such
networks in a same room and I can get them
synchronized through a backbone.

Maybe I’d be interested to run a
minimal RPL network with the slotoffsets that you
describe but vary the channel offset.

Or I’d vary the slotoffsets to be
those you provide in the draft for the first network
then the same + 10 for the second, etc…

There may be a need to make the
bootstrap faster and allow for costly security
exchanges, by having all slots active initially and
the move to the reference slotframe after a certain
time.

Maybe it would be good to make a
status at the next Friday call if you are available?

Cheers,

Pascal

6tisch mailing list

[email-masked]

---

From: Kris Pister <[email-masked]>
Date: Tue, 06 May 2014 16:38:38 -0700

I like that approach.

The debate will of course be about the meaning of the parameters in the 
few bytes.
I believe that will be a fruitful debate, and I do think that it's best 
to keep that
separate from minimal.

ksjp

On 5/6/2014 4:24 PM, Tom Phinney wrote:
> extended-default mode that is parametrized in just a few bytes, rather 
> than the many bytes needed to communicate a more-specialized schedule.
>
> low cost: 1) a minimal schedule that uses very few resources, and 2) a 
> concisely-parametrized means of activating an extended default 
>>> On the one hand, I like your idea of being able to slide the cells 
>>> in the slot frame while keeping the minimal configuration. The 
>>> slicing can be done by specifying a slotOffset and a inter-cell 
>>> offset which might be useful to keep better synchronization.
>>>
>>>     I'm unsure what the status is for the various questions we had
>>>     at the last IETF WRT the capability to tune the static schedule
>>>     for minimal.
>>>

---

From: Qin Wang <[email-masked]>
Date: Tue, 6 May 2014 18:22:26 -0700 (PDT)

Hi Pascal and all,

Firstly, I agree on the principle that minimal draft should be kept very simple. 

Secondly, Pascal, regarding to your idea, I do not understand very well. According to my understanding, the number of networks run in the same room will base on different ASNs, and thus, even they use same slotframe arrangement, there is very low possibility for them to overlap. Right? Maybe I miss something.

Thanks
Qin 
On Wednesday, May 7, 2014 7:39 AM, Kris Pister <[email-masked]> wrote:
 
I like that approach.

The debate will of course be about the meaning of the parameters in
    the few bytes.
I believe that will be a fruitful debate, and I do think that it's
    best to keep that
separate from minimal.

ksjp

Perhaps there's a way to have both: to have a default fixed truly-minimal configuration along with a means of indicating that observing nodes should watch for and acquire information about an extended-default mode that is parametrized in just a few bytes, rather than the many bytes needed to communicate a more-specialized schedule. 

Having two mechanisms permits the best of both worlds at
      relatively low cost: 1) a minimal schedule that uses very few
      resources, and 2) a concisely-parametrized means of activating an
      extended default schedule for those situations where many nodes
      are starting concurrently (e.g., after somebody stops the jammers,
      or after the tornado with its flying metal objects has passed),
      which would facilitate more-rapid network rebuild/recovery than is
      possible with just the minimal default schedule.

-Tom
====

Pascal - I agree with Xavi.  I like the idea, but it is not "minimal".  Minimal should really be
minimal.  There are many useful and obvious improvements that
        can be added to minimal...
but then it's not minimal.

ksjp

Hi Pascal, 
>On the one hand, I like your idea of being able to slide the cells in the slot frame while keeping the minimal configuration. The slicing can be done by specifying a slotOffset and a inter-cell offset which might be useful to keep better synchronization.
>
>
>On the other hand, I am afraid of breaking the concept of fallback mode and minimal configuration equal for everyone.
>
>
>>I’m unsure what the status is for the various questions we had at the last IETF WRT the capability to tune the static schedule for minimal.
>> 
>>Maybe I’d be interested to run a minimal RPL network with the slotoffsets that you describe but vary the channel offset. 
>>Or I’d vary the slotoffsets to be those you provide in the draft for the first network then the same + 10 for the second, etc… 
>> 
6tisch mailing list [email-masked] https://www.ietf.org/mailman/listinfo/6tisch 

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

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

---

From: Xavier Vilajosana <[email-masked]>
Date: Wed, 7 May 2014 05:34:51 +0200

Hi,

I think that this extended mechanism can be OTF, as far as nodes can join
the network, OTF can start working to provide a best fit schedule for them.

Regarding the minimal draft we still have two open issues,

1)if minimal defines a fix number of slots to be pre-configured in the
slotframe, this limits the size of the network or amount of traffic that
can be handled before the network collapses.

2)if slots are contiguous, synchronization might be affected in platforms
where clock drift is high.

to cope with 1) we proposed to study whether the number of slots in a
slotframe can be defined as a function of the size of the network. I think
this approach will work but then nodes in different networks will have
different configurations. I have my doubts that this is a good approach and
I think that we first need to understand what minimal operation means and
what is the type of operation that we want for a network running in a
minimal mode.

For me minimal is an operation mode that can guarantee that a node will be
able to join a network and route its control packets to acquire a better
schedule and support a very little traffic (in case of fallback mode in a
critical situation).

As regards to 2) I think that spacing cells instead of having them
contiguos at the beginning of the slotframe will improve synchronization of
nodes as synchronization windows will be moved from once every 1.5 seconds
to once every 300ms aprox.

what others think?
X

2014-05-07 1:38 GMT+02:00 Kris Pister <[email-masked]>:

> I believe that will be a fruitful debate, and I do think that it's best to
> keep that
> separate from minimal.
>
> ksjp
>
>
> Perhaps there's a way to have both: to have a default fixed truly-minimal
> configuration along with a means of indicating that observing nodes should
> watch for and acquire information about an extended-default mode that is
> parametrized in just a few bytes, rather than the many bytes needed to
> communicate a more-specialized schedule.
>
> Having two mechanisms permits the best of both worlds at relatively low
> cost: 1) a minimal schedule that uses very few resources, and 2) a
> concisely-parametrized means of activating an extended default schedule for
> those situations where many nodes are starting concurrently (e.g., after
> somebody stops the jammers, or after the tornado with its flying metal
> objects has passed), which would facilitate more-rapid network
> rebuild/recovery than is possible with just the minimal default schedule.
>
> -Tom
> ====
> minimal.  There are many useful and obvious improvements that can be added
> to minimal...
> the slot frame while keeping the minimal configuration. The slicing can be
> done by specifying a slotOffset and a inter-cell offset which might be
> useful to keep better synchronization.
>
>  On the other hand, I am afraid of breaking the concept of fallback mode
> and minimal configuration equal for everyone.
>
>> I’m unsure what the status is for the various questions we had at the
>> last IETF WRT the capability to tune the static schedule for minimal.
>>
>>
>>
> 6tisch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tisch
>
>
>
>
> 6tisch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tisch
>
>
>
>
> 6tisch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tisch
>
>
>

---

From: Qin Wang <[email-masked]>
Date: Tue, 6 May 2014 23:31:45 -0700 (PDT)

Hi Xavi,

I want to confirm with you: for a new node, the slotframe information (e.g. size of slotframe, location of active slot) will come from Enhanced Beacon, or be configured in the new node before joining?

Thanks
Qin
On Wednesday, May 7, 2014 11:34 AM, Xavier Vilajosana <[email-masked]> wrote:
 
Hi,

I think that this extended mechanism can be OTF, as far as nodes can join the network, OTF can start working to provide a best fit schedule for them. 

1)if minimal defines a fix number of slots to be pre-configured in the slotframe, this limits the size of the network or amount of traffic that can be handled before the network collapses. 

2)if slots are contiguous, synchronization might be affected in platforms where clock drift is high. 

to cope with 1) we proposed to study whether the number of slots in a slotframe can be defined as a function of the size of the network. I think this approach will work but then nodes in different networks will have different configurations. I have my doubts that this is a good approach and I think that we first need to understand what minimal operation means and what is the type of operation that we want for a network running in a minimal mode. 

For me minimal is an operation mode that can guarantee that a node will be able to join a network and route its control packets to acquire a better schedule and support a very little traffic (in case of fallback mode in a critical situation).

As regards to 2) I think that spacing cells instead of having them contiguos at the beginning of the slotframe will improve synchronization of nodes as synchronization windows will be moved from once every 1.5 seconds to once every 300ms aprox.

what others think?
X

I like that approach.
    the few bytes.
    best to keep that

---

From: Xavier Vilajosana <[email-masked]>
Date: Wed, 7 May 2014 08:38:50 +0200

Hi Qin, the information is pre-configured at each node. In addition, nodes
may (draft says recommends) decide to advertise these slots in their EB
using Frame and Link IE.

regards,
Xavi

2014-05-07 8:31 GMT+02:00 Qin Wang <[email-masked]>:

> Hi Xavi,
>
> I want to confirm with you: for a new node, the slotframe information
> (e.g. size of slotframe, location of active slot) will come from Enhanced
> Beacon, or be configured in the new node before joining?
>
> Thanks
> Qin

---

From: Qin Wang <[email-masked]>
Date: Wed, 7 May 2014 00:07:19 -0700 (PDT)

Hi Xavi,

Let's detail the way in which a node get slotframe information.

(1) Each node, no matter existing in network or being joining, gets slotframe information from pre-configuration. In this case, the slotframe information can only be one, and must clearly defined in the draft.

(2) New node get the slotframe information from received EB. In this case, only root node gets slotframe information from pre-configuration, and thus, the slotframe information can be different depending on network requirement.  

I prefer to (2). In addition, to cover (1), we can define a slotframe information setting as default value in the draft.

What do you think?

Thanks
Qin

On Wednesday, May 7, 2014 2:38 PM, Xavier Vilajosana <[email-masked]> wrote:
 
Hi Qin, the information is pre-configured at each node. In addition, nodes may (draft says recommends) decide to advertise these slots in their EB using Frame and Link IE.

regards,
Xavi

Hi Xavi,
    the few bytes.
    best to keep that

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 7 May 2014 08:23:23 +0000

Hi Kris:

We have high hopes for minimal, the ultimate goal being that in any deployment we could have a minimal instance that would allow to bring up and configure in any situation, including breakage / recovery e.g. from a misconfig on another instance. Any is certainly very abstract, but then what would the span of sensible deployments be?

A sensible deployment will have some good security in. During the security discussions, concerns were raised about the collisions when multiple nodes join, and the latency that could be become an issue for the AAA flows. Maybe we can address that by spreading the boot process in a trickle fashion, or changing the timing of the security flows and that could be fine if the problem is not limited to minimal configuration. But then, the use of slotted aloha for minimal certainly contributes to the jam.

We have in mind potentially large and dense deployments with multiple 6TiSCH meshes potentially interfering. We also have in mind that the meshes participating to a same subnet will be synchronized so as to allow lazy mobility and RPL local recovery. My question is really can we spread the slots used by minimal so that the meshes do not interfere with one another at least at boot time while keeping it simple?

Cheers,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Kris Pister
Sent: mardi 6 mai 2014 22:59
To: [email-masked]
Subject: Re: [6tisch] More control of the minimal schedule

Pascal - I agree with Xavi.  I like the idea, but it is not "minimal".  Minimal should really be
minimal.  There are many useful and obvious improvements that can be added to minimal...
but then it's not minimal.

ksjp

X

2014-05-06 15:55 GMT+02:00 Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>:
Hello Xavi

Cheers,

Pascal

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

6tisch mailing list

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 7 May 2014 08:26:44 +0000

Hi Qin:

If the networks are unrelated, you are certainly correct. But the multilink subnet case has all the DAGs synchronized. In that case, each DAG could play minimal with some shift to as to avoid interfering with the others. It is unclear to me whether that can be done in a simple enough manner though.

Cheers,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Qin Wang
Sent: mercredi 7 mai 2014 09:07
To: Xavier Vilajosana
Cc: Kris Pister; [email-masked]
Subject: Re: [6tisch] More control of the minimal schedule

Hi Xavi,

What do you think?

Thanks
Qin

On Wednesday, May 7, 2014 2:38 PM, Xavier Vilajosana <[email-masked]<mailto:[email-masked]>> wrote:
Hi Qin, the information is pre-configured at each node. In addition, nodes may (draft says recommends) decide to advertise these slots in their EB using Frame and Link IE.

regards,
Xavi

2014-05-07 8:31 GMT+02:00 Qin Wang <[email-masked]<mailto:[email-masked]>>:
Hi Xavi,

Thanks
Qin
On Wednesday, May 7, 2014 11:34 AM, Xavier Vilajosana <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

what others think?
X

2014-05-07 1:38 GMT+02:00 Kris Pister <[email-masked]<mailto:[email-masked]>>:
I like that approach.

The debate will of course be about the meaning of the parameters in the few bytes.
I believe that will be a fruitful debate, and I do think that it's best to keep that
separate from minimal.

ksjp

Having two mechanisms permits the best of both worlds at relatively low cost: 1) a minimal schedule that uses very few resources, and 2) a concisely-parametrized means of activating an extended default schedule for those situations where many nodes are starting concurrently (e.g., after somebody stops the jammers, or after the tornado with its flying metal objects has passed), which would facilitate more-rapid network rebuild/recovery than is possible with just the minimal default schedule.

-Tom
====

ksjp

X

Cheers,

Pascal

6tisch mailing list

6tisch mailing list

6tisch mailing list

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 7 May 2014 08:51:25 +0000

I agree with Qin that there is a tension here.

The very minimal world where everything is hardcoded does not require descriptors in the EB apart from “this is running the very minimal well known config”.
This would be great for adhoc / unmanaged deployments, and I’d love to have devices at home operate like that.

Then there is the more than minimal that takes info from the EB that is spread out from the root. This network is managed, even if the only thing that is entered is a rough idea of the size and shape of the network.

I agree with Kris that this already a very different ball game. In many incarnations, a type of device would only be expected to operate as either managed or fully autonomic. This touches not only the slot-frames but also the security. If the network is autonomic, what kind of security and config override are we expecting?

And I also agree with Tom that we’d want the best of both worlds, but maybe not necessarily in the same device.

A remark would be that a lot of the minimal work is related to RPL operations over a slotted aloha network which really does not depend on which time slots are used down there.

I’m coming to the conclusion that we are talking profiles. This may lead to a new organization of the draft, or a spinoff draft.
Can you all attend the call Friday? I’d wish to spend enough time on this discussion which is at the core of a chartered item.

Cheers,

Pascal

Hi Xavi,

What do you think?

Thanks
Qin

regards,
Xavi

Thanks
Qin

what others think?
X

ksjp

-Tom
====

ksjp

X

Cheers,

Pascal

6tisch mailing list

6tisch mailing list

6tisch mailing list