Subject: [6tisch] Review of <draft-ietf-6tisch-minimal-00.txt>

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 20 May 2014 13:32:12 +0000

Dear all:

There will be a need for a refresher soon; I was wondering what needs to be added/updated to the draft 

1) As a result of the last biweekly call, people at eth call leaned towards keeping minimal, well, minimal.
Meaning that if there is a need for configuration (such as the size of the slotframe, which cells are used etc...) then that should be an additional work, not part of minimal. Which as it goes would mean that minimal does not need any config and is all hardcoded. Do we all agree on that?

2) Then what's the minimum information that needs to be passed in IE to mean that a given instance is compatible with minimal? I'd think that the parent should indicate that it is compatible with minimal and that the child should indicate that it can only do minimal vs. get some more slots later e.g. using OTF.

3) typos
   7.  RPL on TSCH
     Nodes in the network MUST use the RPL routing protocol << please indicate RFC 6550
  7.1.  RPL Objective Function Zero
     Nodes in the network MUST use the RPL routing protocol [RFC6550]. <<< missing Objective Function zero [RFC6552]

4) section 7.1.2. provides an example. Is that really an example? 
If so, what can the implementer vary? If any implementation of OF0 works that's fine but please indicate so.
Or else is it RECOMMENDED to do it that way? 
My suggestion is to indicate that any OF0 implementation will do.

5) Constants and variables should be used by names in the text and then a summary of (default) values should be given at the end of the document; e.g. TsLongGT is properly used in the text but there should be a RECOMMENDED indication of the value if it is a constant or a default value if it is a variable. 
In the following text:
  "The decision for a node to select one Time Source Neighbour when multiple EBs are received is open to implementers, for example a node MAY wait until one EB from 2 neighbors have been received to select the best Time Source Neighbour.  This condition MAY apply unless a second EB is not received after 180s." the variables that are proposed to 2 and 180 should be given names and the defaults could be proposed to the values above in the section at the end. Same goes for PARENT_SWITCH_THRESHOLD which value should be RECOMMENDED to 394 if ETX is used.

6) RPL information
Considering eth positive reception from Brian at 6MAN we can probably indicate that the RPL information SHOULD be transported in the flow label in the LLN and refer to draft-thubert-6man-flow-label-for-rpl-02

6) Section 7.2.2 trickle

I think we should provide more indication considering that the network time is well known. If we shoot for 3 parents, then redundancy constant, k, would be set to 4 or 5, what do you think? 

The minimum interval size, Imin, cannot be less than a schedule period, so the default in RFC 5206 (100ms) makes no sense. I'd suggest 1.5 seconds or a multiple of that. The maximum interval size, Imax, can be very large if the network is stable. Using the recommendation in 6206 (65536*Imin) we'd end up with roughly 100000 seconds, a bit more than a day. Again what do you all think?

7) triggering DIOs and DAOs.	
There also we should make some recommendations to avoid collisions when many children hear a same new parent, e.g. exponential backoff and indication of path lifetime in transit option accordingly. Any idea there?

Nits:

1) the references to docs that are now WG docs should be migrated to draft-ietf.

2) Missing RFC 2119 text. Please add the following right after the abstract:
   <note title="Requirements Language">
      <t>
         The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
         "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
         and "OPTIONAL" in this document are to be interpreted as described
         in <xref target="RFC2119">RFC 2119</xref>.
      </t>
   </note>

Cheers,

Pascal

-----Original Message-----
From: IETF Secretariat [mailto:[email-masked]] 
Sent: lundi 19 mai 2014 13:42
To: Xavier Vilajosana; Kris Pister
Cc: Pascal Thubert (pthubert); Thomas Watteyne
Subject: Expiration impending: <draft-ietf-6tisch-minimal-00.txt>

The following draft will expire soon:

Name:     draft-ietf-6tisch-minimal
Title:    Minimal 6TiSCH Configuration
State:    I-D Exists
Expires:  2014-05-23 (in 3 days, 19 hours)

---

From: Kris Pister <[email-masked]>
Date: Tue, 20 May 2014 16:43:08 -0700

Pascal - I'd say this slightly differently, with the same outcome I believe.

> 2) Then what's the minimum information that needs to be passed in IE to mean that a given instance is compatible with minimal? I'd think that the parent should indicate that it is compatible with m…
I'd prefer that when we have settled on a final minimal configuration
  (frame size, cell type and allocation, slot parameters),
that all of these parameters be advertised in beacons using the normal 
IEs defined in 4e.
Implementers MUST be able to handle those specific parameters, and if 
they chose to
hard code them that's fine.
If they don't choose to hard code them, and make a more flexible 
implementation, that's
fine too.

