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

[Nicola Accettura]

Diego,

in the end, I guess we agree on this, the REQUIREDCELLS is the output of
the bandwidth estimation algorithm, whichever we want to define in the
draft. I guess we agree too that this is an estimate.

Then it's up to the allocation policy to compare this estimate with what's
the state of the system, i.e., SCHEDULEDCELLS, and produce an output
(number of cells to add/delete) and a change in the state (SCHEDULEDCELLS
will be updated according to REQUIREDCELLS and to SF0THERSH). The
overprovision we are talking about depends in the end on some function of
the SF0THRESH. One way to compute the output is the one that Tengfei is
recalling. We already avoided to write down that thing in the OTF draft
(now it is SF0, but the substance of the way of computing the output is
always the same), just because we wanted the draft to be more general.

For instance: adding/deleting one cell is for sure not optimal, as Tengfei
is saying, I agree. Though in most cases, it is what is really needed. The
choice to not indicate a specific value for the number of cells to
add/delete comes from a tradeoff between point of views.

Why are we going back? Or is there something that I'm misunderstanding or
missing?

Nicola


2016-11-02 17:02 GMT+01:00 Prof. Diego Dujovne :

> Nicola,
>  I answer below.
> Regards,
>
>Diego
>
> 2016-11-02 12:35 GMT-03:00 Nicola Accettura :
>
>> 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.
>>
>
> What I'm saying is that the number of required cells could change when you
> measure the requested cells from the application (an assumption no longer
> valid) to the number of effectively used cells (which depends on the
> aggregate number of effectively used cells by the node itself plus the ones
> used by the forwarded traffic from the neighbors on this particular link)
>
>
>>
>> @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, we may suggest a value, without being it mandatory.
>
>
>
>>
>> Nicola
>>
>>
>> 2016-11-02 16:00 GMT+01:00 Tengfei Chang :
>>
>>> 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 <
>>> diego.dujo...@mail.udp.cl> 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 :

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

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

[Prof. Diego Dujovne]

Nicola,
 I answer below.
Regards,

   Diego

2016-11-02 12:35 GMT-03:00 Nicola Accettura :

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

What I'm saying is that the number of required cells could change when you
measure the requested cells from the application (an assumption no longer
valid) to the number of effectively used cells (which depends on the
aggregate number of effectively used cells by the node itself plus the ones
used by the forwarded traffic from the neighbors on this particular link)


>
> @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, we may suggest a value, without being it mandatory.



>
> Nicola
>
>
> 2016-11-02 16:00 GMT+01:00 Tengfei Chang :
>
>> 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 <
>> diego.dujo...@mail.udp.cl> 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 :
>>>
 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 :

> 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 

Re: [6tisch] [6TISCH] RELOCATE command in sixtop?

[Nicola Accettura]

Tengfei, all,

the idea of relocation is very useful, I agree. A RELOCATE command would
require the same reliable process for maintaining the schedule knowledge
consistent between both sides of the transaction. Which is in practice
identical to that of an ADD command.

Maybe it is possible to use the same abstract command to make add/relocate
with the same kind of reliable process (request, response). Add and
relocate operation have much more in common than a delete command (there is
only a one-way packet in that transaction).

What do you think?

Nicola

2016-11-02 16:09 GMT+01:00 Prof. Diego Dujovne :

> Pascal,
> The relocation process from SF0 is meant
> also to detect collisions after random allocation, among
> other sources of packet loss, such as narrowband
> interference or noise.
> Regards,
>
>  Diego
>
> 2016-11-02 12:06 GMT-03:00 Pascal Thubert (pthubert) :
>
>> Hello Tengfei;
>>
>>
>>
>> this looks very useful in the context of the minimal cell allocation
>> (Xavi’s random appropriation and collision detection).
>>
>>
>>
>> Take care,
>>
>>
>>
>> Pascal
>>
>>
>>
>> *From:* 6tisch [mailto:6tisch-boun...@ietf.org] *On Behalf Of *Tengfei
>> Chang
>> *Sent:* mercredi 2 novembre 2016 15:47
>> *To:* 6tisch@ietf.org
>> *Subject:* [6tisch] [6TISCH] RELOCATE command in sixtop?
>>
>>
>>
>> All,
>>
>>
>>
>> I would like to propose an idea to add a new command called RELOCATE
>> command in sixtop.
>>
>> This RELOCATE sixtop command will contains the cells to be added and
>> removed in single packet.
>>
>>
>>
>> Without RELOCATE command, the relocation is done through adding one cell
>> first then deleting one cell.
>>
>> With RELOCATE command, once the sixtop transaction for relocation
>> successes, the relocation process is done.
>>
>>
>>
>> There are several benefit from RELOCATE:
>>
>>
>>
>> 1.save overhead of relocation process.
>>
>> 2. avoid the influence of relocation on SF0. It requires SF0 to take the
>> relocation into consideration if the cell is added through relocation or
>> not. SF0 may take different decision.
>>
>>
>>
>> What do you think?
>>
>>
>>
>> Tengfei
>>
>>
>>
>>
>>
>>
>> --
>>
>> Chang Tengfei,
>>
>> Pre-Postdoctoral Research Engineer, Inria
>>
>> ___
>> 6tisch mailing list
>> 6tisch@ietf.org
>> 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
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

