Subject: [6tsch] Dynamic slot activation (was part of the 4th control flow)

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 29 Aug 2013 09:16:07 +0000

Hello Xavi and Qin:

I'm not sure we want  to continue this discussion now or keep it for later, but either way I'm making it a separate thread to save the current conclusions.

In short, Thomas below asked:

Thomas> over what cells with the reports travel? Another questions could be: over what cells will the request to install cells travel?

This is a good question and at the same time this is not really something that we have to answer right now, per our proposed charter, as Xavi indicates:
Xavi> I think it is better first to concentrate on the basic things

On the side I think the use of the word 'basic' these days could create confusion since it seems to refer to draft-vilajosana-6tsch-basic which is probably not Xavi's intention here.
I'd suggest that when we refer to the operation in the draft-vilajosana-6tsch-basic draft, we call it something like "Basic 6TiSCH" or "Basic 6TiSCH Support" so the use of the plain word "basic" may not be confusing anymore.

For this particular thread, I suggested as an answer to Thomas that 1) I agree that in the future the control flows could travel over a Basic 6TiSCH instance, and in that case 2) that we could probably handle burstiness of control traffic by overprovisioning time slots and then indicating dynamically which extra time slots are being used; as Qin puts it very clearly:
Qin> Over-provision can increase the throughput at peak time, while the control bits can reduce the energy consumption for idle-listening (at least at the beginning of slot) in those unused Tx/Rx cells.
I was thinking of something like a 'more' bit in a cell the is being used in order to tell listeners to wake up in the next overprovisionned cell, as opposed to a bit sent at the beginning of the overprovisionned cell that would indicate that the cell is not being used, though. Xavi agrees that it Xavi> sounds to me a great idea

To make sure that we do not make a confusion between 1) the bits that control the use of overprovisionned cells in a bundle and that are pigy backed with the traffic to indicate there is more trafficoutstanding and 2) the end to end protocol that controls the allocation of cells between a controlling entity and the device, or between devices, JP insisted that the control flows for the latter (which are the subject of the original thread by Qin) should be cleanly defined and that we should not expect to piggy back them with traffic:
JP> I would just be vary cautious when thinking of piggybacking control information in packet header for control plane purpose

With this summary, it is up to us to continue the discussion or save it for later. Should we continue, I suggest we do it in the context of Basic 6TiSCH to see if that mode could benefit from over-provisioned time slots but then provide a way to use only a subset of those slots. This would probably make Basic 6TiSCH a lot more useful in the future for applications of various scales and degrees of burstiness.

Cheers,

Pascal

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 29 Aug 2013 11:41:48 -0700

+1

Rather than "basic", let's talk about "minimal 6TiSCH Configuration", i.e.
the title of the draft.

Xavi agreed a couple of calls ago to rename "draft-vilajosana-6tsch-basic"
to "draft-vilajosana-6tisch-minimal"

Thomas

On Thu, Aug 29, 2013 at 2:16 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Hello Xavi and Qin:****
>
> ** **
>
> I’m not sure we want  to continue this discussion now or keep it for
> later, but either way I’m making it a separate thread to save the current
> conclusions.****
>
> ** **
>
> In short, Thomas below asked:****
>
> ** **
>
> *Thomas> over what cells with the reports travel? Another questions could
> be: over what cells will the request to install cells travel?*
>
> ** **
>
> This is a good question and at the same time this is not really something
> that we have to answer right now, per our proposed charter, as Xavi
> indicates:****
>
> *Xavi> I think it is better first to concentrate on the basic things*
>
> ** **
>
> On the side I think the use of the word ‘basic’ these days could create
> confusion since it seems to refer to draft-vilajosana-6tsch-basic which is
> probably not Xavi’s intention here.****
>
> I’d suggest that when we refer to the operation in the
> draft-vilajosana-6tsch-basic draft, we call it something like “Basic
> 6TiSCH” or “Basic 6TiSCH Support” so the use of the plain word “basic” may
> not be confusing anymore.****
>
> ** **
>
> For this particular thread, I suggested as an answer to Thomas that 1) I
> agree that in the future the control flows could travel over a Basic 6TiSCH
> instance, and in that case 2) that we could probably handle burstiness of
> control traffic by overprovisioning time slots and then indicating
> dynamically which extra time slots are being used; as Qin puts it very
> clearly:****
>
> *Qin> Over-provision can increase the throughput at peak time, while the
> control bits can reduce the energy consumption for idle-listening (at least
> at the beginning of slot) in those unused Tx/Rx cells.*
>
> I was thinking of something like a ‘more’ bit in a cell the is being used
> in order to tell listeners to wake up in the next overprovisionned cell, as
> opposed to a bit sent at the beginning of the overprovisionned cell that
> would indicate that the cell is not being used, though. Xavi agrees that it
> *Xavi> sounds to me a great idea*****
>
> ** **
>
> To make sure that we do not make a confusion between 1) the bits that
> control the use of overprovisionned cells in a bundle and that are pigy
> backed with the traffic to indicate there is more trafficoutstanding and 2)
> the end to end protocol that controls the allocation of cells between a
> controlling entity and the device, or between devices, JP insisted that the
> control flows for the latter (which are the subject of the original thread
> by Qin) should be cleanly defined and that we should not expect to piggy
> back them with traffic:****
>
> *JP> I would just be vary cautious when thinking of piggybacking control
> information in packet header for control plane purpose***
>
> ** **
>
> With this summary, it is up to us to continue the discussion or save it
> for later. Should we continue, I suggest we do it in the context of Basic
> 6TiSCH to see if that mode could benefit from over-provisioned time slots
> but then provide a way to use only a subset of those slots. This would
> probably make Basic 6TiSCH a lot more useful in the future for applications
> of various scales and degrees of burstiness.****
>
> ** **
>
> Cheers,****
>
> ** **
>
> Pascal****
>

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Thu, 29 Aug 2013 12:00:21 -0700

