Subject: [6tisch] SF0 - Cell reclamation by RPL parent

From: "S.V.R.Anand" <[email-masked]>
Date: Mon, 7 Mar 2016 16:06:56 +0530

Hi Diego and others,

Since we are discussing about the message transactions in SF0, this mail 
is with
respect to the RPL parent, the cell donor.

There are situations where the RPL parent might want to apply a cell 
reclamation
and, depending on the context, a reallocation policy dynamically. This 
results in one or more cells that
have been given to its children are reclaimed by the RPL parent due to 
various
reasons as below.

- The child node is out of the network, or child and parent cannot reach 
each other,
   after the 6P add cell transaction is complete, thereby delete cell 
operation is not
   being transacted. Cell reclamation helps in "cell garbage" collection.

- As add cell requests arrive asynchronously from its children, an RPL
   parent implementing certain fairness objective might re-appropriate 
the cells
   that have already alloted its children, especially during a resource 
crunch.

- Referring to the following text in 4.2.5 of the 6tisch architecture 
document,

   "...Note that a PCE is expected to have precedence in the allocation, 
so that  an RPL parent
     would only be able to obtain portions that are not in-use by the PCE."

   It may be that, an RPL parent might have to relinquish its own cells if
    needed by PCE any time. In such a scenario, the RPL parent may be 
forced to
   reclaim the cells given to its children.

While the first case is relatively less complex, the latter two cases are
problematic as these cases can lead to (i) potential race conditions, say
between PCE and SF0 operations, and (ii) a cascading effect across 
several RPL
parents down the DODAG. Currently, there is no mechanism defined to address
this problem.

I suppose the above text extends beyond SF0.

In light of the above use cases and the associated problems, do you 
think it is a
good idea to include an appropriate message in SF0 for reclaiming the 
cells by
the RPL parent ? or are we inviting new set of problems by doing so ?

Will be happy to receive your inputs.

Anand

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 11 Mar 2016 14:53:17 +0100

Anand,

You are raising a good point. This would mean that a 6P transaction is
started not by the the sender, but the receiver.

I have added a slide in the set for this afternoon's call, as a
high-bandwidth discussion might be best approach here.

Thomas

On Mon, Mar 7, 2016 at 11:36 AM, S.V.R.Anand <[email-masked]>
wrote:

>   parent implementing certain fairness objective might re-appropriate the
> cells
>   "...Note that a PCE is expected to have precedence in the allocation, so
> that  an RPL parent
> between PCE and SF0 operations, and (ii) a cascading effect across several
> RPL
> In light of the above use cases and the associated problems, do you think
> it is a
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Fri, 11 Mar 2016 11:09:37 -0300

Anand,
           Let me comment inline below.
Regards,

                              Diego

>   being transacted. Cell reclamation helps in "cell garbage" collection.
I was thinking on the neighbour list management. If a neighbour is deleted,
all the cells
belonging to the link with that neighbour shall be deleted too. Is there a
specification on
which entity maintains the neighbour list?

>   that have already alloted its children, especially during a resource

Bandwidth requests are managed by SFs; an SF running on a Parent can
trigger
a deletion event as needed. The starving applications on the top layer
should
react accordingly. The problem here is that the SFs react given certain
statistics
and events, but there is no current connection with other modules which may
reclaim cells.
This raises another point: The cell list should be kept and maintained at
the
6P level, or at the SF? Do we allow for multiple SFs on the same node?
Do we allow only different SFs in a per-neighbour basis (so each link is
managed
by only one SF)?

> I suppose the above text extends beyond SF0.

As far as I know, we are using chunks allocated to the RPL Parents by the
PCE to
schedule cells requested by SFs. The main assumption here is that the PCE
will
distribute chunks among the RPL Parents and not reclaim them back. However,
it is only an assumption. As I noticed above, cell list maintenance should
be transferred
to 6P if another module can add/delete cells concurrently.

> the RPL parent ? or are we inviting new set of problems by doing so ?
My question here is: Who is going to send this message? RPL? PCE through
CoAP?
Can we leave this to Chunk negotiation, which is currently out of scope of
this draft?

