Re: [6tisch] [6TISCH] Specify the number of cells to be added or deleted in SF0

[Nicola Accettura <[e-mail]>]

Diego, Tengfei,

I'll provide comments to each of you.

@Diego: I believe that the change in the estimation algorithm does not
change the fact that both OTF and SF0 give as output a number of cells to
add/delete, and this is the point I'm discussing on. If we agree on this
simple evidence (OTF and SF0 give as output a number of cells to
add/delete), I don't see why the reasoning related to the ouput of OTF
should not apply to the reasoning related to SF0 output. So I don't get
really your issue.

@Tengfei: the thing you are talking about (a hint on the number of cells to
be added/deleted) was not expected neither by 6top nor OTF. In fact, what
you are proposing was already present as idea in a paper on OTF. Now we
have 6P and SF0. 6P inherits much from 6TOP. Some of the 6TOP features not
present in 6P are now under the domain of SF0. SF0 inherits both from 6TOP
and OTF. So the change from 6TOP,OTF to 6P,SF0 does not imply that SF0 has
to specify a specific number of cells to be added/deleted. We wanted the
protocols to be as general as possible. I don't think that writing down a
specific way of computing the number of cells to be added/deleted would
help the generality we want to express as standard.

But there could be something else I'm not considering. Please, don't
hesitate to share here your thoughts.

Nicola


2016-11-02 16:00 GMT+01:00 Tengfei Chang <[e-mail]>:

> Hi Nicola, Diego,
>
> I see. Thanks for all your explanation!
>
> It would be very helpful if we can see some recommended number of cell or
> advice how to choose the number of cell in the draft.
> As Sixtop left lots of details in SF, my thought is SF should give more
> specific information or clues for developer/implementer to implement.
> Of course, those information will come out from real experiments.
>
> Thanks for all you replying!
>
> Tengfei
>
>
> On Wed, Nov 2, 2016 at 3:42 PM, Prof. Diego Dujovne <
> [e-mail]> wrote:
>
>> Nicola,
>>            I agree with your comment, but the cell estimation
>> algorithm changed: we now estimate the number of required
>> cells from the number of requested cells (to add or delete)
>> and the number of effectively used cells. What is still not clear
>> to me is if the simulation results from the OTF paper is still valid
>> given this change. To enable the cell estimation algorithm without
>> packet loss, we need to guarantee always a small amount of
>> overprovisioning.
>>           Let me bring the lost text (from OTF) back to SF0.
>>           Regards,
>>
>>                                          Diego
>>
>> 2016-11-02 11:36 GMT-03:00 Nicola Accettura <[e-mail]>:
>>
>>> Hi Tengei,
>>>
>>> the problem you are rising is that you would like to see a number of
>>> cells to add/delete when comparing required and deleted cells.
>>>
>>> The ancestor of SF0, namely OTF, used to specify the following sentence:
>>>
>>> The number of soft cells to be scheduled/deleted for bundle resizing
>>>    is out of the scope of this document and implementation-dependant.
>>>
>>> In fact, we wanted to let that choice being implementation specific.
>>>
>>> What you are proposing (the exact number of cells to add or delete) was
>>> already implemented in the 6tisch simulator, and it is in fact something
>>> that has already been used and tested in the following papers:
>>>
>>> Palattella et al., On-the-Fly Bandwidth Reservation for 6TiSCH Wireless
>>> Industrial Networks, IEEE Sensors Journal, 2015
>>>
>>> Muraoka et al., Simple Distributed Scheduling with Collision Detection
>>> in TSCH Networks, IEEE Sensors Journal, 2016
>>>
>>> But, as already said, this is just a way you can allocate cells. I guess
>>> we don't want to restrict that setting to a particular algorithm choice.
>>>
>>> Hope this helps.
>>>
>>> Nicola
>>>
>>> 2016-11-02 14:59 GMT+01:00 Tengfei Chang <[e-mail]>:
>>>
>>>> Hi All,
>>>>
>>>> I am reading the SF0-02 version which is just released few days ago.
>>>>
>>>> In the SF0 Allocation Policy section, the policy said
>>>>
>>>>    1.  If REQUIREDCELLS<(SCHEDULEDCELLS-SF0THRESH), delete one or more
>>>>        cells.
>>>>    2.  If (SCHEDULEDCELLS-SF0THRESH)<=REQUIREDCELLS<=SCHEDULEDCELLS, do
>>>>        nothing.
>>>>    3.  If SCHEDULEDCELLS<=REQUIREDCELLS, add one or more cells.
>>>>
>>>>
>>>>
>>>> Personally thinking, add/delete one cells may call the sixtop many
>>>> times which is not efficiency, add/delete more cells is not clear to the
>>>> implementer.
>>>> I guess there is a decision to say when to add one cell and when to add
>>>> more cells. But I didn't find it in SF0 draft.
>>>> Is there any reason why we doesn't say specific number of cells?
>>>>
>>>> If no, I think we can add/remove the number of cells to make sure the
>>>> scheduled cells equals to the required cells plus half of SF0THRESH, which
>>>> will help stabilize a little bit of the SF0, in case the sixtop is calling
>>>> too often.
>>>>
>>>> Which means: if SCHEDULEDCELLS<=REQUIREDCELLS:
>>>>
>>>> 1. when there is no cell in the schedule add one cell
>>>> 2. when there is at least one cell in schedule, add
>>>> REQUIREDCELLS-SCHEDULEDCELLS+(SF0THRESH+1)/2 number of cells
>>>>
>>>> if REQUIREDCELLS<(SCHEDULEDCELLS-SF0THRESH))
>>>>
>>>> 1. When required cells equals 0, remove all cells but keep one in
>>>> schedule
>>>> 2. when required cells is greater than 0, remove  SCHEDULEDCELLS-
>>>> REQUIREDCELLS-(SF0THRESH+1)/2
>>>>
>>>> Does this make sense?
>>>>
>>>> Tengfei
>>>>
>>>> --
>>>> Chang Tengfei,
>>>> Pre-Postdoctoral Research Engineer, Inria
>>>>
>>>> _______________________________________________
>>>> 6tisch mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 6tisch mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>
>>>
>>
>>
>> --
>> DIEGO DUJOVNE
>> Profesor Asociado
>> Escuela de Informática y Telecomunicaciones
>> Facultad de Ingeniería - Universidad Diego Portales - Chile
>> www.ingenieria.udp.cl
>> (56 2) 676 8125
>>
>
>
>
> --
> Chang Tengfei,
> Pre-Postdoctoral Research Engineer, Inria
>