Does that make sense?
ksjp

---

From: Xavier Vilajosana <[email-masked]>
Date: Wed, 21 May 2014 05:38:17 +0200

Hi Kris,Pascal,

so you suggest that:

1) minimal draft specifies that EBs MUST contain the slotframe and link IE
indicating the minimum set of cells to be used. (already specified)
2)Nodes MAY decide to hard-code or pre-configure that information or either
learn it from an EB from a parent. (now is a MUST but should change to MAY)

I derive from here that the DAGROOT MAY learn it somehow or have it
pre-configured. right?
X

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

>> Meaning that if there is a need for configuration (such as the size of
>> the slotframe, which cells are used etc...) then that should be an
>> additional work, not part of minimal. Which as it goes would mean that
>> minimal does not need any config and is all hardcoded. Do we all agree on
>> that?
>>
>> 2) Then what's the minimum information that needs to be passed in IE to
>> mean that a given instance is compatible with minimal? I'd think that the
>> parent should indicate that it is compatible with minimal and that the
>> child should indicate that it can only do minimal vs. get some more slots
>> later e.g. using OTF.
>>
> that all of these parameters be advertised in beacons using the normal IEs
> defined in 4e.
> Implementers MUST be able to handle those specific parameters, and if they
> chose to
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>

---

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

Hi Xavi and Kris:

All this makes sense.

My point is that are seeing the potential benefits of an extension to a more malleable schedule than just minimal; and I think we could make it so that it coexists with the minimal schedule as a superset of features in a second draft.

In that model, a device with just minimal support participates as expected, reads DIOs in the mcast timeSlots and send/receives in the other timeSlots; but a device with the manageable capabilities could benefit from more stuff, e.g. additional slots and new behaviors in those additional slots.

I note that:

- advertising a well-known schedule still consumes battery and room in the frame. As we add more stuff in EBs this room might become precious.
- there is probably also a need for control / capability bits, e.g. to signal that all slots are available for slotted aloha operations for the next period of time.
- If we signal the support for the hardcoded minimal schedule with a simple control bit, then the schedule information in the IE can be used for a more advanced schedule that extends the minimal and allows for devices that just do the minimal.

If there isn’t a more advanced schedule then the beacon may carry the minimal schedule and that would match Kris’ proposal. The benefits are simplicity and compatibility with the standards. OTOH, I have trouble believing that a node that is not designed to do minimal can participate in a minimal network.

Cheers,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: mercredi 21 mai 2014 05:38
To: Kris Pister
Cc: [email-masked]
Subject: Re: [6tisch] Review of <draft-ietf-6tisch-minimal-00.txt>

Hi Kris,Pascal,

so you suggest that:

1) minimal draft specifies that EBs MUST contain the slotframe and link IE indicating the minimum set of cells to be used. (already specified)
2)Nodes MAY decide to hard-code or pre-configure that information or either learn it from an EB from a parent. (now is a MUST but should change to MAY)

I derive from here that the DAGROOT MAY learn it somehow or have it pre-configured. right?
X

2014-05-21 1:43 GMT+02:00 Kris Pister <[email-masked]<mailto:[email-masked]>>:
Pascal - I'd say this slightly differently, with the same outcome I believe.

2) Then what's the minimum information that needs to be passed in IE to mean that a given instance is compatible with minimal? I'd think that the parent should indicate that it is compatible with minimal and that the child should indicate that it can only do minimal vs. get some more slots later e.g. using OTF.
I'd prefer that when we have settled on a final minimal configuration
 (frame size, cell type and allocation, slot parameters),
that all of these parameters be advertised in beacons using the normal IEs defined in 4e.
Implementers MUST be able to handle those specific parameters, and if they chose to
hard code them that's fine.
If they don't choose to hard code them, and make a more flexible implementation, that's
fine too.

Does that make sense?
ksjp

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 21 May 2014 08:30:47 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > My point is that are seeing the potential benefits of an extension to a
    > more
    > malleable schedule than just minimal; and I think we could make it so
    > that it
    > coexists with the minimal schedule as a superset of features in a
    > second draft.

The other reason that things should be aable to co-exist is to avoid flag
days.  Some devices get updated and/or replaced, and new capabilities are
available in that part of the network.

    > compatibility with the standards. OTOH, I have trouble believing that a
    > node
    > that is not designed to do minimal can participate in a minimal network.

I can imagine a node that is much more capable, but could be programmed with
a schedule that matches minimal.  But, I can't imagine that an implmenter
wouldn't just do that automtically, right?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Kris Pister <[email-masked]>
Date: Wed, 21 May 2014 12:05:40 -0700

