Subject: Re: [6tisch] Shared / Dedicated cell policy on SF0

From: Yasuyuki Tanaka <[email-masked]>
Date: Wed, 16 Nov 2016 12:33:42 +0100

Hi Diego,

diego> b) if we keep working with the initial assumption, and do not
diego> allow any shared cells to be scheduled by SF0.

Why is scheduling shared cells not allowed by the initial assumption?
I'm a relative newcomer to 6TiSCH and not sure about the initial
assumption...

To me, it seems that scheduling shared cells is more sensible in
Neighbor-to-Neighbor Scheduling than dedicated cells. I would say that
the SHARED cell bit in the CellOptions field should be always on when
the field is used for CMD_ADD.

A pair of devices in a 6P conversation have no idea if cells they are
scheduling are truly dedicated. In general, cells scheduled with 6P
are possibly shared with multiple TX devices. In other words, I think
it'd be better to always perform CCA on a cell scheduled with 6P.

Best,
Yatch

On 2016/10/31 22:23, Prof. Diego Dujovne wrote:
> Dear all,
>              SF0 has assumed until now that it was
> only working on dedicated cells, but 6P now provides
> the possibility to use shared cells.
>
>              I would like to hear your thoughts on the
> following alternatives:
> a) if we allow shared cells to be used SF0, how to
> establish a policy on which type of cells to allocate.
> Currently, SF0 observes only the incoming number of
> cell allocation requests and effectively used cells
> to calculate the number of required cells.
> b) if we keep working with the initial assumption, and
> do not allow any shared cells to be scheduled by SF0.
>
> A quick solution would be to define two different instances
> of SF0, one for shared cells and the other for dedicated
> ones.
>             Regards,
>
>                                      Diego
>
> --
> DIEGO DUJOVNE
> Profesor Asociado
> Escuela de Informática y Telecomunicaciones
> Facultad de Ingeniería - Universidad Diego Portales - Chile
> www.ingenieria.udp.cl <http://www.ingenieria.udp.cl>
> (56 2) 676 8125
>
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 16 Nov 2016 15:15:47 +0000

Yatch,
Allow me to answer in two parts.

First, about your last statement, I don't think CCA will make a difference.
Since the nodes are synchronized, they will all be doing the CCA at the
same time and not hear each other.

If I get your first point well, you suggest to schedule shared cells so
that, if there is contention, back off is used to deal with it before the
cells are possibly relocated. I would argue that, because packets get lost
anyways in wireless from time to time, a node might end up backing off more
than necessary. I don't have numbers to prove, but since there schedules
are typically verse sparse, backing off might cost you more than not.

Thomas

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Wed, 16 Nov 2016 12:22:27 -0300

Yakusuki,
               We currently assume that:
- we have no information about the generated traffic from the application
- we do not know which part of the incoming traffic is routed to which
neighbour.

Example: If a both a TX cell and a Shared cell are requested as incoming
to the node, we do not know to which neighbour these cells will be routed,
or if the incoming traffic destination is the node itself.

As a consequence, since the only true source of information is the effective
number of outgoing cells, our default behavior is to allocate dedicated TX
cells
to the specific neighbour.

I think the reason to use TX or Shared cells as a default, is covered by
Thomas' answer.

Thank you.
Regards,

                                      Diego

www.ingenieria.udp.cl
(56 2) 676 8125

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Wed, 16 Nov 2016 18:03:24 +0100

Hi Thomas and Diego,

thomas> Since the nodes are synchronized, they will all be doing the
thomas> CCA at the same time and not hear each other.

Oh yeah. There is no random delay before performing CCA in the TSCH
case in Figure 6-5 of IEEE 802.15.4-2015! OK, I understand that two
TSCH TX devices sharing a single TX cell will send their frames at the
same time after CCA.

But, what if there are devices of other types or protocols? CCA could
prevent a TSCH device from disturbing other ongoing communication by
non-TSCH devices. Performing CCA could make 6TiSCH/TSCH devices a bit
nicer to other devices at the cost of energy for CCA.

How about defining a configuration parameter to control which type of
cell to schedule, dedicated or shared? I guess, SF0 cannot make such a
decision autonomously, so let's leave it to network administrators or
users.
# We would still have to decide its default value, though.

If they know there are only TSCH-aware nodes, for example, in a
managed environment, CCA is not needed; disable CCA so that the nodes
can save energy. Otherwise, CCA is enabled.

thomas> I would argue that, because packets get lost anyways in
thomas> wireless from time to time, a node might end up backing off
thomas> more than necessary. I don't have numbers to prove, but since
thomas> there schedules are typically verse sparse, backing off might
thomas> cost you more than not.

I agree. It would take a long time to get a next chance to send with a
sparse cell schedule. We may have to set 0 to macMaxFrameRetries to
avoid backoffs when using shared TX cells in TSCH; then, the case of
performing CCA in the CSMA-CA algorithm looks compatible with the
other case from the point of view of an upper layer, e.g., 6TiSCH.

Best,
Yatch

On 2016/11/16 16:22, Prof. Diego Dujovne wrote:
> number of outgoing cells, our default behavior is to allocate dedicated TX cells
> 2016-11-16 8:33 GMT-03:00 Yasuyuki Tanaka <[email-masked] <mailto:[email-masked]>>:
>
>     Hi Diego,
>
>         www.ingenieria.udp.cl <http://www.ingenieria.udp.cl> <http://www.ingenieria.udp.cl>
>         (56 2) 676 8125
>
>
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>
>
>
>
>
>
> --
> DIEGO DUJOVNE
> Profesor Asociado