[Nicola Accettura]

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 :

> 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 <
> diego.dujo...@mail.udp.cl> 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 :
>>
>>> 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 :
>>>
 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 

Re: [6tisch] [6TISCH] RELOCATE command in sixtop?

[Prof. Diego Dujovne]

Pascal,
The relocation process from SF0 is meant
also to detect collisions after random allocation, among
other sources of packet loss, such as narrowband
interference or noise.
Regards,

 Diego

2016-11-02 12:06 GMT-03:00 Pascal Thubert (pthubert) :

> Hello Tengfei;
>
>
>
> this looks very useful in the context of the minimal cell allocation
> (Xavi’s random appropriation and collision detection).
>
>
>
> Take care,
>
>
>
> Pascal
>
>
>
> *From:* 6tisch [mailto:6tisch-boun...@ietf.org] *On Behalf Of *Tengfei
> Chang
> *Sent:* mercredi 2 novembre 2016 15:47
> *To:* 6tisch@ietf.org
> *Subject:* [6tisch] [6TISCH] RELOCATE command in sixtop?
>
>
>
> All,
>
>
>
> I would like to propose an idea to add a new command called RELOCATE
> command in sixtop.
>
> This RELOCATE sixtop command will contains the cells to be added and
> removed in single packet.
>
>
>
> Without RELOCATE command, the relocation is done through adding one cell
> first then deleting one cell.
>
> With RELOCATE command, once the sixtop transaction for relocation
> successes, the relocation process is done.
>
>
>
> There are several benefit from RELOCATE:
>
>
>
> 1.save overhead of relocation process.
>
> 2. avoid the influence of relocation on SF0. It requires SF0 to take the
> relocation into consideration if the cell is added through relocation or
> not. SF0 may take different decision.
>
>
>
> What do you think?
>
>
>
> Tengfei
>
>
>
>
>
>
> --
>
> Chang Tengfei,
>
> Pre-Postdoctoral Research Engineer, Inria
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> 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
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] [6TISCH] RELOCATE command in sixtop?

[Pascal Thubert (pthubert)]

Hello Tengfei;

this looks very useful in the context of the minimal cell allocation (Xavi’s 
random appropriation and collision detection).

Take care,

Pascal

From: 6tisch [mailto:6tisch-boun...@ietf.org] On Behalf Of Tengfei Chang
Sent: mercredi 2 novembre 2016 15:47
To: 6tisch@ietf.org
Subject: [6tisch] [6TISCH] RELOCATE command in sixtop?

All,

I would like to propose an idea to add a new command called RELOCATE command in 
sixtop.
This RELOCATE sixtop command will contains the cells to be added and removed in 
single packet.

Without RELOCATE command, the relocation is done through adding one cell first 
then deleting one cell.
With RELOCATE command, once the sixtop transaction for relocation successes, 
the relocation process is done.

There are several benefit from RELOCATE:

1.save overhead of relocation process.
2. avoid the influence of relocation on SF0. It requires SF0 to take the 
relocation into consideration if the cell is added through relocation or not. 
SF0 may take different decision.

What do you think?

Tengfei



--
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] [6TISCH] RELOCATE command in sixtop?

[Tengfei Chang]

All,

I would like to propose an idea to add a new command called RELOCATE
command in sixtop.
This RELOCATE sixtop command will contains the cells to be added and
removed in single packet.

Without RELOCATE command, the relocation is done through adding one cell
first then deleting one cell.
With RELOCATE command, once the sixtop transaction for relocation
successes, the relocation process is done.

There are several benefit from RELOCATE:

1.save overhead of relocation process.
2. avoid the influence of relocation on SF0. It requires SF0 to take the
relocation into consideration if the cell is added through relocation or
not. SF0 may take different decision.

What do you think?

Tengfei



-- 
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

[Prof. Diego Dujovne]

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 :

> 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 :
>
>> 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
>> 6tisch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>>
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> 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
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

[Nicola Accettura]

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 :

> 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
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] [6TiSCH] Node Behavior at Boot in SF0

[Tengfei Chang]

All,

For the decision when a node is restarted, the SF0 says:

   In order to define a known state after the node is restarted, a CLEAR
   command is issued to each of the neighbor nodes to enable a new
   allocation process.  The 6P Initial Timeout Value provided by SF0
   should allow for the maximum number of TSCH link-layer retries, as
   defined by Section 4.3.4 of [I-D.ietf-6tisch-6top-protocol
].
TODO/
   REMARK: The initial timeout is currently under discussion.


A little suggestion is DO NOT issue a clear command to previous parent
until the nodes has reserved new cells to its new parent. This is to avoid
the swing if the reservation failed to its new parent and changed back to
previous parent.

What do you think?

Tengfei

-- 
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

[Tengfei Chang]

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
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch