Re: [6tisch] SF0 - Cell reclamation by RPL parent
"S.V.R.Anand" <anand@ece.iisc.ernet.in> Sun, 13 March 2016 18:00 UTC
Return-Path: <anand@ece.iisc.ernet.in>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2412012D71F for <6tisch@ietfa.amsl.com>; Sun, 13 Mar 2016 11:00:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.105
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BESpFeu6bRcc for <6tisch@ietfa.amsl.com>; Sun, 13 Mar 2016 11:00:54 -0700 (PDT)
Received: from relay.iisc.ernet.in (unknown [203.200.35.67]) by ietfa.amsl.com (Postfix) with SMTP id 7F92312D711 for <6tisch@ietf.org>; Sun, 13 Mar 2016 11:00:52 -0700 (PDT)
Received: from ece.iisc.ernet.in (mail.ece.iisc.ernet.in [10.32.1.10]) by relay.iisc.ernet.in (Postfix) with ESMTP id 08E13AE1FDD; Sun, 13 Mar 2016 23:28:51 +0530 (IST)
Received: from [10.3.1.120] ([10.3.1.120]) by ece.iisc.ernet.in (8.14.7/8.14.7) with ESMTP id u2DI0pXj023713; Sun, 13 Mar 2016 23:30:53 +0530
To: "Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl>
References: <56DD59C8.20403@ece.iisc.ernet.in> <CAH7SZV_STx-cyZ1ru4ML=7aMF1n5LrxWiXU5809p+qJThbnojQ@mail.gmail.com>
From: "S.V.R.Anand" <anand@ece.iisc.ernet.in>
Message-ID: <56E5AAC4.60200@ece.iisc.ernet.in>
Date: Sun, 13 Mar 2016 23:30:36 +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: <CAH7SZV_STx-cyZ1ru4ML=7aMF1n5LrxWiXU5809p+qJThbnojQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------000108000004070103070200"
X-IISc-MailScanner-Information: Please contact nethelp@serc.iisc.in for more information
X-IISc-MailScanner-ID: 08E13AE1FDD.A8917
X-IISc-MailScanner: Found to be clean
X-IISc-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.889, 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, URIBL_BLOCKED 0.00)
X-IISc-MailScanner-From: anand@ece.iisc.ernet.in
MailScanner-NULL-Check: 1458496731.83975@/u38+U4OvByiFTBSQcxFhw
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/ELTGrRUkJiV8vv5mkc0L7bEARw8>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>
Subject: Re: [6tisch] SF0 - Cell reclamation by RPL parent
X-BeenThere: 6tisch@ietf.org
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" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Mar 2016 18:00:57 -0000
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 <anand@ece.iisc.ernet.in>: > > 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 > (56 2) 676 8125
- [6tisch] SF0 - Cell reclamation by RPL parent S.V.R.Anand
- Re: [6tisch] SF0 - Cell reclamation by RPL parent Thomas Watteyne
- Re: [6tisch] SF0 - Cell reclamation by RPL parent Prof. Diego Dujovne
- Re: [6tisch] SF0 - Cell reclamation by RPL parent S.V.R.Anand
- Re: [6tisch] SF0 - Cell reclamation by RPL parent S.V.R.Anand