On 5/21/2014 1:24 AM, Pascal Thubert (pthubert) wrote:
>
> Hi Xavi and Kris:
>
> All this makes sense.
>
> My point is that are seeing the potential benefits of an extension to 
> a more malleable schedule than just minimal; and I think we could make 
> it so that it coexists with the minimal schedule as a superset of 
> features in a second draft.
>
> In that model, a device with just minimal support participates as 
> expected, reads DIOs in the mcast timeSlots and send/receives in the 
> other timeSlots; but a device with the manageable capabilities could 
> benefit from more stuff, e.g. additional slots and new behaviors in 
> those additional slots.
>
I agree.
>
> I note that:
>
> - advertising a well-known schedule still consumes battery and room in 
> the frame. As we add more stuff in EBs this room might become precious.
>
I agree that being 15.4e compliant will cost some power, and that it 
takes up space in EBs.
>
> - there is probably also a need for control / capability bits, e.g. to 
> signal that all slots are available for slotted aloha operations for 
> the next period of time.
>
I'm not sure that I understand.  You're recommending a bit that says 
"ignore the cell schedule, use all
slots (on some offset?) for time T as aloha"?  Interesting idea.
>
> - If we signal the support for the hardcoded minimal schedule with a 
> simple control bit, then the schedule information in the IE can be 
> used for a more advanced schedule that extends the minimal and allows 
> for devices that just do the minimal.
>
I agree that we want IEs to be used for more advanced scheduling that 
extends minimal and still
allows for devices that just do minimal.  I don't think that we want 
that information in the EBs that
are used to build the minimal network though.  The regular advertisement 
of network information
with EBs allows for basic network formation.  Then fancy networks will 
add optimized schedules,
and quite likely delete the minimal schedule in some cases.
I expect that network schedules will evolve in time to meet QoS 
requirements in the face of time-varying
connectivity.
I also expect that our approach to standardizing networks schedules will 
evolve.  I don't
expect people to be using minimal in ten years, but I also don't want to 
try to predict what
we'll need in ten years and put it into minimal today.
>
> If there isn’t a more advanced schedule then the beacon may carry the 
> minimal schedule and that would match Kris’ proposal. The benefits are 
> simplicity and compatibility with the standards. OTOH, I have trouble 
> believing that a node that is not designed to do minimal can 
> participate in a minimal network.
>
I don't understand the last sentence.  Are you worried that the hardware 
or software won't be able
to handle the timing, or ...?

ksjp
>
> Cheers,
>
> Pascal
>
> *From:*6tisch [mailto:[email-masked]] *On Behalf Of *Xavier 
> Vilajosana
> *Sent:* mercredi 21 mai 2014 05:38
> *To:* Kris Pister
> *Cc:* [email-masked]
> *Subject:* Re: [6tisch] Review of <draft-ietf-6tisch-minimal-00.txt>
>
> Hi Kris,Pascal,
>
> so you suggest that:
>
> 1) minimal draft specifies that EBs MUST contain the slotframe and 
> link IE indicating the minimum set of cells to be used. (already 
> specified)
>
> 2)Nodes MAY decide to hard-code or pre-configure that information or 
> either learn it from an EB from a parent. (now is a MUST but should 
> change to MAY)
>
> minimal does not need any config and is all hardcoded. Do we all agree 
> on that?
>
> 2) Then what's the minimum information that needs to be passed in IE 
> to mean that a given instance is compatible with minimal? I'd think 
> that the parent should indicate that it is compatible with minimal and 
> that the child should indicate that it can only do minimal vs. get 
> some more slots later e.g. using OTF.
>
> [email-masked] <mailto:[email-masked]>

---

From: Kris Pister <[email-masked]>
Date: Wed, 21 May 2014 12:10:11 -0700

> wouldn't just do that automtically, right?
Assuming that we are successful and 6tisch generates some commercial 
traction, IC vendors will
add hardware support for 15.4e slot templates, cell schedules, etc. So 
taking information
from an EB and using that to set up a schedule will become much easier.
Or am I missing the point?

ksjp

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 22 May 2014 08:08:28 +0000

Hi Kris

- If we signal the support for the hardcoded minimal schedule with a simple control bit, then the schedule information in the IE can be used for a more advanced schedule that extends the minimal and allows for devices that just do the minimal.
I agree that we want IEs to be used for more advanced scheduling that extends minimal and still
allows for devices that just do minimal.  I don't think that we want that information in the EBs that
are used to build the minimal network though.  The regular advertisement of network information
with EBs allows for basic network formation.  Then fancy networks will add optimized schedules,
and quite likely delete the minimal schedule in some cases.