-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125

---

From: "S.V.R.Anand" <[email-masked]>
Date: Sun, 13 Mar 2016 18:48:26 +0530

Thomas,

Thank you very much for liking the points that I raised, and including
a slide for discussion during the interim call. Appreciate for initiating a
lively discussion :)

Out of the three cases, I am wondering if the second case of achieving 
fairness
among competing requests that arrive can be handled better without 
reclaiming
cells. One possible method that comes to mind is pooling multiple requests
before responding, rather than serving requests as and when they arrive 
in the
FCFS basis.  Of course, there could be other alternatives. What do you say ?

Anand

On Friday 11 March 2016 07:23 PM, Thomas Watteyne wrote:
> Anand,  > > You are raising a good point. This would mean that a 6P 
transaction is started not by the the sender, but the receiver. > > I 
have added a slide in the set for this afternoon's call, as a 
high-bandwidth discussion might be best approach here. > > Thomas > > On 
Mon, Mar 7, 2016 at 11:36 AM, S.V.R.Anand <[email-masked]> 
wrote: > >     Hi Diego and others, > >     Since we are discussing 
about the message transactions in SF0, this mail is with >     respect 
to the RPL parent, the cell donor. > >     There are situations where 
the RPL parent might want to apply a cell reclamation >     and, 
depending on the context, a reallocation policy dynamically. This 
results in one or more cells that >     have been given to its children 
are reclaimed by the RPL parent due to various >     reasons as below. > 
 >     - The child node is out of the network, or child and parent 
cannot reach each other, >       after the 6P add cell transaction is 
complete, thereby delete cell operation is not >       being transacted. 
Cell reclamation helps in "cell garbage" collection. > >     - As add 
cell requests arrive asynchronously from its children, an RPL >       
parent implementing certain fairness objective might re-appropriate the 
cells >       that have already alloted its children, especially during 
a resource crunch. > >     - Referring to the following text in 4.2.5 of 
the 6tisch architecture document, > >       "...Note that a PCE is 
expected to have precedence in the allocation, so that  an RPL parent 
 >         would only be able to obtain portions that are not in-use by 
the PCE." > >       It may be that, an RPL parent might have to 
relinquish its own cells if >        needed by PCE any time. In such a 
scenario, the RPL parent may be forced to >       reclaim the cells 
given to its children. > >     While the first case is relatively less 
complex, the latter two cases are >     problematic as these cases can 
lead to (i) potential race conditions, say >     between PCE and SF0 
operations, and (ii) a cascading effect across several RPL >     parents 
down the DODAG. Currently, there is no mechanism defined to address 
 >     this problem. > >     I suppose the above text extends beyond 
SF0. > >     In light of the above use cases and the associated 
problems, do you think it is a >     good idea to include an appropriate 
message in SF0 for reclaiming the cells by >     the RPL parent ? or are 
we inviting new set of problems by doing so ? > >     Will be happy to 
receive your inputs. > >     Anand > > >     -- >     This message has 
been scanned for viruses and >     dangerous content by MailScanner, and 
is >     believed to be clean. > >     
_______________________________________________ >     6tisch mailing 
list >     [email-masked] >     
https://www.ietf.org/mailman/listinfo/6tisch > >

---

From: "S.V.R.Anand" <[email-masked]>
Date: Sun, 13 Mar 2016 23:30:36 +0530

Hi Diego,

Thank you very much for the detailed response. Please find below my comments
inline.

Regards
Anand

On Friday 11 March 2016 07:39 PM, Prof. Diego Dujovne wrote:
> Anand,  >            Let me comment inline below. > Regards, > 
 >                               Diego > > 2016-03-07 7:36 GMT-03:00 
S.V.R.Anand <[email-masked]>: > >     Hi Diego and others, > 
 >     Since we are discussing about the message transactions in SF0, 
this mail is with > >     There are situations where the RPL parent 
might want to apply a cell reclamation >     and, depending on the 
context, a reallocation policy dynamically. This results in one or more 
cells that >     have been given to its children are reclaimed by the 
RPL parent due to various >     reasons as below. > >     - The child 
node is out of the network, or child and parent cannot reach each other, 
 >       after the 6P add cell transaction is complete, thereby delete 
