Subject: [6tisch] Control bits in EB

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

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

Yes, Kris. I’m concerned that there are some short periods in the life of the network (typically a new iteration of the DODAG) where we’d wish to place the network in some (simpe) turbo mode. If there is a logic in the attibution of the offsets of the minimal slots (just like we foresee for chunks) and that same logic can be extended to all slots in turbo mode, then when the EB says so we could boost the network for a short period of time.

I’m giving that as an example of the value of control bits. My point is that minimal is a base for the next and we’d wish the foreseeable next to be supersets so that a minimal implementation can still survice in a network that has evolved. Reserved control bits could be a way to enable that evolution. It’s up to us what we decide as the bare minimum.

Considering the discussions on the join process, I see that many devices joining at the same time will cause a certain amount of collisions and backoff. I’m unsure what the limits will be with the timeout values of a number of protocols, but settings things right may become difficult. A turbo mode would push that frontier quite a bit.

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>

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]<mailto:[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.

On 5/20/2014 6:32 AM, Pascal Thubert (pthubert) wrote:
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.
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: Kris Pister <[email-masked]>
Date: Thu, 22 May 2014 11:09:06 -0700

Xavi - I believe that what you propose below could be done with the 
existing EB mechanisms
defined in 4e for under 10 bytes.
I acknowledge that 10 bytes is much less efficient than 1 bit, but it 
does have the benefit of
being compliant with the standard, and not locking us in to something 
that seems like a good
idea today, but might not be exactly the right answer tomorrow.

ksjp

On 5/22/2014 12:29 AM, Pascal Thubert (pthubert) wrote:
>
> - 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.
>
> Yes, Kris. I’m concerned that there are some short periods in the life 
> of the network (typically a new iteration of the DODAG) where we’d 
> wish to place the network in some (simpe) turbo mode. If there is a 
> logic in the attibution of the offsets of the minimal slots (just like 
> we foresee for chunks) and that same logic can be extended to all 
> slots in turbo mode, then when the EB says so we could boost the 
> network for a short period of time.
>
> I’m giving that as an example of the value of control bits. My point 
> is that minimal is a base for the next and we’d wish the foreseeable 
> next to be supersets so that a minimal implementation can still 
> survice in a network that has evolved. Reserved control bits could be 
> a way to enable that evolution. It’s up to us what we decide as the 
> bare minimum.
>
> Considering the discussions on the join process, I see that many 
> devices joining at the same time will cause a certain amount of 
> collisions and backoff. I’m unsure what the limits will be with the 
> timeout values of a number of protocols, but settings things right may 
> become difficult. A turbo mode would push that frontier quite a bit.
>
> 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>
>
> 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
> *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:
>
> 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)
>
> 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.
>
> [email-masked] <mailto:[email-masked]>