I’m concerned that we might not have the same idea about the future of minimal:

- If we design it for short term / close network operations, then we better make the draft experimental and learn from it.

- If we are shooting for production deployments, some devices may be here to stay for (tens of) years while the deployment is extended over time.  We want to be able to bring in new devices though we cannot fathom what they will be. And yet we want the minimal schedule to still operate in the minimal fashion.

My question is do we want a minimal device to survive within a more advanced schedule, meaning that the minimal device may not be able to even understand some of the information about the layout and parameters that come with it? If that’s so, we need to make the minimal information controllable and extensible, without any preconception of what the extensions will be. A control bit can say, if you’re minimal, this schedule still works for you, just use the hardcoded timeslots in a slotted aloha fashion, don’t worry about all the extra.

There is a hope that we have an always-available fallback. There is hope that minimal is that fallback. Is that overshooting?

I expect that network schedules will evolve in time to meet QoS requirements in the face of time-varying
connectivity.
I also expect that our approach to standardizing networks schedules will evolve.  I don't
expect people to be using minimal in ten years, but I also don't want to try to predict what
we'll need in ten years and put it into minimal today.

Agreed but for the use of minimal. People may use devices for a long while they keep buying new and more capable ones.

Cheers,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Kris Pister
Sent: mercredi 21 mai 2014 21:06
To: Pascal Thubert (pthubert); Xavier Vilajosana
Cc: [email-masked]
Subject: Re: [6tisch] Review of <draft-ietf-6tisch-minimal-00.txt>

Hi Xavi and Kris:

All this makes sense.

I note that:

- advertising a well-known schedule still consumes battery and room in the frame. As we add more stuff in EBs this room might become precious.
I agree that being 15.4e compliant will cost some power, and that it takes up space in EBs.

- there is probably also a need for control / capability bits, e.g. to signal that all slots are available for slotted aloha operations for the next period of time.
I'm not sure that I understand.  You're recommending a bit that says "ignore the cell schedule, use all
slots (on some offset?) for time T as aloha"?  Interesting idea.

- If we signal the support for the hardcoded minimal schedule with a simple control bit, then the schedule information in the IE can be used for a more advanced schedule that extends the minimal and allows for devices that just do the minimal.
I agree that we want IEs to be used for more advanced scheduling that extends minimal and still
allows for devices that just do minimal.  I don't think that we want that information in the EBs that
are used to build the minimal network though.  The regular advertisement of network information
with EBs allows for basic network formation.  Then fancy networks will add optimized schedules,
and quite likely delete the minimal schedule in some cases.
I expect that network schedules will evolve in time to meet QoS requirements in the face of time-varying
connectivity.
I also expect that our approach to standardizing networks schedules will evolve.  I don't
expect people to be using minimal in ten years, but I also don't want to try to predict what
we'll need in ten years and put it into minimal today.

If there isn’t a more advanced schedule then the beacon may carry the minimal schedule and that would match Kris’ proposal. The benefits are simplicity and compatibility with the standards. OTOH, I have trouble believing that a node that is not designed to do minimal can participate in a minimal network.
I don't understand the last sentence.  Are you worried that the hardware or software won't be able
to handle the timing, or ...?

ksjp

Cheers,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: mercredi 21 mai 2014 05:38
To: Kris Pister
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] Review of <draft-ietf-6tisch-minimal-00.txt>

Hi Kris,Pascal,

so you suggest that:

Does that make sense?
ksjp

---

From: Kris Pister <[email-masked]>
Date: Thu, 22 May 2014 11:14:28 -0700

> If we are shooting for production deployments, some devices may be 
here to stay for (tens of)
 > years while the deployment is extended over time.  We want to be able 
to bring in new devices
 > though we cannot fathom what they will be. And yet we want the 
minimal schedule to still
 > operate in the minimal fashion.

I agree.  That is what we want to do.

 > My question is do we want a minimal device to survive within a more 
advanced schedule,

Yes.

 > meaning that the minimal device may not be able to even understand 
some of the information
 > about the layout and parameters that come with it? If that’s so, we 
need to make the minimal
 > information controllable and extensible, without any preconception of 
what the extensions will
 > be. A control bit can say, if you’re minimal, this schedule still 
works for you, just use the
 > hardcoded timeslots in a slotted aloha fashion, don’t worry about all 
the extra.

  I disagree.  The tools exist to make controllable and extensible 