cell operation is not >       being transacted. Cell reclamation helps 
in "cell garbage" collection. > > > I was thinking on the neighbour list 
management. If a neighbour is deleted, all the cells > belonging to the 
link with that neighbour shall be deleted too. Is there a specification 
on > which entity maintains the neighbour list? >

Absolutely. There is a need for such a management entity. I can think of 
an API
that SF0 provides to that entity so that with the help of appropriate 
callback
functions and commands, it can implement certain policies on per-neighbor
basis.  Does that make sense ?

> > >     - As add cell requests arrive asynchronously from its children, 
an RPL >       parent implementing certain fairness objective might 
re-appropriate the cells >       that have already alloted its children, 
especially during a resource crunch. > > > Bandwidth requests are 
managed by SFs; an SF running on a Parent can trigger > a deletion event 
as needed. The starving applications on the top layer should > react 
accordingly. The problem here is that the SFs react given certain 
statistics > and events, but there is no current connection with other 
modules which may > reclaim cells. > This raises another point: The cell 
list should be kept and maintained at the > 6P level, or at the SF? Do 
we allow for multiple SFs on the same node? > Do we allow only different 
SFs in a per-neighbour basis (so each link is managed > by only one SF)? >

The points you are raising are very important from the architectural 
point of
view. At high level, I suppose the solution calls for an introduction of an
additional control logic module that works with SF0 and makes algorithmic
decisions. I feel the functional decomposition that you are pointing out
requires more discussion.

>  > >     - Referring to the following text in 4.2.5 of the 6tisch 
architecture document, > >       "...Note that a PCE is expected to have 
precedence in the allocation, so that  an RPL parent >         would 
only be able to obtain portions that are not in-use by the PCE." > 
 >       It may be that, an RPL parent might have to relinquish its own 
cells if >        needed by PCE any time. In such a scenario, the RPL 
parent may be forced to >       reclaim the cells given to its children. 
 > >     While the first case is relatively less complex, the latter two 
cases are >     problematic as these cases can lead to (i) potential 
race conditions, say >     between PCE and SF0 operations, and (ii) a 
cascading effect across several RPL >     parents down the DODAG. 
Currently, there is no mechanism defined to address >     this problem. 
 > >     I suppose the above text extends beyond SF0. > > > As far as I 
know, we are using chunks allocated to the RPL Parents by the PCE to > 
schedule cells requested by SFs. The main assumption here is that the 
PCE will > distribute chunks among the RPL Parents and not reclaim them 
back. However, > it is only an assumption. As I noticed above, cell list 
maintenance should be transferred > to 6P if another module can 
add/delete cells concurrently. >

As we are soon moving towards Detnet, PCE can potentially set up tracks or
reserve chunks dynamically based on the requests from application. The race
condition can arise from the fact that, at the instant PCE takes away a 
chunk
from an RPL parent over CoAP, it is not clear what would happen to the
transactional state of 6P if it is in the middle of the transactional 
activity
of the add/delete cell request between it and its children. If a child 
is also
an RPL parent, we could end up in a further unpredictable state. This is
my fear.

> > > >     In light of the above use cases and the associated problems, 
do you think it is a >     good idea to include an appropriate message 
in SF0 for reclaiming the cells by >     the RPL parent ? or are we 
inviting new set of problems by doing so ? > > > My question here is: 
Who is going to send this message? RPL? PCE through CoAP? > Can we leave 
this to Chunk negotiation, which is currently out of scope of this draft? >

Yes, as you noted, there could be several sources that can initiate the 
reclaim process.

> > >     Will be happy to receive your inputs. > >     Anand > > >     
-- >     This message has been scanned for viruses and >     dangerous 
content by MailScanner, and is >     believed to be clean. > > > > > -- 
 > DIEGO DUJOVNE > Académico Escuela de Ingeniería en Informática y 
Telecomunicaciones > Facultad de Ingeniería UDP > www.ingenieria.udp.cl