Yes I do, the next revision will be a new draft with 6TiSCH and Minimal...
and then no more naming issues!!

:)

X

On Thu, Aug 29, 2013 at 11:41 AM, Thomas Watteyne <
[email-masked]> wrote:

>> *Thomas> over what cells with the reports travel? Another questions
>> could be: over what cells will the request to install cells travel?*
>>
>> ** **
>>
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch
>
>

---

From: Qin Wang <[email-masked]>
Date: Fri, 30 Aug 2013 03:11:48 +0800

Can we just call it "minimal 6TiSCH", instead of "minimal 6TiSCH
configuration"?

Qin

On Fri, Aug 30, 2013 at 2:41 AM, Thomas Watteyne <[email-masked]
> wrote:

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 29 Aug 2013 12:52:57 -0700

Of course!

On Thu, Aug 29, 2013 at 12:11 PM, Qin Wang <[email-masked]> wrote:

> On Fri, Aug 30, 2013 at 2:41 AM, Thomas Watteyne <
>> Rather than "basic", let's talk about "minimal 6TiSCH Configuration",
>> i.e. the title of the draft.
>>
>> Xavi agreed a couple of calls ago to rename
>> "draft-vilajosana-6tsch-basic" to "draft-vilajosana-6tisch-minimal"
>>
>> Thomas
>>
>>
>>> This is a good question and at the same time this is not really
>>> something that we have to answer right now, per our proposed charter, as
>>> Xavi indicates:****
>>>
>>> *Qin> Over-provision can increase the throughput at peak time, while
>>> the control bits can reduce the energy consumption for idle-listening (at
>>> least at the beginning of slot) in those unused Tx/Rx cells.*
>>>
>>> I was thinking of something like a ‘more’ bit in a cell the is being
>>> used in order to tell listeners to wake up in the next overprovisionned
>>> cell, as opposed to a bit sent at the beginning of the overprovisionned
>>> cell that would indicate that the cell is not being used, though. Xavi
>>> agrees that it *Xavi> sounds to me a great idea*****
>>>
>>> ** **
>>>
>>> *JP> I would just be vary cautious when thinking of piggybacking
>>> control information in packet header for control plane purpose***
>>>
>>> ** **
>>>

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Thu, 29 Aug 2013 13:00:25 -0700

ok, I like it. If there is no objection I will change the name to minimal
6TiSCH

cheers.
Xavi

On Thu, Aug 29, 2013 at 12:52 PM, Thomas Watteyne <
[email-masked]> wrote:

>>>> For this particular thread, I suggested as an answer to Thomas that 1)
>>>> I agree that in the future the control flows could travel over a Basic
>>>> 6TiSCH instance, and in that case 2) that we could probably handle
>>>> burstiness of control traffic by overprovisioning time slots and then
>>>> indicating dynamically which extra time slots are being used; as Qin puts
>>>> it very clearly:****
>>>>