schedules (or they will exist
once our work here is done).  We do NOT need to make minimal 
controllable and extensible.
Here's the schedule.  Done.  If you can't handle the fancy traffic that 
shows up later, so be
it.  At least you have your minimal schedule.

 > There is a hope that we have an always-available fallback. There is 
hope that minimal is that
 > fallback. Is that overshooting?

I agree, and I don't think that it is overshooting.

ksjp

On 5/22/2014 1:08 AM, Pascal Thubert (pthubert) wrote:
> - If we design it for short term / close network operations, then we 
> better make the draft experimental and learn from it.
>
> - If we are shooting for production deployments, some devices may be 
> here to stay for (tens of) years while the deployment is extended over 
> time.  We want to be able to bring in new devices though we cannot 
> fathom what they will be. And yet we want the minimal schedule to 
> still operate in the minimal fashion.
>
> My question is do we want a minimal device to survive within a more 
> advanced schedule, meaning that the minimal device may not be able to 
> even understand some of the information about the layout and 
> parameters that come with it? If that’s so, we need to make the 
> minimal information controllable and extensible, without any 
> preconception of what the extensions will be. A control bit can say, 
> if you’re minimal, this schedule still works for you, just use the 
> hardcoded timeslots in a slotted aloha fashion, don’t worry about all 
> the extra.
>
> There is a hope that we have an always-available fallback. There is 
> hope that minimal is that fallback. Is that overshooting?
>
> Agreed but for the use of minimal. People may use devices for a long 
> while they keep buying new and more capable ones.
>
> Cheers,
>
> Pascal
>
> *From:*6tisch [mailto:[email-masked]] *On Behalf Of *Kris Pister
> *Sent:* mercredi 21 mai 2014 21:06
> *To:* Pascal Thubert (pthubert); Xavier Vilajosana
> *Cc:* [email-masked]
> *Cc:* [email-masked] <mailto:[email-masked]>

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Thu, 22 May 2014 14:22:55 -0400

My two cents:

2014-05-22 14:14 GMT-04:00 Kris Pister <[email-masked]>:

>  > If we are shooting for production deployments, some devices may be here
> to stay for (tens of)
> > years while the deployment is extended over time.  We want to be able to
> bring in new devices
> > though we cannot fathom what they will be. And yet we want the minimal
> schedule to still
> > meaning that the minimal device may not be able to even understand some
> of the information
> > about the layout and parameters that come with it? If that’s so, we need
> to make the minimal
> > be. A control bit can say, if you’re minimal, this schedule still works
> for you, just use the
> once our work here is done).  We do NOT need to make minimal controllable
> and extensible.
> > There is a hope that we have an always-available fallback. There is hope
> that minimal is that

In fact, if a node looses sync and has to go on fallback mode, it can
rebuild (or recover) the
schedule by asking the parent node or the PCE.

> ksjp
Diego

