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

"S.V.R.Anand" <> Sun, 13 March 2016 13:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 74FCD12D53F for <>; Sun, 13 Mar 2016 06:18:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.105
X-Spam-Status: No, score=-1.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_HELO_FAIL=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pRWvB-z2NmUF for <>; Sun, 13 Mar 2016 06:18:42 -0700 (PDT)
Received: from (unknown []) by (Postfix) with SMTP id C7CA612D614 for <>; Sun, 13 Mar 2016 06:18:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1C6D5AE207D; Sun, 13 Mar 2016 18:46:38 +0530 (IST)
Received: from [] ([]) by (8.14.7/8.14.7) with ESMTP id u2DDIeRC030414; Sun, 13 Mar 2016 18:48:41 +0530
To: Thomas Watteyne <>
References: <> <>
From: "S.V.R.Anand" <>
Message-ID: <>
Date: Sun, 13 Mar 2016 18:48:26 +0530
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------020006090105070507080307"
X-IISc-MailScanner-Information: Please contact for more information
X-IISc-MailScanner-ID: 1C6D5AE207D.AA939
X-IISc-MailScanner: Found to be clean
X-IISc-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.389, required 6.5, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90, HTML_MESSAGE 0.00, NO_RDNS2 0.01, RP_MATCHES_RCVD -0.00, SMILEY -0.50, URIBL_BLOCKED 0.00)
MailScanner-NULL-Check: 1458479800.15989@+09h3FISwIuOG1rBwcxEiw
Archived-At: <>
Cc: "" <>, "Prof. Diego Dujovne" <>
Subject: Re: [6tisch] SF0 - Cell reclamation by RPL parent
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 13 Mar 2016 13:18:45 -0000


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 
among competing requests that arrive can be handled better without 
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 ?


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