> simple control bit, then the schedule information in the IE can be used for
> a more advanced schedule that extends the minimal and allows for devices
> that just do the minimal.
>
> - If we are shooting for production deployments, some devices may be here
> to stay for (tens of) years while the deployment is extended over time.  We
> want to be able to bring in new devices though we cannot fathom what they
> will be. And yet we want the minimal schedule to still operate in the
> minimal fashion.
>
>
>
> advanced schedule, meaning that the minimal device may not be able to even
> understand some of the information about the layout and parameters that
> come with it? If that’s so, we need to make the minimal information
> controllable and extensible, without any preconception of what the
> extensions will be. A control bit can say, if you’re minimal, this schedule
> still works for you, just use the hardcoded timeslots in a slotted aloha
> fashion, don’t worry about all the extra.
>
>
>
> There is a hope that we have an always-available fallback. There is hope
> that minimal is that fallback. Is that overshooting?
>
>
>
>
>
> Agreed but for the use of minimal. People may use devices for a long while
> they keep buying new and more capable ones.
>
>
>
> Cheers,
>
>
>
> Pascal
>
>
>
> *From:* 6tisch [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Kris Pister
> more malleable schedule than just minimal; and I think we could make it so
> that it coexists with the minimal schedule as a superset of features in a
> second draft.
>
>
>
> expected, reads DIOs in the mcast timeSlots and send/receives in the other
> timeSlots; but a device with the manageable capabilities could benefit from
> more stuff, e.g. additional slots and new behaviors in those additional
> slots.
>
> I agree.
>
>
>
> I note that:
>
>
>
> - advertising a well-known schedule still consumes battery and room in the
> frame. As we add more stuff in EBs this room might become precious.
>
> signal that all slots are available for slotted aloha operations for the
> next period of time.
>
> simple control bit, then the schedule information in the IE can be used for
> a more advanced schedule that extends the minimal and allows for devices
> that just do the minimal.
>
> believing that a node that is not designed to do minimal can participate in
> a minimal network.
>
> *From:* 6tisch [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Xavier Vilajosana
> either learn it from an EB from a parent. (now is a MUST but should change
> to MAY)
>
>
>
> Meaning that if there is a need for configuration (such as the size of the
> slotframe, which cells are used etc...) then that should be an additional
> work, not part of minimal. Which as it goes would mean that minimal does
> not need any config and is all hardcoded. Do we all agree on that?
>

-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125

---

From: <[email-masked]>
Date: Fri, 23 May 2014 17:45:58 +0000

Dear All,

I was wondering, if (i) we let the nodes to be scheduled (after network start-up phase) in other channel offsets (other than 0) during the "minimal schedule" timeslots OR (ii) we are keeping those timeslots (after network start-up) for just "minimal schedule" and we do not recommend to schedule any more cells in those timeslots in other channel offsets?

I guess we shouldn't recommend the other cells to be scheduled in those "minimal" timeslots if we intend to support delayed joining devices (with hard coded "minimal schedule") who wants to join after start-up phase,
Because:
The network that supports "minimal schedule" (e.g. first five shared timelosts with channel offset 0) are set to work on channel offset 0 (based on the minimal schedule) and all the nodes, during network start-up phase, listen on channel offset 0 in "minimal" timeslots to receive the data form other neighboring nodes. After network start-up phase, as the nodes schedule fills up (either by the PCE or by a distributed scheduling solution), they spend less time listening on channel offset 0 in the "minimal schedule" timeslot. This means that nodes with more busy schedules have difficulties to participate in those shared "minimal schedule" cells. As a result, a new device (with hard coded "minimal schedule") who wants to join the network (after start-up phase) will not find any neighboring router to meet in the "minimal schedule" cells. Am I right?

I was wondering,
(A) if we can avoid to use other channel offsets (other than 0) during the "minimal schedule" timeslots? And considering a period for just "minimal schedule" in the basic slotframe?
Or
(B) are we assuming a joined devices will at least participate in one of those "minimal schedule" cells and the rest of the cells in the "minimal" timeslots can be scheduled for other purposes?
Or
(C) are we assuming that the during the normal operation of network (after start-up phase), the routing devices will advertise their "joining links" (Tx and Rx links that are scheduled by PCE) and the new devices can use those "joining links" to join the network without participating in "minimal schedule"?

Am I missing anything?

Regards,
Pouria

On 22 May 2014, at 20:23, "Prof. Diego Dujovne" <[email-masked]<mailto:[email-masked]>> wrote:

My two cents:

2014-05-22 14:14 GMT-04:00 Kris Pister <[email-masked]<mailto:[email-masked]>>:
> If we are shooting for production deployments, some devices may be here to stay for (tens of)
> years while the deployment is extended over time.  We want to be able to bring in new devices
> though we cannot fathom what they will be. And yet we want the minimal schedule to still

> My question is do we want a minimal device to survive within a more advanced schedule,

Yes.

> meaning that the minimal device may not be able to even understand some of the information
> about the layout and parameters that come with it? If that’s so, we need to make the minimal
> information controllable and extensible, without any preconception of what the extensions will
> be. A control bit can say, if you’re minimal, this schedule still works for you, just use the
> hardcoded timeslots in a slotted aloha fashion, don’t worry about all the extra.

 I disagree.  The tools exist to make controllable and extensible schedules (or they will exist
once our work here is done).  We do NOT need to make minimal controllable and extensible.
Here's the schedule.  Done.  If you can't handle the fancy traffic that shows up later, so be
it.  At least you have your minimal schedule.

In fact, if a node looses sync and has to go on fallback mode, it can rebuild (or recover) the
schedule by asking the parent node or the PCE.

ksjp

Diego

Cheers,

Pascal

Hi Xavi and Kris:

All this makes sense.

I note that:

ksjp

Cheers,

Pascal

Hi Kris,Pascal,

so you suggest that:

Does that make sense?
ksjp

www.ingenieria.udp.cl<http://www.ingenieria.udp.cl>

---

From: Kris Pister <[email-masked]>
Date: Sat, 24 May 2014 15:41:47 -0700

Pouria -
  My vote is for (B).

ksjp

On 5/23/2014 10:45 AM, [email-masked] wrote:
> Dear All,
>
> I was wondering, if (i) we let the nodes to be scheduled (after 
> network start-up phase) in other channel offsets (other than 0) during 
> the "minimal schedule" timeslots OR (ii) we are keeping those 
> timeslots (after network start-up) for just "minimal schedule" and we 
> do not recommend to schedule any more cells in those timeslots in 
> other channel offsets?
>
> I guess we shouldn't recommend the other cells to be scheduled in 
> those "minimal" timeslots if we intend to support delayed joining 
> devices (with hard coded "minimal schedule") who wants to join after 
> start-up phase,
> Because:
> The network that supports "minimal schedule" (e.g. first five shared 
> timelosts with channel offset 0) are set to work on channel offset 0 
> (based on the minimal schedule) and all the nodes, during network 
> start-up phase, listen on channel offset 0 in "minimal" timeslots to 
> receive the data form other neighboring nodes. After network start-up 
> phase, as the nodes schedule fills up (either by the PCE or by a 
> distributed scheduling solution), they spend less time listening on 
> channel offset 0 in the "minimal schedule" timeslot. This means that 
> nodes with more busy schedules have difficulties to participate in 
> those shared "minimal schedule" cells. As a result, a new device (with 
> hard coded "minimal schedule") who wants to join the network (after 
> start-up phase) will not find any neighboring router to meet in the 
> "minimal schedule" cells. Am I right?
>
> I was wondering,
> (A) if we can avoid to use other channel offsets (other than 0) during 
> the "minimal schedule" timeslots? And considering a period for just 
> "minimal schedule" in the basic slotframe?
> Or
> (B) are we assuming a joined devices will at least participate in one 
> of those "minimal schedule" cells and the rest of the cells in the 
> "minimal" timeslots can be scheduled for other purposes?
> Or
> (C) are we assuming that the during the normal operation of network 
> (after start-up phase), the routing devices will advertise their 
> "joining links" (Tx and Rx links that are scheduled by PCE) and the 
> new devices can use those "joining links" to join the network without 
> participating in "minimal schedule"?
>
> Am I missing anything?
>
> Regards,
> Pouria
>
> On 22 May 2014, at 20:23, "Prof. Diego Dujovne" 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>> My two cents:
>>
>>
>>     > information controllable and extensible, without any
>>     preconception of what the extensions will
>>     > There is a hope that we have an always-available fallback.
>>     There is hope that minimal is that
>>>     - If we signal the support for the hardcoded minimal schedule
>>>     with a simple control bit, then the schedule information in the
>>>     IE can be used for a more advanced schedule that extends the
>>>     minimal and allows for devices that just do the minimal.
>>>
>>>     - If we design it for short term / close network operations,
>>>     then we better make the draft experimental and learn from it.
>>>
>>>     - If we are shooting for production deployments, some devices
>>>     may be here to stay for (tens of) years while the deployment is
>>>     extended over time.  We want to be able to bring in new devices
>>>     minimal schedule to still operate in the minimal fashion.
>>>
>>>     My question is do we want a minimal device to survive within a
>>>     more advanced schedule, meaning that the minimal device may not
>>>     be able to even understand some of the information about the
>>>     layout and parameters that come with it? If that’s so, we need
>>>     to make the minimal information controllable and extensible,
>>>     without any preconception of what the extensions will be. A
>>>     control bit can say, if you’re minimal, this schedule still
>>>     works for you, just use the hardcoded timeslots in a slotted
>>>     aloha fashion, don’t worry about all the extra.
>>>
>>>     There is a hope that we have an always-available fallback. There
>>>     is hope that minimal is that fallback. Is that overshooting?
>>>
>>>     Agreed but for the use of minimal. People may use devices for a
>>>     long while they keep buying new and more capable ones.
>>>
>>>     Cheers,
>>>
>>>     Pascal
>>>
>>>     My point is that are seeing the potential benefits of an
>>>     extension to a more malleable schedule than just minimal; and I
>>>     think we could make it so that it coexists with the minimal
>>>     schedule as a superset of features in a second draft.
>>>
>>>     In that model, a device with just minimal support participates
>>>     as expected, reads DIOs in the mcast timeSlots and send/receives
>>>     in the other timeSlots; but a device with the manageable
>>>     capabilities could benefit from more stuff, e.g. additional
>>>     slots and new behaviors in those additional slots.
>>>
>>>     I agree.
>>>
>>>     I note that:
>>>
>>>     - advertising a well-known schedule still consumes battery and
>>>     room in the frame. As we add more stuff in EBs this room might
>>>     become precious.
>>>
>>>     - there is probably also a need for control / capability bits,
>>>     e.g. to signal that all slots are available for slotted aloha
>>>     operations for the next period of time.
>>>
>>>     - If we signal the support for the hardcoded minimal schedule
>>>     with a simple control bit, then the schedule information in the
>>>     IE can be used for a more advanced schedule that extends the
>>>     minimal and allows for devices that just do the minimal.
>>>
>>>     If there isn’t a more advanced schedule then the beacon may
>>>     carry the minimal schedule and that would match Kris’ proposal.
>>>     The benefits are simplicity and compatibility with the
>>>     standards. OTOH, I have trouble believing that a node that is
>>>     not designed to do minimal can participate in a minimal network.
>>>
>>>     *From:*6tisch [mailto:[email-masked]] *On Behalf Of
>>>     *Xavier Vilajosana
>>>     1) minimal draft specifies that EBs MUST contain the slotframe
>>>     and link IE indicating the minimum set of cells to be used.
>>>     (already specified)
>>>
>>>     2)Nodes MAY decide to hard-code or pre-configure that
>>>     information or either learn it from an EB from a parent. (now is
>>>     a MUST but should change to MAY)
>>>
>>>     1) As a result of the last biweekly call, people at eth call
>>>     leaned towards keeping minimal, well, minimal.
>>>     Meaning that if there is a need for configuration (such as the
>>>     size of the slotframe, which cells are used etc...) then that
>>>     should be an additional work, not part of minimal. Which as it
>>>     goes would mean that minimal does not need any config and is all
>>>     hardcoded. Do we all agree on that?
>>>
>>>     2) Then what's the minimum information that needs to be passed
>>>     in IE to mean that a given instance is compatible with minimal?
>>>     I'd think that the parent should indicate that it is compatible
>>>     with minimal and that the child should indicate that it can only
>>>     do minimal vs. get some more slots later e.g. using OTF.
>>>
>> www.ingenieria.udp.cl <http://www.ingenieria.udp.cl>
>> (56 2) 676 8125

---

From: Xavier Vilajosana <[email-masked]>
Date: Mon, 26 May 2014 05:19:20 +0200

B seems to me the right approach.

regards,
Xavi

2014-05-25 0:41 GMT+02:00 Kris Pister <[email-masked]>:

>  I was wondering, if (i) we let the nodes to be scheduled (after network
> start-up phase) in other channel offsets (other than 0) during the "minimal
> schedule" timeslots OR (ii) we are keeping those timeslots (after network
> start-up) for just "minimal schedule" and we do not recommend to schedule
> any more cells in those timeslots in other channel offsets?
>
>  I guess we shouldn't recommend the other cells to be scheduled in those
> "minimal" timeslots if we intend to support delayed joining devices (with
> hard coded "minimal schedule") who wants to join after start-up phase,
> Because:
> timelosts with channel offset 0) are set to work on channel offset 0 (based
> on the minimal schedule) and all the nodes, during network start-up phase,
> listen on channel offset 0 in "minimal" timeslots to receive the data form
> other neighboring nodes. After network start-up phase, as the nodes
> schedule fills up (either by the PCE or by a distributed scheduling
> solution), they spend less time listening on channel offset 0 in the
> "minimal schedule" timeslot. This means that nodes with more busy schedules
> have difficulties to participate in those shared "minimal schedule" cells.
> As a result, a new device (with hard coded "minimal schedule") who wants to
> join the network (after start-up phase) will not find any neighboring
> router to meet in the "minimal schedule" cells. Am I right?
>
>  I was wondering,
> (A) if we can avoid to use other channel offsets (other than 0) during the
> "minimal schedule" timeslots? And considering a period for just "minimal
> schedule" in the basic slotframe?
> Or
> (B) are we assuming a joined devices will at least participate in one of
> those "minimal schedule" cells and the rest of the cells in the "minimal"
> timeslots can be scheduled for other purposes?
> Or
> (C) are we assuming that the during the normal operation of network (after
> start-up phase), the routing devices will advertise their "joining links"
> (Tx and Rx links that are scheduled by PCE) and the new devices can use
> those "joining links" to join the network without participating in "minimal
> schedule"?
>
>  Am I missing anything?
>
>  Regards,
> Pouria
>
> On 22 May 2014, at 20:23, "Prof. Diego Dujovne" <[email-masked]>
> wrote:
>
>   My two cents:
>
>
>> *From:* 6tisch [mailto:[email-masked] <[email-masked]>]
>> *On Behalf Of *Kris Pister
>> *From:* 6tisch [mailto:[email-masked] <[email-masked]>]
>> *On Behalf Of *Xavier Vilajosana
>> 1) minimal draft specifies that EBs MUST contain the slotframe and link
>> IE indicating the minimum set of cells to be used. (already specified)
>>